Galaxy Note20 and Note20 Ultra Now Available in Remote Test Lab
-
Similar Topics
-
By Samsung Newsroom
Galaxy Store Seller Portal is Samsung's platform for developers to publish and manage their applications in Galaxy Store. It provides tools for submission, distribution, analytics, and release control.
Galaxy Store is a gateway to millions of Samsung device users, and for a developer, the stakes of a release can be incredibly high: A minor bug in a major update can lead to negative reviews and churn. To mitigate this, Samsung provides the Staged Rollout feature.
A staged rollout allows developers to gradually release application updates to only a certain percentage of users. This controlled approach helps developers manage releases efficiently and observe application behavior during update deployment. Instead of distributing an update to all users at once, developers can define a rollout percentage and increase it over time.
Key Benefits
Here are the key benefits of using a staged rollout strategy:
Control release distribution Identify issues early Reduce the risk of large-scale failures Monitor real-world performance The staged rollout rate can be set from 0% to 100%, where 0% means the update is not available at all and 100% indicates a full release. Galaxy Store provides flexibility by allowing developers to manually control and adjust rollout percentages based on performance and feedback.
Staged rollouts are supported for Android applications and can be configured based on the application’s status in Seller Portal. The appStatus parameter is central to every staged rollout API call. Find out more at Status Parameters Mapping.
Managing Staged Rollouts Using the Content Publish API
While staged rollouts can be configured through the Seller Portal UI, the Content Publish API provides a powerful programmatic interface to automate your application’s lifecycle. Within this framework, the Staged Rollout API functions as a specialized suite of endpoints that allow developers to manage incremental distribution through code rather than manual intervention.
End-to-End Flow (Example)
Before jumping into the API description, it is important to understand the full workflow.
The following illustrates a typical staged rollout workflow using the Content Publish API:
Upload Binary → Create or Update Application Content → Configure Staged Rollout (Initial Rate) → Submit for Publication → Rollout Begins (Partial Distribution) → Monitor Rollout Status → Update Rollout Rate (Progressive Increase) → (Optional) Update Rollout Binary → Complete Rollout (Full Distribution)
This flow represents a common implementation pattern. Actual workflows may vary depending on your release process. For another example of a staged rollout workflow, see Staged Rollout Release.
This tutorial focuses on the four essential endpoints that form the backbone of an automated, controlled release workflow: View Staged Rollout Rate, Update Staged Rollout Rate, View Staged Rollout Binaries, and Update Staged Rollout Binary. Each of these endpoints provides the granular control necessary to ensure that your updates reach your Galaxy device users with maximum stability and minimum risk.
Prerequisites
Before making any Content Publish API calls, you must satisfy the following requirements set out in the Galaxy Store Developer API documentation:
A registered Seller Portal account. Commercial seller status Registered applications in Seller Portal Service account ID from Seller Portal A valid access token generated using the authentication endpoint. Every API call must include this token in the Authorization: Bearer header. For more information about access tokens, check out this article. Python installed on your PC. Starting the Implementation
Before implementing the APIs, it is helpful to understand the basic structure of the code. In this example, Python is used for API implementation.
The basic code structure is as follows:
Dependency Library → Headers → Application Information → Payload → API Endpoint → CRUD Operation.
Dependency Library
To use Python script for HTTP requests, import the requests library. At this point, also import the json library to see the response in the JSON format.
# Importing the requests library import requests # Importing the json library import json Headers
To call any Content Publish API, an access token and service account ID must be sent with the headers for user authorization.
Headers parameters are:
Attribute
Type
Description
Authorization
string
Bearer <your-access-token>
service-account-id
header
Your service account ID
Now, set the required values for these headers using Python:
# Access token and headers accessToken = "<your-access-token>" Authorization = "Bearer " + accessToken SERVICE_ACCOUNT_ID = "<your-service-account-id>" # Header to be sent to the API headers = { 'Content-Type': 'application/json', 'Authorization': Authorization, 'service-account-id': SERVICE_ACCOUNT_ID } Since the dependency libraries and headers are common across all requests, you have to define them first to implement the Content Publish API.
NoteEvery Content Publish API request requires two authorization headers: Authorization: Bearer <your-access-token> and service-account-id: <your-service-account-id>. Missing either of these headers returns an authentication error. Implementing the “View Staged Rollout Rate” Endpoint
This endpoint retrieves the current default rollout rate as well as any country-specific rollout rates for the given application.
Application Information
It is essential to provide the following details for the View Staged Rollout Rate operation:
# Content ID and app status contentId= '<Content ID of your app>' appStatus= 'REGISTRATION' Here, contentId is the unique identifier of your application in Seller Portal. In the appStatus parameter, you can use either REGISTRATION or SALE. REGISTRATION is for the version under registration/update, and SALE is for the currently live version.
These parameters are required to accurately specify the application for which the staged rollout information is being requested.
API Endpoint
Use the following API to consume the application staged rollout rates.
# Defining the API endpoint (GET request) api_url=f"https://devapi.samsungapps.com/seller/v2/content/stagedRolloutRate?contentId={contentId}&appStatus={appStatus}" GET Operation
Finally, send an HTTP GET request to the Galaxy Store Server with the api_url and headers parameters.
This is a read-only operation to inspect the state of a rollout.
try: response = requests.get(api_url, headers=headers) print("Status Code:", response.status_code) data_shows = response.json() print("Parsed JSON:", json.dumps(data_shows, indent=4)) except Exception as e: print("Error:", str(e)) Response on Success
After processing the request, if all the provided information is correct, then the operation returns the success response in the JSON format:
Status Code: 200 Parsed JSON: { "resultCode": "0000", "resultMessage": "Ok", "data": { "rolloutRate": 40, "countries": [ { "countryCode": " AUT ", "rolloutRate": 30 }, { "countryCode": "BEL", "rolloutRate": 45 }] } } The rolloutRate object at the top level is the global default rate. The countries object contains possible country-specific rates that override the default. In this example, the application is being rolled out to 40% of users globally, to 30% in Austria, and to 45% of users in Belgium.
Implementing the “Update Staged Rollout Rate” Endpoint
Updating a staged rollout in Seller Portal refers to modifying the current rollout rate to expand application availability to a larger percentage of users. The updated rollout rate must be higher than the previously set value and is applied progressively during the distribution process.
The following figure shows the UI from Seller Portal. You can change most of the settings shown using the Update Staged Rollout API.
https://d3unf4s5rp9dfh.cloudfront.net/GlxyStore_blog/2026-05-28-01-01.jpg Figure 1: Update Staged Rollout Rate user interface
On this screen, if you enable the Staged Rollout Settings option, the rollout settings portion is enabled and you can set the rollout rate. Otherwise, the option to do so remains unavailable.
The Content Publish API allows you to manage distribution either globally or with regional precision.
Default Rollout Rate: This is the primary percentage applied to all supported countries. If no specific country data is provided, every market receives the update at this baseline rate.
Country-Specific Rollout Rate: This allows you to override the default rollout rate for individual markets. You can set a different rollout rate for each country.
In Figure 1, from the Seller Portal UI, you can see that the default rollout rate is 40%, the Austrian rate is 30%, and the Belgian rate is 45%. Here, the 40% default rate is applicable for all other countries except Austria and Belgium. During the release, Austria and Belgium will follow their customized rollout rate.
To modify the rollout rate for a specific country, your request has to contain either new or updated rates for any existing countries you have already defined (in the given example, Austria and Belgium) before you can add new ones. Otherwise, the request returns an error response. If you want to change the default rate only, then you can omit the countries object from the code.
API Endpoint
Define the API endpoint for updating the default or country specific staged rollout rate.
# Defining the API endpoint (PUT request) api_url="https://devapi.samsungapps.com/seller/v2/content/stagedRolloutRate" Payload
The payload defines the new rollout configuration to update the existing rollout settings. Here, when the appStatus is SALE or you are updating a previously deployed app, the new rolloutRate must be greater than the previously set default rollout rate. You cannot decrease a rollout rate once set for a live app. Plan your incremental ramp-up carefully before you start.
The payload contains the JSON data which are required for updating an application’s rollout rates.
# Payload (ENABLE rollout) payload = { "contentId": " <Content ID of your app>", "function": "ENABLE_ROLLOUT", "appStatus": "REGISTRATION", "rolloutRate": 50, "countries": [ { "countryCode": "AUT", "rolloutRate": 30 }, { "countryCode": "BEL", "rolloutRate": 55 }] } } In this example, the code changes the default rollout rate from 40% to 50% and the country-specific rollout rate for Belgium from 45% to 55%.
You can set the function value as either “ENABLE_ROLLOUT” or “DISABLE_ROLLOUT” to enable or disable the staged rollout settings. If you disable the setting, you cannot change the value.
For this call to be successful, the appStatus field must be set. Setting it with the value “REGISTRATION” during an update indicates that the application content is being modified and prepared for submission.
PUT Operation
Send an HTTP PUT request for updating the staged rollout rate.
try: response = requests.put(api_url, headers=headers, json=payload) print("Status Code:", response.status_code) data_shows = response.json() print("Parsed JSON:", json.dumps(data_shows, indent=4)) except Exception as e: print("Error:", str(e)) Response on Success
A successful request returns the response “Ok”.
Status Code: 200 Parsed JSON: { "resultCode": "0000", "resultMessage": "Ok", "data": {} } After a successful response, Seller Portal UI looks like this:
Figure 2: Seller Portal UI after updating the staged rollout rate
Implementing the “View Staged Rollout Binaries” Endpoint
Before modifying which binaries participate in a staged rollout, you need to know the current state of the binary. This GET endpoint returns the list of binaries associated with a staged rollout for a given application, giving you the binarySeq values you need to take further action.
Application Information
To get application information, you only need the content ID and application status values.
# Content ID and parameters contentId = '<Content ID of your app>' appStatus= 'REGISTRATION' Here, appStatus can be set as either “REGISTRATION” or “SALE”, depending on which version you want to inspect.
API Endpoint
Define the api_url value, including the content ID and application status values, to get the staged rollout binaries.
# Defining the API endpoint (GET request) api_url=f"https://devapi.samsungapps.com/seller/v2/content/stagedRolloutBinary?contentId={Content_ID}&appStatus={appStatus}" GET Operation
Send an HTTP GET request to the Galaxy Store Server with the api_url and headers values.
try: response = requests.get(api_url, headers=headers) print("Status Code:", response.status_code) data_shows = response.json() print("Parsed JSON:", json.dumps(data_shows, indent=4)) except Exception as e: print("Error:", str(e)) Response on Success
This is the success response, after completing the above operation.
Status Code: 200 Parsed JSON: { "resultCode": "0000", "resultMessage": "Ok", "data": { "binaries": [ { "seq": 3, "versionCode": "7", "versionName": "1.1", "fileName": "App_20260202102640596.apk", "fileSize": "93.49", "rolloutStatus": "ENABLED", "appStatus": "REGISTRATION" } ] } } The response returns an array of binary objects, each containing the binarySeq identifier, version information, and whether the binary is currently included in the staged rollout. Keep a note of the binarySeq values, as you need them when calling the “Update the Staged Rollout Binary” endpoint.
NoteIf you do not know the binarySeq for a binary, you can also retrieve it by calling GET /seller/contentInfo?contentId=XXXXXXXXXXXX, which returns full application details including all registered binaries and their sequence numbers. Implementing the “Update the Staged Rollout Binary” Endpoint
This endpoint programmatically modifies the specific binary files associated with an active staged rollout, allowing developers to manage which version is being distributed. Using the API, the rollout status is set to either “ENABLED” or “DISABLED”, which refers to the “ADD” or “REMOVE” functions used to manage specific files within a release.
ENABLED (ADD): This function attaches a specific binary sequence to your staged rollout, making it active for the designated percentage of users.
DISABLED (REMOVE): This function disables a staged rollout immediately and makes that build available to all users globally.
API Endpoint
Define the API endpoint for changing the rollout status.
# Defining the API endpoint (PUT request) api_url= "https://devapi.samsungapps.com/seller/v2/content/stagedRolloutBinary" Payload
To change a specific application’s rollout binary, send its content ID, function value (“ADD” or “REMOVE”) and the binary sequence value inside a JSON payload.
# Payload (ADD or REMOVE binary to staged rollout) payload = { "contentId": "<Content Id of your app>", "function": "REMOVE", # or ADD "binarySeq": "3" } This code removes the specific binary from the list. You can check this modification from the Seller Portal UI.
Figure 3: Disabled staged rollout binary in the Seller Portal UI
PUT Operation
Send an HTTP PUT request to update the staged rollout binaries to the Galaxy Store Server.
try: response = requests.put(api_url, headers=headers, json=payload) print("Status Code:", response.status_code) data_shows = response.json() print("Parsed JSON:", json.dumps(data_shows, indent=4)) except Exception as e: print("Error:", str(e)) Response on Success
After a successful change of the rollout status from “ENABLE” to “DISABLE”, or vice versa, the operation returns a resultMessage with the value “Ok”.
Status Code: 200 Parsed JSON: { "resultCode": "0000", "resultMessage": "Ok", "data": {} } Response on Error
See the Failure response codes for a list of possible response codes when a request fails.
Key Cautions and Limitations
Samsung's official documentation makes several important constraints explicit that every seller needs to keep in mind:
The staged rollout rate cannot decrease for live applications. Once you set a rollout rate for a SALE version, the only valid options are increasing the rate or disabling the rollout entirely. In an application, only one staged rollout can be active at a time. You must disable an existing rollout before enabling a new one. Concurrent rollouts on the same content ID are not supported. The rules for binary contentStatus are very strict. The “Update the Staged Rollout Binary” endpoint only works when the application has a status of “REGISTERING”, “UPDATING”, “RE_REGISTERING”, or “READY_FOR_SALE”. The “FOR_SALE" status is not supported for this operation. The “DISABLE_ROLLOUT” action is irreversible in terms of exposure. Disabling a staged rollout immediately makes the current build available to all users globally. You cannot "re-stage" that release. Application review is still required. A staged rollout is only a distribution control mechanism and does not bypass the standard Samsung Galaxy Store review process. Applications must pass review before any users receive the update. Manual publication adds an extra step. If publicationType is set to “manual", even after passing review, you must call POST /seller/contentStatusUpdate with contentStatus: "FOR_SALE" to release the pending application. New application registration is not supported through the API. The Galaxy Store Developer API only manages applications that have already been registered in Seller Portal. First-time application submissions must begin in the Seller Portal web interface. The HTTPS protocol is mandatory for all API calls. HTTP requests are rejected. Conclusion
The Galaxy Store Developer API enables developers to manage application releases programmatically through staged rollouts. By integrating these APIs into your development workflow, you can improve release reliability, reduce manual effort, and enhance the overall user experience. Staged rollout management is essential for modern application delivery, empowering teams to scale effectively through automated and controlled release processes.
If you have any questions about or need help with the information in this article, you can reach out to us on the Samsung Developers Forum or contact us through Developer Support.
For additional reference you can check out the following resources:
How to Create an Access Token for the Galaxy Store Developer API Using Python: Learn how to create an access token using the Galaxy Store Developer API and Python. Set a Staged Rollout in the Seller Portal: Learn how to configure a staged rollout of applications in Seller Portal. Python Sample Source Code: Learn how to install Python on your PC and the setup for implementing these APIs. View the full blog at its source
-
By Samsung Newsroom
Health and fitness are the most popular features for Galaxy Watches running Wear OS powered by Samsung. Implementing these features requires a continuous data stream to work effectively and seamlessly.
One of the most common challenges third-party developers face is keeping a sensor like the heart rate monitor active, even when the watch screen is off.
By default, Wear OS efficiently optimizes power consumption to extend usage time. As part of this optimization, sensor data collection may stop when the screen is off. This presents a challenge for applications that require continuous monitoring, such as health trackers, workout assistants, or medical-grade wearables.
What Happens When the Screen Turns Off
When a Galaxy Watch screen turns off, the system enters a low-power state to preserve battery. During this time:
The CPU may slow down or suspend execution of background threads. Registered sensor listeners can stop receiving updates. Any active work in your Activity pauses. To keep sensor data flowing, your application needs two things:
A foreground service to keep your code running in the background. A wake lock to prevent the CPU from going into a deep sleep state. This tutorial shows how to create a simple Galaxy Watch application that continuously collects heart rate data, even when the screen is off, using a foreground service and a wake lock and all the code examples are provided in a downloadable sample application.
Let's Start Coding
Step 1: Create a New Wear OS Project
Open Android Studio and create new project from scratch:
Go to File > New > New Project > Wear OS Tab > Empty Wear App. Fill in the project details in the New Project window.
Figure 1: Create a new wearable application in Android Studio
Click Finish and wait for Gradle sync to complete. Step 2: Configure Permissions in AndroidManifest.xml
In the AndroidManifest.xml file, add the following permissions to access the heart rate sensor, foreground service, and wake lock.
<uses-permission android:name="android.permission.BODY_SENSORS" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE_HEALTH" /> <uses-permission android:name="android.permission.WAKE_LOCK" /> <uses-permission android:name=" android.permission.BODY_SENSORS_BACKGROUND " /> <uses-feature android:name="android.hardware.type.watch" /> NoteThe BODY_SENSORS_BACKGROUND permission is required on Android 12 (API 31) and above for collecting sensor data when the application is not in the foreground. Register the SensorService in the manifest:
<service android:name=".SensorService" android:enabled="true" android:exported="false" android:foregroundServiceType="health" /> NoteIf you forget foregroundServiceType="health" in the manifest, your application will crash with a SecurityException on Android 10 (API 29) and above when trying to read sensors from a foreground service. Step 3: Design Your Watch UI Layout
The watch UI can be designed entirely according to your preference. In this content, only two buttons have been used to start and stop the service and a TextView to show the result to keep it simple. Wear OS screens are small, so keeping the layout simple is the best practice.
To implement the UI, edit app/res/layout/activity_main.xml.
The following code implements a sample UI:
<?xml version="1.0" encoding="utf-8"?> <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" android:padding="16dp" tools:context=".MainActivity" tools:deviceIds="wear"> <LinearLayout android:layout_width="match_parent" android:layout_height="match_parent" android:gravity="center" android:orientation="vertical"> <TextView android:id="@+id/heart_rate_text" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="--" android:textColor="#90EE90" android:textSize="24sp" android:layout_marginBottom="16dp"/> <Button android:id="@+id/start_button" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/start_sensors" /> <Button android:id="@+id/stop_button" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_marginTop="8dp" android:text="@string/stop_sensors" /> </LinearLayout> </androidx.constraintlayout.widget.ConstraintLayout> Step 4: Edit MainActivity.java
Inside MainActivity.java, sensor permissions must be requested at runtime.
onCreate() :
You need to initialize all the UI components inside the onCreate() method. This example uses two Button instances, for starting and stopping the service, and one TextView , for showing the result. Before staring the service, you have to check all the runtime permissions.
heartRateTextView = findViewById(R.id.heart_rate_text); //initialize globally to use it outside of the method Button startButton = findViewById(R.id.start_button); Button stopButton = findViewById(R.id.stop_button); if (startButton != null) { startButton.setOnClickListener(v -> { if (checkPermissions()) { if (checkBackgroundPermission()) { startSensorService(); } else { requestBackgroundPermission(); } } else { requestPermissions(); } }); } if (stopButton != null) { stopButton.setOnClickListener(v -> stopSensorService()); } In this application, when the user taps the start button, the application checks both permissions in sequence, and the stop button stops the service.
NoteOn Android 11 (API 30) and above, BODY_SENSORS_BACKGROUND must be requested as a separate step after foreground sensor permission is granted. The system does not grant this permission automatically.
checkPermissions() :
This method checks at runtime whether the BODY_SENSORS permission has been granted. On Galaxy Watch, the user must explicitly grant this permission on their device.
private boolean checkPermissions() { return ContextCompat.checkSelfPermission(this, Manifest.permission.BODY_SENSORS) == PackageManager.PERMISSION_GRANTED; }
checkBackgroundPermission() :
This method checks for the BODY_SENSORS_BACKGROUND permission, which is essential for Wear OS 3+ devices (like Galaxy Watch 5, 6, 7) to access sensor data in all power states.
private boolean checkBackgroundPermission() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { return ContextCompat.checkSelfPermission(this, Manifest.permission.BODY_SENSORS_BACKGROUND) == PackageManager.PERMISSION_GRANTED; } return true; }
startForegroundService() :
On Android 8 (Oreo) and above, you must call this method instead of startService() when starting a foreground service.
private void startSensorService() { Intent intent = new Intent(this, SensorService.class); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { startForegroundService(intent); } else { startService(intent); } Toast.makeText(this, "Sensor Service Started", Toast.LENGTH_SHORT).show(); }
stopSensorService() :
Once the task is completed, call this method to reduce battery drain.
private void stopSensorService() { Intent intent = new Intent(this, SensorService.class); stopService(intent); if (heartRateTextView != null) { heartRateTextView.setText("--"); } Toast.makeText(this, "Sensor Service Stopped", Toast.LENGTH_SHORT).show();
requestPermissions() :
This method prompts the user for the BODY_SENSORS permission before starting the service.
private void requestPermissions() { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.BODY_SENSORS}, PERMISSION_REQUEST_CODE); }
requestBackgroundPermission() :
This method prompts the user for the BODY_SENSORS_BACKGROUND permission. Since the sample application targets Android 13 (API level 33) or higher (currently set to 34), this permission is required if you want to access sensor data in the background, even when using a foreground service. Without it, the system can restrict or stop sensor data delivery when the application is not in the immediate foreground for an extended period.
private void requestBackgroundPermission() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { Toast.makeText(this, "Please allow 'All the time' sensor access in settings",Toast.LENGTH_LONG).show(); // On API 30+, background permission MUST be requested separately and // the user must be directed to settings manually in many cases, or through a system dialog. ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.BODY_SENSORS_BACKGROUND}, BACKGROUND_PERMISSION_REQUEST_CODE); } } Override the onRequestPermissionsResult() method to handle the user's response to each permission request:
@Override public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) { super.onRequestPermissionsResult(requestCode, permissions, grantResults); if (requestCode == PERMISSION_REQUEST_CODE) { if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) { if (checkBackgroundPermission()) { startSensorService(); } else { requestBackgroundPermission(); } } else { Toast.makeText(this, "Permission denied to read sensors", Toast.LENGTH_SHORT).show(); } } else if (requestCode == BACKGROUND_PERMISSION_REQUEST_CODE) { if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) { startSensorService(); } else { Toast.makeText(this, "Background permission denied. Data collection may stop when app is not in foreground.", Toast.LENGTH_LONG).show(); // Optionally start service anyway, knowing it might be limited startSensorService(); } } } Even if the background permission is denied, the service is started. This allows heart rate collection to continue while the application is visible, though data collection may pause when it moves to the background.
BroadcastReceiver:
Send an intent with the heart rate value to update the UI components in real time. This should be outside of the onCreate() method.
private final BroadcastReceiver heartRateReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { if (SensorService.ACTION_HEART_RATE_UPDATE.equals(intent.getAction())) { float heartRate = intent.getFloatExtra(SensorService.EXTRA_HEART_RATE, 0); if (heartRateTextView != null) { heartRateTextView.setText(String.format(Locale.getDefault(), "%.0f", heartRate)); } } } };
onResume() :
Register a BroadcastReceiver inside this method to catch updates and display them in a TextView element.
@Override protected void onResume() { super.onResume(); IntentFilter filter = new IntentFilter(SensorService.ACTION_HEART_RATE_UPDATE); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { registerReceiver(heartRateReceiver, filter, Context.RECEIVER_NOT_EXPORTED); } else { registerReceiver(heartRateReceiver, filter); } }
onDestroy() :
This method stops the service when the activity is destroyed, preventing a dangling service.
@Override protected void onDestroy() { stopSensorService(); super.onDestroy(); }
Step 5: Edit SensorService.java
This is the core of the tutorial. SensorService is a foreground service that registers a heart rate sensor listener and acquires a wake lock to keep the CPU active when the screen turns off.
onCreate() :
Initialize the SensorManager instance and request the wake-up sensor. Here, do not use the default sensor. Instead, request the wake-up version:
sensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE); if (sensorManager != null) { // Attempt to get the wake-up version of the sensor heartRateSensor = sensorManager.getDefaultSensor(Sensor.TYPE_HEART_RATE, true); if (heartRateSensor == null) { Log.i(TAG, "Wake-up heart rate sensor not available, falling back to non-wake-up."); heartRateSensor = sensorManager.getDefaultSensor(Sensor.TYPE_HEART_RATE); } } Standard sensors stop sending data when the screen turns off. The true parameter ensures the sensor can wake up the processor to deliver data even in deep sleep.
onStartCommand() :
Execute the foreground service notification.
Promoting your service to the foreground is mandatory for the tracking to stay alive. This prevents Galaxy Watch from pausing your application after 60 seconds of screen-off time.
Promote Immediately: In onStartCommand(), promote the service to the foreground immediately to satisfy Android’s background limitations.
Build the Notification: Create a persistent notification that informs the user that heart rate tracking is active.
Specify Service Type: Android 10+ requires the FOREGROUND_SERVICE_TYPE_HEALTH type for health sensors.
Register Listener: Register the sensor listener to begin receiving heart rate events.
Check the code here:
@Override public int onStartCommand(Intent intent, int flags, int startId) { Notification notification = new NotificationCompat.Builder(this, CHANNEL_ID) .setContentTitle(getString(R.string.sensor_notification_title)) .setContentText(getString(R.string.sensor_notification_text)) .setSmallIcon(android.R.drawable.ic_menu_info_details) .setPriority(NotificationCompat.PRIORITY_DEFAULT) .build(); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { startForeground(1, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_HEALTH); } else { startForeground(1, notification); } if (heartRateSensor != null) { sensorManager.registerListener(this, heartRateSensor, SensorManager.SENSOR_DELAY_UI); Log.d(TAG, "Heart rate sensor registered."); } else { Log.e(TAG, "Heart rate sensor not available."); } return START_STICKY; }
onSensorChanged() :
To process sensor data and broadcast updates, implement this method to handle the actual data.
Capture Value: Extract the heart rate from event.values[0].
Broadcast Result: Send a local broadcast with the heart rate value so your UI components can update in real-time.
Here is the code:
@Override public void onSensorChanged(SensorEvent event) { if (event.sensor.getType() == Sensor.TYPE_HEART_RATE) { float heartRate = event.values[0]; Log.d(TAG, "_________Heart Rate: " + heartRate); // Broadcast the result to update the UI Intent intent = new Intent(ACTION_HEART_RATE_UPDATE); intent.putExtra(EXTRA_HEART_RATE, heartRate); intent.setPackage(getPackageName()); // Ensure only this app receives the broadcast sendBroadcast(intent); } }
onDestroy() :
In this method, unregister the sensor listener to prevent excessive battery drain after the user is finished.
@Override public void onDestroy() { if (sensorManager != null) { sensorManager.unregisterListener(this); //Stop sensor } Log.d(TAG, "Sensor service destroyed and listener unregistered."); super.onDestroy(); } Step 6: Download the Sample Application
You may download the final projects here:
SensorReadConExample (556.0 KB) 04/23/2026 Step 7: Run the Sample Application on Galaxy Watch
To run the sample application on a Galaxy Watch:
Connect Galaxy Watch to Android Studio over Wi-Fi. Run the sample application on your device. Tap START SENSORS and grant the sensor permission when prompted. When you see the second prompt (or toast), go to the System Settings > Apps > Permissions > Sensors and select All the time. Once granted, the data collection continues even if you close the application UI or the watch screen goes dark.
When the screen turns off, heart rate logs continue in Android Studio Logcat. Tap STOP SENSORS when you want to stop data collection. This stops the service.
Figure 2: Sample application output on a real device
Figure 3: Data collection output in Logcat
In Logcat, filter by the SensorService tag to see the collected heart rate readings. New readings arrive even while the watch screen is off.
NoteYou need to wear the watch to read the heart rate data. Otherwise, it shows 0.0 as the value. Conclusion
Following the steps above, you can build a Galaxy Watch application that collects heart rate data continuously—even when the screen turns off. This same approach applies to other sensors as well, allowing you to read any sensor data continuously in the background.
If you have any questions about or need help with the information in this article, you can reach out to us on the Samsung Developers Forum or contact us through Developer Support.
View the full blog at its source
-
By Samsung Newsroom
Samsung Wallet, Aliro Locks, and SmartThings turn a simple tap into total home control
What if getting into your home didn’t require fumbling for keys, digging through bags, or wondering whether you locked the door on your way out? With the Samsung Wallet, SmartThings and Aliro-certified smart locks from trusted brands like Aqara, Nuki, ULTRALOQ, and Schlage, your Galaxy phone can become your new door key, unlocking a smarter, safer, and more convenient home experience.
Now available on Samsung.com, Aliro-certified locks integrate with SmartThings and Samsung Wallet, giving you tap-to-unlock access, remote control, and powerful home automations that start the moment you walk through the door.
Tap to Unlock. Walk Right In.
Ever arrive home from a run with nowhere to stash your keys?
Instead of slowing down, soon you can simply tap your Galaxy phone on your smart lock. The door unlocks instantly, no physical keys required. Samsung Wallet securely stores your digital keys, while SmartThings keeps everything connected behind the scenes. It’s a simple gesture that makes everyday routines feel effortless.
Unlocking your door can trigger far more than just entry. When paired with SmartThings and a compatible hub, Aliro-certified smart locks can become the starting point for your entire home:
Lights turn on as you step inside Thermostat adjusts to your preferred temperature Security cameras shift modes Alarms disarm and re-arm automatically Heading out? Lock the door from your phone when you leave and SmartThings takes care of the rest, shutting off lights or securing devices so you can leave with peace of mind.
Designed for Real-Life Moments
Technology should make life easier, especially in the moments that matter most.
Active lifestyles: Going for a run or walking the dog? Leave your keys behind. Your Galaxy has you covered.
Locked-out scares: Step outside to take out the trash and hear the door click shut? No panic required, tap your phone and get back in.
Family members: Share secure digital keys with family members through Samsung Wallet, and use SmartThings to manage alarms and routines while they’re inside. Members added to SmartThings can use a designated pin as well to use the features.
Built for What’s Next: Aliro-Certified Smart Locks
Samsung’s tap-to-unlock experience is powered by Aliro Home Key certification, an industry standard created to make digital access to your home more secure, reliable, and interoperable across devices.
Aliro-certified smart locks are designed to work seamlessly with Galaxy phones through Samsung Wallet, delivering consistent tap-to-unlock access whether you’re coming home from work, heading out for a run, or letting in a guest remotely.
And this ecosystem is growing.
Samsung is partnering with a broad range of Aliro-certified lock makers, including Aqara, Nuki, ULTRALOQ, and Allegion brands like Schlage, giving homeowners more flexibility and choice when upgrading their front door.
That means confidence today and peace of mind that your home is ready for what comes next.
How to Set Up an Aliro-Certified Lock with Galaxy
Getting started is easier than you might think.
Step 1: Install Your Aliro-Certified Lock
Follow the manufacturer’s instructions to physically install your lock.
Step 2: Add the Lock in the SmartThings App
Open the SmartThings app. Tap Add device and follow the on-screen prompts to connect your lock.
Step 3: Add Your Digital Key to Samsung Wallet
Once connected, you’ll receive the option to add your home key to Samsung Wallet. Confirm and authenticate, your Galaxy phone is now your key.
Step 4: Test Tap-to-Unlock
Hold your Galaxy phone near the lock. Tap. Unlock. Done. Want a Routine to try? Try This!
Routine Name: “I’m Home!”
Trigger: When front door unlocks
Actions:
Turn on entryway and living room lights Adjust thermostat to comfort setting Disarm security system Turn on Samsung TV Plus automatically Now your home responds automatically the moment you walk in.
You can customize this routine for mornings, evenings, guests, or even specific users.
Ready to upgrade?
Shop the Aliro-compatible smart locks, Galaxy Devices, and SmartThings hubs now on Samsung.com and fully unlock your home’s potential.
View the full blog at its source
-
By Samsung Newsroom
Emulator skins for the newly released Galaxy S26 series (S26, S26+, and S26 Ultra) are now available for download. Get the chance to test your apps on Android virtual devices that replicate the refined design of the latest flagship phones.
To utilize the emulator skins for the Galaxy S26 series, you will need the following: Android Studio and Android SDK, with at least one platform installed under Android SDK > Platform.
For detailed instructions, refer to Using a Galaxy Emulator Skin.
View the full blog at its source
-
-
By Samsung Newsroom
Starting in 2026, Samsung will enhance its Auto Blocker feature on Galaxy phones and tablets running Android to provide users with greater flexibility while maintaining strong security protections. With this update, users will be able to directly install third-party Android app stores and their apps without Auto Blocker preventing installation, as long as the stores meet certain security and compliance requirements.
Auto Blocker is a sophisticated security tool designed to give users more control over their device protection, primarily by preventing app installations from unauthorized sources. This upcoming enhancement builds on that foundation by supporting additional app distribution channels, while continuing to apply platform protections across the broader Galaxy security framework.
Further details will be announced and implemented later this year.
View the full blog at its source
-
-
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.