Wear OS Platform

Google's Android-based operating system for smartwatches. It is AOSP (Linux kernel, HALs, Binder, ART, system_server) with a wearable framework layer (Tiles, complications, watch faces, ambient mode, Health Services, the Wearable Data Layer) and a watch-specific UI, running on a wearable SoC that usually has an application processor plus an always-on co-processor.

The foundation is the same: kernel, BSP, HALs over Binder, Zygote, system_server, ART, SELinux, Treble, verified boot and A/B updates. The deltas are:

• A dual-processor design: AP plus an always-on co-processor / sensor hub.
• A wearable framework layer: Tiles, complications, watch faces, ambient mode, ongoing activities.
• Health Services over a batched, offloaded sensor stack.
• A companion and Data Layer sync model with the phone.
• Much tighter RAM, flash and battery budgets, more aggressive Doze and memory killing, and a Wear GMS subset.

The integration discipline is identical; the constraints and KPIs are tighter.

The battery is roughly a tenth of a phone's, yet users expect time, notifications, steps and heart rate 24/7, plus multi-day battery. A few extra milliamps of average current can cost a day. So every feature is judged by how much it keeps the AP awake, and always-on work must move to the co-processor.

A low-power microcontroller or DSP, separate from the Cortex-A application processor, with its own memory and power domain. It runs step counting, continuous heart-rate sampling, sensor fusion, wrist-raise and gesture detection, off-body detection, sensor batching and parts of the always-on display, and on some designs Bluetooth keep-alive or a small RTOS UI. It wakes the AP only when needed.

The always-on display state. The face is dim, mostly black, uses few colors and updates about once a minute, while the AP is mostly suspended. Faces provide an ambient variant; burn-in protection shifts pixels and avoids large bright areas. Wrist-raise, a tap or a button returns to interactive mode.

A swipeable, glanceable card next to the watch face (weather, timer, workout start). The app's TileService returns a layout and resources; the system renders it and requests new layouts on a freshness schedule or when the app asks for an update. No app process needs to stay running.

A small data slot on the watch face, such as steps, battery, weather or next event. A complication data source service provides typed data (short text, long text, ranged value, goal progress, images); the face renders it. Updates come on a declared period or when the data source pushes an update request.

Tiles are full-screen glanceable cards you swipe to, with information and simple actions, without launching an app. Complications are tiny data slots embedded in the watch face. Notifications are alerts in a vertical stream, bridged from the phone or posted on the watch, with actions and replies. Tiles and complications are system-rendered and cheap; notifications cost a wakeup and often a vibration.

A declarative XML format (introduced with Wear OS 4) for watch faces. The face is a package of XML and resources that the system watch-face renderer draws, binding to time, sensor values and complications. No app code runs, which saves power, improves stability and security, and lets the system optimize ambient rendering. It is the direction for all new faces.

PPG (optical heart rate, heart-rate variability, SpO2), accelerometer, gyroscope, magnetometer, barometer, ambient light, skin temperature, off-body or skin-contact detection, GNSS, and on some models ECG electrodes and bioimpedance.

Photoplethysmography. LEDs (green for heart rate, red and infrared for SpO2) shine into the skin and photodiodes measure reflected light. Blood volume changes with each heartbeat, so the signal pulses at the heart rate. Motion causes artifacts, so accelerometer data is used to clean the signal.

A Wear OS system service and API for health and fitness data. It exposes ExerciseClient (workouts), PassiveMonitoringClient (all-day data) and MeasureClient (spot checks), reports device capabilities, and handles sensor batching and offload to the hub so apps do not have to read raw sensors.

Health Services runs sensing and algorithms on the sensor hub and delivers batched results, so the AP sleeps between bursts. It also coordinates multiple apps (one exercise at a time), provides consistent calibrated metrics across devices, and handles permissions. Direct high-rate raw sensor access bypasses batching and drains the battery.

