Mastering Android Wear: Communication, Health Data, and UI Tips for Developers

On March 19, 2014 Google launched Android Wear, a smartwatch platform positioned as a phone companion that can collect richer health data and display messages more quickly.

1. Communication

Android Wear uses Bluetooth 4.0 (BLE) to communicate with the phone, with Google wrapping the Bluetooth layer in the GoogleApiClient and offering three APIs: MessageApi, DataApi, and ChannelApi.

MessageApi works like a broadcast and requires the target node ID.

DataApi behaves like a shared queue; no node ID is needed, just place data into the queue.

ChannelApi is used for large files (e.g., movies, music) and provides point‑to‑point transfer.

WeChat combines MessageApi and DataApi: data larger than 100 KB uses DataApi's Asset or ChannelApi; data smaller than 100 KB uses MessageApi, which offers reliable delivery confirmation.

The original peer‑to‑peer model treats Phone and Wear as equal clients, each needing listeners and handlers, which works for small projects but scales poorly. The improved model adopts a client‑server approach, categorizing communications into short requests (single request/response), long requests (multiple requests/one response), and server‑to‑client pushes.

Each transmission uses a unified data packet with a header (defining parsing) and payload (business data), identified by a unique ID.

2. Health Data

Because a watch is close to the body, health features are essential. WeChat currently collects two health metrics: step count and heart rate.

Step count returned by stepCount is cumulative; to obtain today’s steps, record the total at midnight and subtract it from the next day's total.

Heart rate accuracy has three levels; choose based on your needs.

Both phone and watch must request the appropriate permissions to access health data.

3. Message Notifications

Android Wear syncs phone notifications to the watch, but actions are limited and cannot use watch resources such as microphone or storage.

Phone apps can support Wear notifications in two ways:

Attach a WearableExtender to the phone’s Notification to add special actions for the watch.

Transfer data to the watch and create a local Notification, allowing full use of watch resources.

The second method enables recording audio via AudioRecord, but recording cannot start during a left‑swipe gesture because the resource is held by Google; you must launch a dedicated Activity.

Wear notifications do not support RemoteView but do support Embedded Activities, though they have many restrictions (e.g., scrolling can trigger notification switches, icons may not react as expected, background cannot be transparent). Images and ImageSpan are not displayed, but Unicode emoji are supported.

Text input is provided through RemoteInput, which invokes Google’s speech‑to‑text UI and returns the transcribed text.

4. User Interface

Wear UI must adapt to both round and rectangular watches. Google offers RoundLayout and RectLayout for static adaptation; for dynamic adaptation, an API can query the current watch shape at runtime.

By passing the appropriate layout as the Activity’s content view, the app can dynamically adjust to the watch’s shape.

5. Performance and Tips

Offload heavy calculations to the phone; keep the Wear app focused on display.

Release sensors promptly to conserve battery; the watch enters sleep mode when idle.

Cache only essential data on the watch; fetch most data from the phone as needed.

Ensure all required permissions are declared on both phone and watch; missing permissions prevent the Wear app from installing.

Sign the Wear app with the same certificate as the phone app.