Embedded Android: what it takes to build and maintain an Android device

Companies that build kiosks, point-of-sale terminals, vending machines or digital signage players often ask us whether Android is a good base for a dedicated device. For a device with a touch screen and apps, it usually is. The harder part comes after the first working image: keeping the OS secure and up to date for as long as the devices are in the field. This article covers what embedded Android is, where its hardware support comes from, and what it takes to maintain it over a product's lifetime.

Embedded Android is Android built for one device and one job

Embedded Android is the Android Open Source Project (AOSP) adapted to hardware that is not a phone and to a device with a dedicated purpose. A self-service kiosk, a handheld scanner in a warehouse and an HMI panel on a production line can all run Android, but their users never see a home screen full of consumer apps. The device typically boots into one application, often in kiosk mode, and the device maker decides which apps, settings and updates it receives.

Most embedded Android devices ship without Google Mobile Services, because Google licenses GMS only for certified device models. Apps are installed through device management or built into the OS image. We cover the trade-offs in GMS vs. non-GMS Android.

Android fits devices that people interact with

Embedded Linux has been the default OS for professional devices for decades. It is the better fit for headless devices, hard real-time requirements and very small memory footprints. Android adds what a device with a screen and a user needs: a touch-first UI framework, an app model with a large developer pool, ready-made Wi-Fi, Bluetooth and cellular stacks, and a security model with SELinux, verified boot and app sandboxing.

In our customer projects, the deciding question is usually whether people will interact with the device through a screen. A longer comparison is in Android or Linux: what OS to use for professional devices.

Hardware support comes from the chip vendor's BSP

Android runs on the Linux kernel, but it is not a Linux distribution. Between the kernel and the Android framework sits the hardware abstraction layer (HAL), which defines how Android talks to displays, cameras, video codecs, sensors and other hardware. The kernel, its drivers and the HAL implementations for a chip come from the chip vendor as a board support package (BSP).

The BSP decides which Android version a board can run, how graphics and video decoding perform, and how long the board receives updates from its vendor. Two boards with similar CPUs can behave very differently under load because of their codec and display configuration in the Android stack. We measure this on our own builds, for example in our video decoding measurements. For choosing a board, see Android boards: choosing the best dev board and our list of supported hardware.

Google once offered an official embedded variant, Android Things, and repurposed it in 2022. Since then, device makers have built on AOSP and the vendor BSP. Our post on moving on from Android Things covers that transition.

The first working image is the smallest part of the work

Building a customized Android OS for one board is well documented, but it needs serious build infrastructure. On our Android 17 build, generating the build graph alone took 53.6 GiB of memory before compilation started (details in this article). The larger effort starts once the first image works:

• OS security patches. Google publishes an Android security bulletin every month. Each fix has to be merged, built, tested on the device and shipped.
• Android version upgrades. A new major Android release appears every year. Each one changes the framework, the build system and the HAL interfaces the BSP has to match.
• Signing and release management. Release keys, update packages and a traceable record of what went into each build.
• Update delivery and device management. Infrastructure that delivers updates to devices in the field and shows which device runs which version.

We see devices in retail, logistics and industry stay in the field for many years, often longer than the Android version they shipped with receives security patches. Regulation adds to this: under the EU Cyber Resilience Act, the obligation to report actively exploited vulnerabilities has applied since 11 September 2026, and full enforcement follows in December 2027. Our article on the CRA explains what it means for Android products.

OTA updates need a rollout process, not only an update file

A failed update on a device in the field usually means a site visit, so the update process for a fleet matters as much as the update itself. Android provides the building blocks on the device, such as A/B system partitions. The server side, the release process and the fleet overview are left to the device maker. A reliable OTA update process for a fleet includes:

• Staged rollouts that update a small group of devices first and the rest of the fleet after that group runs without problems
• Scheduled installation outside operating hours
• Delta updates that only transfer what changed
• Automatic fallback to the last working system if an update fails
• Rollback protection, so devices refuse older versions with known vulnerabilities

Emteria builds and maintains your own customized Android OS for your devices

This long-term work is what we do. Android OS built by Emteria starts from AOSP and the vendor BSP and adds what dedicated devices need: kiosk mode, remote access, provisioning and an OTA update client. We provide community builds for popular boards and custom builds for our customers' own hardware, and we focus on the two latest Android releases.

Two parts of the Emteria Hub carry this work over the product's lifetime:

• OS Pipelines build your customized Android image from the browser: boot animation, branding, preinstalled apps and settings. The same pipelines build the update images and include vulnerability scanning and CVE patch integration.
• Device and update management registers your devices, prepares provisioning settings that devices apply on their first boot, manages kiosk mode and rolls out OTA updates in stages. Provisioning is free on every plan.

More on Android OS customization, OTA update management and the Emteria Hub.

Trying it takes a Raspberry Pi and an SD card

The quickest way to see Android OS built by Emteria on real hardware is a Raspberry Pi. In Raspberry Pi Imager, open Freemium and paid-for OS, choose the Android image by Emteria, write it to an SD card and boot. No account is needed. Images for other boards are on the Downloads page of the Emteria Hub, which you can use with a free workspace (create an account).

Until you register your device, it shows a watermark and restarts every 8 hours. Registering is free and removes both. Step-by-step instructions are in our knowledge base.

If you are planning a new device, or your devices in the field run an Android version that no longer receives security patches, talk to us about building and maintaining the OS for them.

Raspberry Pi is a trademark of Raspberry Pi Ltd.