Audio cues on the wrist: Wear OS speakers, Bluetooth, and Apple Watch workout sessions

On a phone, the audio question is how to share the channel with the user's music. On a watch, there is an earlier question: where does the sound come out? Google's Wear OS guide says "Most Wear OS devices have built-in speakers," earbuds can be paired straight to the watch, and the two platforms draw the line between speaker and headset in different places.

This page covers audio output for workout cues on Wear OS and Apple Watch. Running the workout itself belongs to watch apps: HKWorkoutSession lifecycle on watchOS and the ExerciseClient walkthrough on Wear OS.

Wear OS: find out what outputs exist#

Google's Play audio on wearables guide starts with detection: "A Wear OS app must first detect if the wearable device has an appropriate audio output." Wearables "typically have at least one of" these outputs:

• AudioDeviceInfo.TYPE_BUILTIN_SPEAKER, "on devices with a built-in speaker"
• AudioDeviceInfo.TYPE_BLUETOOTH_A2DP, "when a Bluetooth headset is paired and connected"
• AudioDeviceInfo.TYPE_BLE_BROADCAST, TYPE_BLE_HEADSET and TYPE_BLE_SPEAKER for Bluetooth Low Energy devices

fun audioOutputAvailable(type: Int): Boolean {
    if (!packageManager.hasSystemFeature(PackageManager.FEATURE_AUDIO_OUTPUT)) return false
    return audioManager.getDevices(AudioManager.GET_DEVICES_OUTPUTS).any { it.type == type }
}

That is Google's sample, lightly trimmed: check FEATURE_AUDIO_OUTPUT, then look for the device type among the outputs.

Wear OS: cues may use the speaker, media should not#

The guide separates media from everything else. For media: "To provide the best user experience, only play media when Bluetooth headphones or speakers are connected to the watch." And: "Built-in speakers don't deliver the optimal experience for listening to media content because they aren't designed for this purpose."

For non-media sound, the guide is permissive, and it names our use case: "If your app offers a non-media use case that uses sound, consider using speakers to offer an extra dimension of engagement. For example, a speaker-equipped Wear OS device might trigger a clock or timer alarm with an audio notification, and fitness apps might use the speaker to provide exercise instructions."

Wear OS: when the headset comes and goes#

Bluetooth headsets connect and disconnect mid-run. Google: "If your app requires a headset to continue, register a callback to detect when the user connects and disconnects a Bluetooth headset using registerAudioDeviceCallback." Its sample checks the A2DP and BLE types in onAudioDevicesAdded and onAudioDevicesRemoved.

When there is no headset and the user wants media, Google is specific about tone: "don't show an error message. Instead, offer to take the user directly to Bluetooth settings," using Settings.ACTION_BLUETOOTH_SETTINGS. "Starting with Wear OS 5, the system provides a UI that lets users choose which device plays media," and Google suggests offering that media output switcher where it is available.

Wear OS: stop media leaking out of the speaker#

For apps that play media through ExoPlayer, Google documents a guard: call setSuppressPlaybackOnUnsuitableOutput(true) while building the player, and add WearUnsuitableOutputPlaybackSuppressionResolverListener as a listener. Google also notes that if you target Android 15 or higher, "the media output switcher provides the watch's built-in speakers as one of the selectable options on supported Wear OS devices," and that supporting this with ExoPlayer needs "version 1.5.0 or later."

val exoPlayer = ExoPlayer.Builder(context)
    .setAudioAttributes(AudioAttributes.DEFAULT, true)
    .setSuppressPlaybackOnUnsuitableOutput(true)
    .build()
exoPlayer.addListener(WearUnsuitableOutputPlaybackSuppressionResolverListener(context))

For other players, Google's list is plain: start media only when a suitable output is connected, pause if it disconnects, and prompt the user to connect one if they try to play without it. Once a suitable output is chosen, "playing audio on Wear OS is the same as on mobile," including "managing audio focus," which is covered on the MAY_DUCK page.

Apple Watch: cues belong to the workout session#

Apple's Running workout sessions article makes the session the gate. "Workout sessions require the Workout processing background mode. If your app plays audio or provides haptic feedback during the workout session, you must also add the Audio background mode." Apple says to "Use the AVAudioPlayer class to play short audio clips," and notes that workout apps "can use the AVFoundation framework to play short audio clips in the background, such as coaching or notifications. In order to play an audio clip, an active workout session must be running; any attempt to play background audio outside a workout session are invalid." The same article lists, among what a session gives you: "Your app can alert the user using audio or haptic feedback while running in the background."

Apple's Playing audio guidelines describe the watch in two modes: "An app can play short audio clips while it's active and running in the foreground, or it can play longer audio that continues even when people lower their wrist or switch to another app."

Apple Watch: long-form audio needs Bluetooth#

For the second mode, Apple's Playing Background Audio article sets the session category to playback with the route-sharing policy .longFormAudio, then activates asynchronously:

try session.setCategory(.playback, mode: .default, policy: .longFormAudio, options: [])
try await session.activate()

Apple: "watchOS requires a Bluetooth audio route for long-form audio. If necessary, the system presents an audio route picker to the user." And: "If no applicable Bluetooth route is selected (either automatically or by the user), the system passes an error to the completion handler." So a guided run on the watch has to handle the no-headphones case as an error path, not a crash and not a silent failure.

The two platforms side by side#

Our judgement for both: on the wrist, a cue is often better as a haptic than as a sound, because the device is touching the skin. The wrist is where haptics as a second channel make the most sense, so the default should be haptic plus optional voice, not the reverse.

Monday morning#

On Wear OS, detect outputs at workout start, route short cues to whatever is available, and keep media behind a Bluetooth check with a route to settings rather than an error. On watchOS, confirm the Audio background mode is present next to Workout processing, that cue clips only play while the session is running, and that any long-form audio handles the no-Bluetooth error. Then run a workout on each watch with no earbuds paired.