Stock Android assumes a phone someone chose to buy. On a payment terminal, warehouse scanner or in-vehicle display, the setup wizard and the Play Store are liabilities rather than features.

We build Android for hardware that has a job to do.

Pick the right depth

Approach	Changes	Fits
Device owner app	Lockdown, policy, restricted apps	Off-the-shelf hardware
Custom launcher	The whole user-facing surface	Standard internals
AOSP on existing BSP	Framework, system apps, OTA	Vendor SoC kit
Full bring-up	Kernel, HAL, boot chain	New hardware

Many projects that ask for a custom ROM only need device owner mode — cheaper, upgradeable, and it keeps you out of the OS maintenance business. We will say so.

What we handle

Bring-up. Kernel and device tree, SoC board support, HAL integration for camera, audio, sensors and power, and the vendor blobs whose licensing constrains which Android release you can target. We push for proper Treble separation early — retrofitting it later is painful.

Security. Verified boot, your own signing keys with a process that survives staff turnover, and SELinux policy written properly rather than set permissive to hit a date. Permissive mode is the most common thing we are asked to clean up.

OTA updates. A device you cannot patch is a liability. We build the whole path — update server, signed packages, staged rollout. A/B seamless updates are worth the partition space almost every time: the automatic rollback on a failed boot is what makes remote updates viable for unattended devices.

GMS, or not. If you need the Play Store you need a Google licence and passing CTS, which constrains how far you can modify the framework. Plan for it upfront. Many purpose-built devices skip GMS entirely and lose an entire compliance track.

Where we get called in

Kiosks and self-service terminals, rugged handhelds and POS, in-vehicle and industrial displays, regulated hardware — and rescue work on an OS half-built by a vendor who has moved on. That last one is more common than you would think, and we will start with an honest assessment rather than a rewrite proposal.

Why us

Our own Android software runs on over 200,000 devices across a huge spread of manufacturers, chipsets and versions. This work punishes teams who have only worked at the app layer, and equally punishes those who have never had to support software in the field.

First questions we will ask

What SoC, and is there a vendor BSP?
Do you need Google Mobile Services?
How will deployed devices be updated, and by whom?
Who holds the signing keys?
What is the expected support lifetime?

Not knowing some of these yet is fine — working them out is part of the job, and getting them wrong early is what makes these projects expensive.

What drives the cost

Three things, roughly in order.

Whether a vendor BSP exists. Building on a SoC vendor's board support package is a different project from bringing up a board with no kit behind it. The first is integration work; the second can double a timeline before any of your own features exist.

Whether you need GMS. Google Mobile Services means a licensing agreement and passing the Compatibility Test Suite, which constrains how far the framework can be modified. Skipping GMS removes an entire compliance track — and for a device that never shows the Play Store to a user, it is usually the right call.

How long the device must be supported. A three-year field life implies a security patch strategy, an update path and a build environment somebody can still reproduce in year three. That is an ongoing commitment, not a one-off delivery.

Reproducible builds

A custom OS that only builds on one engineer's laptop is a liability with a countdown on it. Builds run in a container with pinned toolchains, so the same source produces the same image next year, on someone else's machine, after that engineer has moved on.

Manifests are version-controlled, vendor blobs are archived with their licence terms recorded, and the whole thing is documented to the standard of "a competent Android engineer who has never seen this project can produce a signed image."

Signing keys and who holds them

Verified boot means the device trusts images signed with your keys. This makes key custody a business decision rather than a technical detail: whoever holds the keys controls what the fleet will run.

We set up a signing process with the keys in your custody, not ours, and a documented procedure that survives staff turnover. Where a client wants us to hold keys operationally, we do it under an explicit arrangement with an exit path — because a vendor who can sign your firmware and cannot be replaced is a dependency you did not intend to buy.

Compliance and field realities

Purpose-built hardware often carries obligations stock phones do not: payment certification, medical or industrial standards, regional radio approvals. These have long lead times and specific evidence requirements, and they constrain OS decisions — which means they belong in the plan at the start, not discovered in the final month.

Field devices also fail in ways lab devices do not. Power loss mid-update, storage wear on cheap eMMC, clock drift on units that sit unpowered for weeks, and network conditions that no office reproduces. A/B updates with automatic rollback exist precisely because of the first one.

Rescue work

A meaningful share of what we are asked to do is inherited: an OS half-built by a vendor who has moved on, no documentation, permissive SELinux, and a build nobody can reproduce.

We start with an assessment rather than a rewrite proposal — what actually works, what is load-bearing, what is genuinely unsalvageable. Rewrites are sometimes correct and often the expensive reflex. You get an honest read either way, including if the honest read is that the existing work is better than it looks.