Native Android application development in Burbank

A phone app and a watch app are not the same product in different clothing. Wear OS runs on a small, round or square screen. Battery is limited. Interaction differs too: a tap, a turn of a bezel, a glance instead of a scroll. Extending an app onto a wrist starts with deciding what belongs there.

Most features do not survive that trip. A shopping app on a watch does not need the full catalog. It needs an order status, maybe a reorder button. A fitness app does not need every settings screen. It needs one metric, checked mid-run. The design work behind a companion app is mostly subtraction.

Jetpack Compose for Wear OS reuses much of the phone mental model. The building blocks differ. Curved text follows the edge of a round display. Rotary input handles devices with a physical bezel. Layouts assume a touch target smaller than anything comfortable on a phone. Sharing logic between a phone module and a watch module is realistic work. Sharing entire screens usually is not.

Android Auto raises a different set of constraints, mostly about safety. A driver cannot read paragraphs of text while a car is moving. The platform enforces its own templates for lists, messaging and media controls instead of a free form screen. Many design decisions end up made by the platform, not the team.

Notification behaviour changes across the pair too. A detailed phone notification might collapse into one glanceable card on a watch, and into a short spoken message inside a car, where a driver should not look at a screen. Building the same event three different ways for three surfaces is normal work. It is not a sign the original design went wrong.

Testing gets harder once a project spans this many surfaces. A watch and a phone can be paired and tested together. Battery behaviour on a real wrist device rarely matches an emulator. Real hardware differs. Automotive testing usually depends on a head unit emulator, or a small number of loaner units. Spare cars are rare in a QA lab.

Deciding whether a companion surface is worth building at all is its own early conversation. A watch app adds ongoing upkeep: another platform to update, another place for a fault to hide, another review cycle through the Play Console. For some products that upkeep pays for itself. For others, one well built phone app already covers what an audience needs.

Fingerprint and face checks feel instant to the person using them. Underneath sits a careful split. The operating system owns the sensor. The app only asks for a result. Android matches the sensor data inside its own protected process. The app never sees a fingerprint image or a face scan directly.

The BiometricPrompt API is the standard entry point. An app calls it and states what it needs. Android takes over from there. It shows the platform authentication sheet, runs the sensor check, and returns a plain success or failure. A custom fingerprint dialog built from scratch rarely earns its sprint. The platform version is already familiar from every other app on the phone.

Android Keystore is the other half of the picture. A cryptographic key generated inside the Keystore never leaves the secure hardware where it was made. An app can ask that key to sign or decrypt something. It cannot export the raw key material. Pairing a Keystore key with a biometric check ties one cryptographic operation to a key bound to that single device.

This distinction matters past a simple lock screen. A payment confirmation. A request to view stored documents. An action that should not survive a phone changing hands. Each benefits from tying the check to a key rather than a flag sitting in memory. A flag can be fooled by anyone who works around the surrounding code. A key inside protected hardware is far harder to copy out.

Device diversity complicates a rollout more than most teams expect. Sensors and cameras vary across manufacturers. Some older or budget devices carry no strong biometric hardware at all. A resilient design keeps a fallback ready: a PIN or a pattern, offered when biometric hardware is missing, disabled, or never enrolled.

Enrollment changes deserve their own handling too. Say a person adds a new fingerprint, or clears every enrolled face, after a key was bound to a biometric check. The safer default treats that key as invalid. Trusting whichever finger sits on the sensor now is not safe. It is a small setting, easy to miss until a security review asks.

None of this removes every risk. Saying otherwise to a client or a reviewer would not be honest. The Android biometric stack offers a well tested default. It removes most of the ways a homemade check goes wrong. In exchange, a team works inside limits the platform sets, not around them.