The phone app (OEM or Google's Wear OS app) used to pair the watch, run setup, transfer accounts, manage settings and watch faces, and bridge notifications. Individual developers can also ship a phone app that pairs with their watch app via the Data Layer.

The Google Play services API that connects apps on the phone and watch (and the cloud). It provides DataClient (synced DataItems and Assets), MessageClient (one-way messages), ChannelClient (streams and files), CapabilityClient (feature discovery) and NodeClient (connected devices), over Bluetooth, Wi-Fi or a cloud relay. It is not present on builds without Play services.

Over Bluetooth (BLE and Classic) by default. When the phone is out of range the watch can use Wi-Fi, and data can be relayed through the cloud via the user's account. LTE watches can work fully without the phone.

An embedded UICC (eUICC) chip soldered on the board that stores carrier profiles downloaded over the air. Watches have no room for a SIM tray and need water resistance, so eSIM is the only practical option.

No, the chain is the same idea: boot ROM, firmware loaders, kernel, init, Zygote, system_server, launcher and watch face. PBL then XBL then ABL are Qualcomm loader names; other vendors use U-Boot or their own. The wearable differences are co-processor firmware loading and coordination, a smaller image, and a stronger focus on fast resume and power during boot. See Android Boot.

The watch app declares com.google.android.wearable.standalone true and can run its core features without the phone. It still may have a companion for setup and Health Connect. If the meta-data is false, the store and the OS treat it as needing the phone. Standalone apps must not rely on MessageClient for features that have to work on a run; use local Health Services, local storage, and DataItems if the state must sync later.

When the app reads body sensors (heart rate and similar) while it is not in the foreground, for example all-day PassiveMonitoringClient tracking. BODY_SENSORS alone covers a foreground spot check or an on-screen workout. The background permission is API 33 (Wear OS 4+) and is a separate, stricter user grant.

Jetpack Compose for Wear OS, with watch-specific Material components, scaling lazy lists that suit round screens, curved text, and rotary input support. Horologist adds helpers for media, authentication and layout.

A small touchscreen, a rotating crown or bezel (rotary input), one or more hardware buttons, voice, and gestures such as wrist-raise and tilt detected by the co-processor.

Android Wear 1.x (2014) was phone-tethered. Android Wear 2.0 (2017), renamed Wear OS by Google in 2018, brought standalone apps, the on-watch Play Store and complications. Wear OS 3 (2021, Android 11 base) was a joint Google and Samsung platform with new system UI, Tiles and big power and performance gains; most older watches could not upgrade. Wear OS 4 (Android 13) added Watch Face Format and backup and restore; Wear OS 5 moved to Android 14 (Watch Face Push); Wear OS 5.1 rebased onto Android 15; Wear OS 6 to Android 16. Wear OS 3 matters because it is the modern baseline almost all current work targets.

The wearable platform rebases onto a stable AOSP release and then trims, tunes and stabilizes it for watch hardware, power and memory. SoC vendors and OEMs then have to integrate BSP, co-processor firmware and HALs. Rebasing on the newest phone release every year would multiply that cost, so Wear OS skips versions.

They are declarative (protocol-buffer or XML layouts plus data), so a system process renders them instead of keeping an app process alive. That means fewer processes in memory, fewer wakeups, predictable battery, easier validation, and less risk from buggy third-party code. It is a deliberate power and stability architecture choice.

It declares an update period in its service metadata (the system enforces a minimum of several minutes), and the system calls it on that schedule while the complication is visible. For event-driven data it can request an update through an update requester. Good practice: long periods, push only on real changes, and provide time-dependent data (such as countdowns) that the face can render without a new request.

The system calls the TileService for a layout (and separately for resources) when the tile becomes visible or its freshness interval expires, or the app requests an update. Freshness is a hint: the system throttles updates, typically to many minutes, and requestUpdate is rate-limited. The app should do minimal work, return quickly, and let the process die. Timeline entries let one layout response describe what to show at different future times without extra wakeups.

A Wear OS 5 API that installs a Watch Face Format package on the watch without a watch-side face APK. The phone or store pushes the declarative package; the system renderer draws it. It is the store and OEM path that matches the "no app code on the face" architecture.

No. The Wearable Data Layer is a Google Play services API. AOSP-only images and some regional builds without Play services do not ship it; those products use an OEM companion protocol. If you rely on DataClient, declare the Play services dependency and have a fallback or a "needs Play services" product rule.

Starting an activity on the paired phone (or the reverse) without inventing a MessageClient command. Typical use: the user taps "open on phone" on a workout or pairing screen. It still needs the phone reachable; it is not a substitute for DataItems.

It registers the ambient lifecycle observer, and on "enter ambient" switches to a low-color, mostly black layout with no animations, anti-aliasing off on low-bit displays, and burn-in-safe positioning. It updates only on the "update ambient" callback (about once a minute) and restores the full UI on "exit ambient". It must not use its own timers or wakelocks to refresh more often.

PPG LEDs and photodiodes produce raw samples; firmware on the co-processor samples, filters motion using the accelerometer, computes heart rate and buffers results in a FIFO while the AP sleeps. When the batch is full or the latency expires, it raises an interrupt that wakes the AP. The Sensors HAL delivers the events to SensorService and Health Services, which pass them to the app's PassiveMonitoringClient or ExerciseClient callback in a batch. The AP then suspends again.

A sensor is registered with a sampling period and a maximum report latency. The hardware samples at the period but stores events in a FIFO and delivers them only when the latency expires or the FIFO fills. Non-wake-up sensors do not wake the AP when their FIFO fills (older events may be overwritten); wake-up sensors do. Longer latency means more AP sleep; zero latency means continuous delivery.

ExerciseClient: active workouts with high-rate heart rate, GPS, pace and laps; one exercise system-wide; the app normally runs a foreground service and ongoing activity. PassiveMonitoringClient: all-day data such as steps, calories and heart rate, collected on the hub and delivered in batches even when the app is not running, with passive goals as events. MeasureClient: brief foreground spot measurements, such as checking heart rate now, unregistered quickly.

Health Services is the watch-side API that produces sensor-derived health data. Health Connect is an on-device store on the phone where apps write and read health records (steps, sleep, workouts) with user-controlled permissions. A typical flow is: watch app collects via Health Services, syncs to its phone app, which writes to Health Connect so other apps can use the data.

DataClient for state that must eventually be consistent on all nodes (settings, current workout state): it persists and syncs when nodes reconnect. MessageClient for commands where losing the message is acceptable or the caller retries (start playback on phone): it is fire-and-forget to a connected node. ChannelClient for large or streaming data (files, audio). Assets on DataItems for medium blobs that are part of synced state.

It lets apps advertise named capabilities (declared in resources or added at runtime) and discover which connected nodes have them. Before sending a message, the watch app finds the node that has the "phone companion installed" capability and, ideally, the nearest one, rather than guessing a node ID.

Both need Google Play services with the Wearable API, the same application ID (package name) and the same signing certificate. Paths and capability names must match on both sides, and a listener (or WearableListenerService with intent filters for paths) must be registered to receive events.

Bluetooth first (lowest power, phone nearby), then Wi-Fi when the phone is out of range or for bulk transfers, then relay through the cloud via the user's account (over Wi-Fi or LTE). The Data Layer chooses the transport; apps should not assume which one is in use and must tolerate switches.

The companion bridges notifications from the phone to the watch automatically. Apps can control bridging (for example disable it if the watch app posts its own) and use dismissal IDs so dismissing on one device dismisses on the other. Without that, users see duplicates. Wearable-specific extensions add watch actions and replies.

During setup (usually driven from the phone companion), the carrier's entitlement system checks the user's plan. The watch's Local Profile Assistant then contacts the carrier's SM-DP+ server (using an activation code or discovery), authenticates the eUICC, downloads the encrypted profile, installs and enables it. The modem then attaches to the network and registers for IMS.

Same path as a phone: dialer, Telecom, Telephony, the IMS service, RIL, Radio HAL, modem. The device is already IMS-registered over LTE; it sends a SIP INVITE, negotiates codecs, and carries voice as RTP on a dedicated QoS bearer. With number sharing, the network routes the call to show the phone's number. The differences are power (aggressive modem sleep), thermal limits and a small antenna.

Prefer Bluetooth via the phone, then Wi-Fi; use LTE only when standalone. When LTE is used, rely on long DRX or eDRX paging cycles and power saving mode, batch data transfers, avoid keep-alive chatter, and let the modem reach its deepest sleep quickly after a burst.

The mechanism is the same (update_engine, A/B or virtual A/B, AVB, rollback). The policy differs: install only above a battery threshold, on the charger, on Wi-Fi, and in an idle window, often overnight. Flash is small, so virtual A/B with compression is common. Co-processor and sensor firmware ship in the same update and must match the HAL versions.

An ongoing activity is linked to an ongoing notification of a foreground service and shows an icon or status on the watch face and launcher so the user can return to the running task. A workout app needs a foreground service to keep running while the user leaves the app, and an ongoing activity so the workout stays discoverable.

RAM is small (often 1.5 to 2 GB), and the system must keep the watch face, system UI, Health Services and connectivity responsive. Cached processes are killed early. A common bug is an app faking foreground importance to avoid being killed, which then holds memory and drains power.

A design where a small real-time OS on the co-processor can show the face, handle notifications and track sensors on its own while Wear OS on the AP sleeps, then hands control to Wear OS for rich interaction. It extends battery life greatly but requires keeping state consistent between two operating systems and making the hand-off invisible.

A little core in the same cluster still needs the cluster's power domain, interconnect, memory controller and DDR to be on. A separate co-processor has its own SRAM and power domain on a low-leakage process, so it can run while the entire AP subsystem, including DDR in self-refresh, is off. That brings always-on power down to the milliwatt level, which a shared cluster cannot reach.

Battery hours are about capacity divided by average current. Average current is the sum of AP active share times active current, AP suspended share times suspend current, co-processor current, display current (interactive versus AOD) and radio current. Because active current is 10 to 100 times suspend current, the biggest levers are raising the suspended share (fewer, shorter wakeups; no leaked wakelocks), offloading always-on work, AOD tuning, and radio policy. For example, 400 mAh at 8 mA is about 50 hours; cutting to 6 mA gives about 67 hours.

Continuous accelerometer monitoring and a first-stage detector (a spike followed by stillness) run on the co-processor at low rate, so the AP sleeps. Only when the detector fires does it wake the AP to run a heavier classifier, show the UI, and start the emergency call flow. The trade-offs are false-positive wakeups (power) versus missed events (safety), co-processor memory and compute limits, and firmware update coupling with the HAL.

A wake-up sensor's events wake the AP from suspend when the batch is due or the FIFO is full, so no data is lost but power is spent. A non-wake-up sensor's events wait while the AP is suspended; if the FIFO fills, old events may be dropped. Step counting and significant motion use wake-up variants; high-rate data for a visible screen can be non-wake-up. Choosing wrongly either drains battery or loses data.

The Sensors HAL (AIDL on current releases) exposes sensors to SensorService with batching support via fast message queues. The Sensors Multi-HAL lets several vendor sub-HALs (for example the hub's sensors and a separate PPG vendor) be combined into one HAL. The hub vendor's sub-HAL talks to hub firmware over a shared-memory or IPC transport. Version matching between hub firmware, sub-HAL and framework is an integration gate.

The display panel (often LTPO OLED) runs at a very low refresh rate and reduced color depth. Designs vary: the AP wakes briefly once a minute to render the new time and sends it; or a display controller or the co-processor updates simple elements such as the time and complications from pre-rendered assets without waking the AP. Watch Face Format helps because the system knows exactly what the ambient face needs and can optimize it.

Hard parts: transport switches mid-transfer, nodes connecting and disconnecting, concurrent writes on both sides, Doze delaying delivery, companion updates changing capabilities, and MessageClient losing messages when disconnected. Design rules: store state in DataItems (last writer wins per path), include version numbers or timestamps, make handlers idempotent, use message plus acknowledgement plus retry for commands, keep payloads small and use Assets or channels for bulk, and never assume a particular transport.

Legacy faces were apps with code running permanently on the device, with access to sensors and data granted by permissions. A WFF face contains no executable code, only declarative XML and resources, so it cannot run arbitrary logic, leak data or hold wakelocks. The system controls exactly what data the face can bind to.

Contents: Wear OS framework and Wear GMS, GKI kernel plus vendor modules, device tree, drivers, co-processor and sensor-hub firmware, modem and connectivity firmware, vendor HALs, power and thermal tuning, OEM apps and faces. Gates: build health and boot success, CTS, VTS and Wear certification, per-use-case power budgets (standby, AOD, workout), stability (crash-free rate, ANR, watchdog resets), performance (Tile launch, wake-to-render latency, jank), health-sensor accuracy, OTA success.

Version the interface between firmware and HAL explicitly, check it at boot, and fail safe (disable a feature rather than crash) on mismatch. Ship all components in the same OTA and the same A/B slot so they change together. Treat firmware as a first-class integration artifact with its own regression tests, and include rollback testing so an old slot still pairs with its firmware.

Wrist-raise to rendered face (wake-to-render) is the key UX latency, and it happens thousands of times a day. It includes interrupt handling, kernel resume of devices, display power-up, and the first frame. Measure with Perfetto traces around resume plus a high-speed camera or display photodiode for end-to-end time, and break down by driver resume callbacks (/sys/kernel/debug/suspend_stats and kernel logs with PM debug).

Compare against reference devices (chest-strap heart rate, clinical pulse oximeter, lab treadmill, GPS reference tracks) across a panel covering skin tones, wrist sizes, activities and temperatures. Track error metrics per firmware and algorithm version, and gate releases on no regression. Also verify timing: batched data must carry correct timestamps across suspend and time-zone changes.

It sits on skin, so skin-temperature limits (comfort and safety) bind before silicon limits, and the tiny thermal mass heats quickly during workouts with GPS, LTE calls and charging. The thermal framework throttles CPU and GPU, limits charging current and can restrict the modem. Details are on the Power, Thermal & Battery page.

Number sharing is set up by the carrier: the watch's eSIM profile is linked in the network to the phone's line, so incoming calls and messages fork to both and outgoing ones show the shared number. Failures include provisioning entitlement errors, IMS registration issues on the watch, messages only arriving on one device, and duplicate or missed call alerts when the phone is nearby and also relays via Bluetooth. Debug with IMS registration state, carrier entitlement logs and logs from both devices.

Ship precompiled app code or cloud profiles so apps do not fully compile on device, run background optimization only while charging, trim preinstalled apps, parallelize init services, and avoid blocking the boot on slow firmware loads. For OTA, compile in the background before reboot (virtual A/B allows this) so the post-reboot phase is short.

Classic A/B duplicates every updatable partition, which a watch's small flash cannot afford. Virtual A/B keeps one copy and writes changes as copy-on-write snapshots during the update, merging after a successful boot. Compression shrinks the snapshot. The cost is merge time and more complex rollback, which must be tested.

Reproduce with a fixed use-case profile on several devices, on battery, with debugging disconnected. Reset and capture batterystats, take a bugreport and a Perfetto trace, and compare against the last good build: AP suspend residency, wakeup count, top wakeup sources, wakelock holders, per-app CPU, sensor clients and radio activity. Bisect the merge to the offending change. Usual culprits: a new or leaked wakelock, a service that stopped batching sensors, an exact alarm defeating Doze, or a HAL polling instead of using the FIFO. Fix it, re-measure, and add a power-regression gate.

Check whether it suspended at all: kernel logs for suspend entry and exit, suspend_stats for failures, and wakeup_sources for a source with growing active time. Check Doze: dumpsys deviceidle to see whether it reached deep idle (off-body watches should). Check dumpsys alarm for frequent wakeup alarms and dumpsys sensorservice for a wake-up sensor at high rate. Also check radio: a lost Bluetooth connection causing constant reconnect scans, or LTE searching with poor coverage.

A raw sensor registered at high rate with zero batch latency; GPS left on after a workout ended; a foreground service stuck in a loop; a watch face or ambient screen refreshing every second; a network retry loop over LTE; or a wakelock held through a stalled network call. Confirm with per-app CPU in batterystats, dumpsys sensorservice, dumpsys location, dumpsys activity services, and a Perfetto trace, then contact the app owner or apply platform limits.

Check whether the app uses Health Services passive monitoring (batched delivery, may be delayed by design) or raw sensors (non-wake-up sensor data may be dropped when the FIFO fills during suspend). Check dumpsys sensorservice for the registration, sampling and latency; check whether the app process is killed and its listener not restored; check permissions and whether the off-body sensor paused measurement. Fix with Health Services passive callbacks or a wake-up sensor variant with suitable latency.

The phone notification is bridged and the watch app also posts its own copy. Fix by disabling bridging for that notification or using a shared dismissal ID so the system de-duplicates, and making sure the watch app posts only when appropriate. Also check companion app versions, since bridging behavior can change with updates.

Verify both apps share package name and signature. Check whether the phone writes a DataItem (not a message sent while disconnected) and whether the path matches the watch listener's path filter. Check node connectivity with NodeClient and Bluetooth state, Data Layer logs on both sides, and whether the watch listener service is declared correctly. Check whether the DataItem content actually changed; writing identical data does not trigger a change event.

At home it uses Bluetooth; away from the phone it needs Wi-Fi or LTE plus cloud relay. Suspects: watch not on Wi-Fi or LTE, cloud sync disabled, the app using MessageClient (which needs a directly connected node) rather than DataClient, or relying on a specific node ID. Design for DataItems that sync via cloud, and check capability reachability before sending messages.

Data working means the attach and a data PDN are fine, so look at IMS: is the device IMS-registered (dumpsys telephony.registry, IMS logs)? Is VoLTE provisioned and enabled for this eSIM profile by carrier config and entitlement? Is the IMS PDN up? Check SIP responses (403 or 488 errors indicate provisioning or codec issues). For number sharing, check that the carrier linked the line.

Separate stages: carrier entitlement check (plan eligible? account errors?), LPA to SM-DP+ connection (network, TLS, certificate issues), eUICC authentication, download and install errors, then enable and network attach. Collect LPA and eUICC logs, error codes from SM-DP+, and correlate with carrier-side logs. Common causes: wrong activation code, profile already used, network time wrong on the watch causing TLS failures, or insufficient eUICC memory.

Pull boot reason and kernel logs from affected devices, and update_engine logs showing the slot switch and rollback. Look for version mismatches (co-processor firmware versus HAL), a failing early service, SELinux denials, or a verity failure. Find the common factor (hardware revision, region, prior build). Pause the rollout, fix, add the failing configuration to the test matrix and add a boot-success gate on that path.

Capture Perfetto traces with power and scheduling data across a wrist-raise. Break the latency into gesture detection on the co-processor, interrupt delivery, kernel resume (per-driver resume times), display power-up, and first frame render. Compare with the good build to find the stage that grew, for example a driver with a slow resume callback or a heavier face render. Fix and add a latency budget to the test gate.

Measure with a power monitor while in ambient. Check whether the AP is actually suspending between updates (wakeup count, suspend residency), whether the face or an app is refreshing more than once a minute, whether the panel is in its low-power mode and low refresh, brightness in ambient, and the proportion of lit pixels (OLED power scales with lit pixels). Compare with a reference WFF face to separate face issues from platform issues.

For accuracy: GNSS signal quality, antenna and wrist placement, whether sensor fusion with the accelerometer is used, and the location request interval. For battery: GNSS duty cycle and batching, whether the screen stays interactive, heart-rate sampling rate, LTE activity during the run, and CPU usage of the workout app. Health Services ExerciseClient with batched location usually beats an app managing GPS itself.

Measure the face's current in interactive and ambient mode, look at how often it redraws and whether it holds wakelocks or runs sensors. Short term, contact the developer or restrict the face. Long term, move the ecosystem to Watch Face Format, where no app code runs and the system controls refresh and ambient behavior.

Collect reboot reasons (kernel panic, watchdog, thermal shutdown, brownout or PMIC fault) and pstore or ramdumps. Workout correlation suggests high load: thermal trips, battery voltage droop under GPS plus LTE plus screen (brownout), or a co-processor crash when sensor rates increase. Check thermal zone logs, PMIC fault registers, and co-processor crash dumps; reproduce on a treadmill rig with a power monitor.

Check the tile's freshness interval and whether the app requests updates when data changes. Remember the system throttles freshness and rate-limits requestUpdate; a 1-minute interval will not be honoured. Check whether the app's data source is itself stale (for example waiting on a sync delayed by Doze). Check logs for errors or timeouts in the tile service's layout request; slow responses are dropped. Use timeline entries for predictable future changes rather than frequent updates.

Almost always BODY_SENSORS_BACKGROUND (and using PassiveMonitoringClient rather than a raw foreground-only listener). BODY_SENSORS is enough only while visible. Also check whether the process was killed and the passive registration was not restored, and whether the off-body sensor paused sampling. Confirm with dumpsys sensorservice and the app's permission state.