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.

Review the principles below before you start building your Wear OS app to optimize your development time.

Note: The API level 30 Wear OS emulator system image is currently in Developer Preview. See release notes for the latest updates.

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 your app's full experience called an overlay.

surfaces use cases

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.

Complication

P1: What’s the weather right now?

Notification

P1 Tell me about a severe weather advisory

Tile

P1: What’s the weather right now?

P2: What’s the weather today?

Overlay

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.

surfaces

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 make sense for your app.

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.

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 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 a wake lock and the AmbientModeSupport. For more information, see Keep your app visible on Wear.

To use AmbientModeSupport effectively:

Don't hold a wake lock

Don't hold a wake lock unless you are using it with always-on.

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 senors, follow the best practices recorded at Detect location on Wear OS.

Use hardware buttons

Users expect to press buttons on the watch to control their workouts, such as to start, stop, or pause their workout. Offer the option if buttons are available.

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 (or put your app in "wet-mode") when tracking a swimming workout, because accidental touch is very likely in this case.

For more information, see Wet mode.

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.