Principles of Wear OS development

Wear OS is based on Android, so many of the best practices for Android also apply to Wear OS. However, Wear OS is optimized for the wrist, so there are some differences between the two.

To optimize your development time, review the principles below before you start building your Wear OS app.

Note: New Wear OS quality requirements will come into effect August 31, 2023. For a full list of requirements, see Wear OS app quality.

Design for critical tasks

Focus on one or two needs of your target users rather than a full app experience. Don't migrate an entire mobile codebase and put a Wear OS user interface on top.

Instead, find critical tasks that work well on the wrist and streamline the experience on Wear OS.

app samples

Optimize for the wrist

Help people complete tasks on the watch within seconds to avoid ergonomic discomfort or arm fatigue.

Review the Wear OS design guidelines to learn more about optimizing for the wrist.

timer sample

Use the appropriate surface for the task

Wear OS has many more surfaces than mobile to engage users. Apps should tailor their content for those surfaces.

Each surface has its own use case. If more action is required, direct users into a fuller app experience.

Read and understand how your content scales across each surface according to the priority of user needs. Following is an example of priorities for a weather app.


P1: What’s the weather right now?


P1 Tell me about a severe weather advisory


P1: What’s the weather right now?

P2: What’s the weather today?


P1: What’s the weather right now?

P2: What’s the weather today?

P3: What’s the hourly breakdown?

P3: Preferences

weather tile

To learn more, read our User Interface Guide.

Add notifications to additional surfaces

In Wear OS API level 30 and higher, pair any ongoing notification to an OngoingActivity to add that notification to additional surfaces within the Wear OS user interface to increase engagement with long running activities.

Support offline scenarios

While a Wear OS device generally supports Bluetooth and Wi-Fi, it might not support LTE. Design for spotty connections and offline use cases, such as exercising and commuting, when a user may leave their mobile device at home.

offline examples

Provide relevant content

The watch is almost always with the user. Keep your app content updated with the user's context, such as their time, place, and activity.


Aid users in completing a task from another device

People increasingly own multiple devices. The watch can aid people in completing a task across a distributed ecosystem of devices. Review use cases where this makes sense for your app.

Improve user experience during an app cold start

To improve user experience during an app cold start, create a splash activity with a separate theme and set its windowBackground to your custom splash drawable in the manifest file. The splash screen is made up of a layer-list with two elements, the background color and the custom drawable that is typically your app icon. The drawable should be 48 x 48dp.

Considerations for media apps

Enable playback controls for music from the phone

If your app is installed on both the phone and watch, users expect to have remote controls from their watch. For example, users expect the ability to pause, play, or skip songs from their watch.

Downloaded content

As called out earlier, it is important to support offline scenarios. This is especially important for media apps. For media apps, it is easier to support offline downloads first, then to add streaming ability if you see the demand.

When designing, make it clear to the user what content is available offline. For any long-running immediate or periodic tasks, use WorkManager. Defer downloads until the watch is charging and connected to Wi-Fi.

Streaming on LTE

Consider offering streaming support on devices that have LTE connectivity, a common use case for media playback. Streaming allows users to leave their other devices at home and still listen to music. Make sure to visually communicate to the user when they are streaming music and cache streamed audio. Avoid using LTE for any jobs that could be deferred, such as sending logging and analytics data, to optimize power usage while streaming.

Support Bluetooth headphones

Users may take only their watch and headphones out for a run or walk. Enable them to have a true standalone experience by supporting pairing with headphones. If headphones are not connected when playing or resuming music, launch Bluetooth settings to allow the user to connect to their Bluetooth headphones directly from the app.

Indicate music source

Clearly indicate whether the sound is coming from the watch or the phone. Use a source icon to indicate where the music is playing. The default source should be where the user starts the music.

Using the speaker

Some Wear OS devices include a built-in speaker which can be used for things like reminders and alarms. Avoid using the built-in speaker for playing media and music, as users expect these experiences to be tied to using headphones. For more information, see Detecting audio devices.

Considerations for fitness apps

When creating fitness apps for Android 10 and higher, request the Physical activity recognition permission.

Complement the mobile app

As outlined above, a Wear OS fitness app should handle only critical tasks for the wrist. This means a fitness Wear OS app will mostly focus on data gathering.

While you can allow some post-workout summary screens, leave detailed post-workout analysis, and any other features that require more screenspace to the mobile app.

Support long-lived activities

Like many apps that subscribe to location and sensor data, design your app to handle running while-in-use. This means your app should function in the foreground.

If the workout starts in an activity, bind that activity to a service that will do the work. When the user navigates away from your app, the service will unbind and can promote itself to an ongoing notification.

In Wear OS, you can expose your Ongoing Notifications to new surfaces with the Ongoing Activity API using a minimal amount of code.

Review the Ongoing Activity code lab on GitHub to see a simplified app with this architecture.

Use always-on sparingly

If a user stops using their watch during a session with your app, the device will eventually go into system ambient mode to save battery.

Wear OS will bring that app back to an active state if the user interacts with the device again within a specified amount of time.

For most use cases, this should be enough for user to have a good experience and save battery life.

In some cases, you may need your app to be visible for longer, such as during an entire workout. For those cases, you will need to use AmbientLifecycleObserver. For more information, see Keep your app visible on Wear.

Don't hold a wake lock

Use APIs such as Health Services to obtain sensor data, while allowing the CPU to sleep between readings or delivery.

Optimize location and sensor management

Sensor management is very important and can impact battery life negatively if not done properly.

Make sure you follow these recommendations when implementing your sensor strategy:

  • Always use sensors in batch mode where possible.
  • Flush sensors when the screen/app becomes active again.
  • Change the length of batching when the screen goes off to conserve power.
  • Unregister sensor listeners when they are no longer needed.
  • For location sensors, follow the best practices recorded at Detect location on Wear OS.

Use haptics to confirm actions

Use haptic feedback to confirm actions, such as start, stop, auto-pause, or auto-lap.

Use touch lock

In some cases, disabling the touch experience improves the app experience. For example, it makes sense to disable touch when tracking a workout, because accidental touch is very likely in this case.

Considerations for messaging apps

Start with notifications

Support MessagingStyle to improve your user's app experience.

Support voice input

Make sure to support speech-to-text, as it's much faster on a watch. You may also want to support recorded audio as well.