Android beyond phones

Android is not one product with several skins. It is one platform that has been extended to several product categories, each of which changes the assumptions an app is allowed to make. The interesting part is not that a watch is small. It is that a watch, a television, a car head unit and a headset each break a different assumption, and the platform's evolution since about 2021 has been mostly about removing the remaining phone-shaped assumptions from the API.

TL;DR#

• Each form factor is a product category with its own input model, its own screen assumptions and usually its own system image, not a configuration of a phone.
• Wear OS changes the interaction model most: small round screens, glanceable content, and a different app lifecycle expectation.
• Android TV changes the input model to a remote, with focus-driven navigation and no touch.
• Android for Cars splits into two very different things: Android Auto (projection from a phone) and Android Automotive (a full Android system in the vehicle).
• Android XR adds spatial input and a 3D window model, while reusing the same core services.
• The platform's answer to all of this is adaptive-first: assume any window size and any input device, and let the layout respond.

Mental model#

Think of a language with several dialects.

The grammar is the same: the same Binder, the same package manager, the same permission model, the same runtime. That is why an Android app can run on a watch and a television at all.

The dialect is the form factor: the vocabulary of input, the conventions of layout, the shape of a screen. A phrase that is natural in one dialect is awkward in another, and some are outright ungrammatical.

An adaptive speaker does not learn four languages; they learn to notice which dialect the listener expects and adjust. That is precisely what the platform now asks of apps.

Where the analogy breaks#

Dialects evolve slowly and mostly by mutual influence. Android form factors are engineered: each has an owner, a compatibility programme and a set of documented requirements, and the differences are deliberate design decisions rather than accreted convention. A television is not a phone that grew up; it is a product with a remote control, a ten-foot viewing distance and no touchscreen, and the platform encodes that.

The big picture#

Notice the spacing. The categories did not arrive together, and each arrival was followed by a period of platform work: a new input model, new UI guidance, a new compatibility programme, and eventually changes in the core API so the category was not an afterthought.

Deep dive#

Wear OS#

A Wear OS device is a full Android system with a different interaction model. The screen is small and often round, the session is short, and the primary interaction is a glance rather than a task. That produces a different design vocabulary: tiles for glanceable information, complications on watch faces, and notifications as the main surface for app content.¹

The platform consequences are concrete. Apps are expected to work with very limited screen area, to handle a round display without clipping content, and to be frugal with battery because the device is small. The app model is still Android — activities, services, notifications — but the defaults are tuned for a device you look at for two seconds.

Android TV#

Television changes the input model completely. There is no touchscreen; there is a remote with a d-pad and a few buttons. Navigation is focus-driven, which means the d-pad moves a focus cursor through a view hierarchy, and the app must make focus visible and predictable. Leanback, the AndroidX library for television, exists largely to provide those focus-aware components.²

The other difference is distance. Content is designed for a ten-foot viewing distance, so touch target sizes, text sizes and information density all change. A layout that is comfortable on a phone is unusable across a room.

Android for Cars#

"Android in cars" is two distinct products and conflating them is a common mistake.

Android Auto projects a phone's experience onto the car's display. The phone runs the app; the car provides a screen and input. The app is still a phone app with a car-specific presentation.

Android Automotive is a full Android system running in the vehicle, with its own system image, its own apps and its own compatibility requirements. It is a platform, not a projection protocol.³ The two share design guidance and some app categories, but they are not the same deployment model, and the difference matters for everything from updates to testing.

Android XR#

Extended reality adds spatial input: head tracking, hand tracking, and a window model that is not a rectangle on a fixed screen. The platform reuses the same core services — the same package manager, the same runtime, the same Binder — but the UI layer changes shape. Apps are expected to present content in space rather than in a screen-sized window.⁴

XR is the most recent reminder that "screen size" is the wrong abstraction. The right abstraction is window, which may not be a rectangle, and input, which may not be a touch.

Adaptive-first#

The platform's response to all of this is a principle rather than a single API: assume the app can be shown in any window, on any screen, with any input device. In practice that means:

• Responsive layouts built from window size classes rather than device categories.⁵
• Handle insets rather than assuming the system bars are outside your window. Edge-to-edge became the enforced default in Android 15 for apps targeting 35.⁶
• Do not lock orientation on large screens. Android 16 and 17 both move toward ignoring orientation and resizability restrictions for targeting apps, with games the main exemption.⁷
• Support multiple input devices — touch, keyboard, d-pad, stylus, remote — without assuming one.

Foldables: the form factor that is also a phone#

A foldable is not a separate product category in the same sense as a watch or a television. It is a phone whose window changes size while the app is running, and that makes it the purest test of the adaptive model.

Two things make foldables different from a tablet. First, the configuration changes at runtime: the app is not launched into a large screen; it is resized into one, often mid-interaction. Second, the display may have a hinge, which means the window can be split into two logical areas with a physical gap between them.

The platform's answer is the same as for every other large screen: respond to the window size and the configuration, not to a device category. An app that reads the current window size and lays out accordingly handles a foldable, a tablet and a desktop-mode phone with the same code. An app that branches on "is this a tablet" does not.

Why "phone" is the wrong default#

Almost every early Android API assumed a phone: a portrait window, a touchscreen, a battery, a user holding it. Those assumptions are visible in the API surface, and each one had to be relaxed as a new category arrived.

The relaxation is not complete. Some APIs still have phone-shaped defaults, and some behaviours are tuned for a device in a hand. That is why the platform's guidance is to test on the form factors you support rather than assume that a layout which works on a phone will work elsewhere. The layout may be technically valid and still be wrong for the device.

What each form factor reuses#

The pattern in the last column is the useful one: each category keeps the platform and changes one or two assumptions. That is why the platform can support them without forking into separate operating systems.

How it evolved#

The UI rows from Honeycomb onward are a history of the platform learning that the screen is not fixed: tablet layouts, then multi-window, then foldables, then edge-to-edge, then orientation being ignored entirely.

Under the hood#

• ‹›Configuration.java↗the runtime description of screen size, density, orientation and input that every configuration change flows through
• ‹›WindowSizeClass.java↗the AndroidX-adjacent size-class model that adaptive layouts are built on
• ‹›WindowManagerService.java↗where window bounds, insets and display policy are decided

Curiosity corner#

• A watch is a full Android system. Wear OS is not a companion protocol; it runs the platform, with its own package manager and its own app installs.
• Android Auto and Android Automotive are not the same product. One projects a phone; the other is the car's own system.
• The 12L release got its own API level (32) because it changed enough behaviour to need a compatibility boundary, even though it kept the Android 12 version number.

Try it#

$ adb shell dumpsys window displays | grep -E "init=|cur="
adb shell wm size
adb shell wm density

Illustrative output — values depend on the device and window.

Build it#

The adaptive-layout ideas here are the basis of B05 — Janky list, and the fix, which measures what happens when a list is rebuilt on every configuration change.

Check yourself#

Sources#