Ship a fleet on custom AOSP and you eventually hit this the hard way: Android Enterprise can't deliver firmware to it. The managed-update path assumes Google Mobile Services, and a non-GMS build sits on the other side of that boundary. The OTA mechanism is already in the OS. The delivery layer that stages it across a fleet isn't.

TL;DR

• Android Enterprise and the Android Management API (AMAPI) assume Google Mobile Services. On custom AOSP and non-GMS builds, the managed-firmware delivery path doesn't exist.
• That architectural boundary leaves OEMs shipping custom builds without a standard mechanism for fleet-wide OTA delivery.
• Esper Airwave delivers signed OTA packages to any AOSP build regardless of GMS presence, through an approval gate to targeted device groups, with cryptographic signing you control. No MDM enrollment required.
• Honest boundary: Airwave delivers the update package you provide. It doesn't manufacture a cross-major OS upgrade path your images never shipped with. Attempting that without a real upgrade image causes boot loops.
• For update_engine internals and partition mechanics, see AOSP OTA documentation. For device onboarding, see Esper docs.

Why Android Enterprise and AMAPI Can't Update Custom AOSP Devices

Android Enterprise's firmware management features were designed for one world: GMS-certified, Play-certified devices. The Android Management API inherits that assumption. Every managed-update call flows through Google Play services infrastructure, which means the firmware delivery path is architecturally bound to Google's certification chain.

Custom AOSP and non-GMS devices sit outside that chain entirely. They don't have Play services. They don't have the managed Google Play agent. They can't receive firmware policies through AMAPI because the enforcement layer those policies depend on isn't present on the device.

This isn't a missing feature or an oversight. Android Enterprise was architected for the GMS ecosystem, and it does that job well. The problem is that the GMS boundary is exactly where most purpose-built hardware lives. Kiosks, payment terminals, industrial handhelds, clinical devices, digital signage controllers. These fleets run custom AOSP because the use case demands OS-layer control that GMS certification doesn't permit. The standard managed-update toolchain stops at the GMS boundary, and the fleet that needs firmware control most is on the other side of it.

How OTA Delivery to Non-GMS AOSP Devices Actually Works

The OTA update mechanism itself isn't the gap. AOSP ships with update_engine, supports A/B and non-A/B partition schemes, and handles signed update packages natively. That infrastructure exists on every AOSP build, GMS or not. The update mechanism is built into the OS.

What's missing is the managed delivery layer. The system that registers devices to a fleet, stages a signed package across thousands of endpoints, enforces an approval gate before anything reaches production, and reports back on what installed. On GMS devices, Android Enterprise and Play services provide that orchestration. On non-GMS devices, it doesn't exist unless you build it or bring it.

Esper Airwave provides that managed delivery layer for any AOSP build. Full OTA and delta updates, cryptographic signing you retain authority over, and delivery through an approval gate to targeted device groups. The delivery pipeline doesn't check for GMS presence because it doesn't need to. It operates at the OS layer, below the Google services boundary.

What any AOSP build actually requires for fleet OTA

The requirements for OTA delivery on non-GMS AOSP are straightforward. Device registration against a fleet identity. A signed update package built from your AOSP source tree. A delivery mechanism that can target device groups, gate what reaches production, and report installation status.

What it doesn't require: Google Play services, managed Google Play enrollment, a GMS certification, or an MDM agent that depends on any of those. The entire OTA path from package to device operates on AOSP primitives that exist independent of Google's ecosystem.

For the full technical breakdown of how Android OTA updates work at the partition and signing level, Esper has a dedicated deep-dive that covers update_engine, A/B mechanics, and signing infrastructure. This post stays focused on the non-GMS delivery gap.

What Airwave Delivers, and the Upgrade Path It Doesn't Invent

Airwave delivers full and delta OTA builds to AOSP and GMS fleets with the operational controls fleet firmware deployment requires. Delivery through an approval gate so no build reaches production before it's signed off. Cryptographic package signing that stays under your authority. Targeted delivery to device groups. On A/B-partition devices, a failed update reverts to the previous slot at the bootloader level, which is Android's own recovery behavior rather than something Airwave performs. 

The delivery pipeline treats every AOSP build as a first-class target. No GMS dependency. No Play services agent. No managed Google Play enrollment as a prerequisite. If the device runs AOSP and has network connectivity, Airwave can deliver firmware to it.

Here is the honest boundary: Airwave delivers the update package you build. It does not construct upgrade paths between major Android versions. If your ODM or OS build team hasn't produced a real upgrade image from Android 12 to Android 15, Airwave can't invent one. Attempting a cross-major upgrade without a purpose-built upgrade payload results in boot loops, bricked partitions, or silent data corruption. This is a firmware engineering constraint, not a delivery constraint.

The responsibility chain is clear. Your ODM or OS build team (or Esper Foundation if Esper owns the OS layer) produces the update image. Airwave delivers it to every device in your fleet with the signing and approval controls that make fleet-scale firmware deployment safe. Confusing the delivery layer with the build layer is how teams end up with bricked devices in production.

The Reason Most "Android Device Management" Can't Touch Your Fleet

Teams evaluating device management for AOSP and dedicated devices typically start with a reasonable assumption: "Android device management" is a single capability surface that applies to all Android devices. It isn't.

The capability surface splits at the GMS boundary. On the GMS side, Android Enterprise provides a standardized management API, a managed firmware path, app distribution through managed Google Play, and a compliance framework that works because every device on that side has the same Google infrastructure underneath. MDMs that build on Android Enterprise inherit all of that, and it works.

On the non-GMS side, none of that infrastructure is present. The managed firmware path quietly stops applying. App distribution through managed Google Play doesn't function. The compliance checks that depend on Play services report nothing. The moment you ship custom AOSP, the general-purpose device management toolchain loses its firmware delivery capability, and most teams discover this after the hardware is committed and deployed.

This is why the question "which MDM" is the wrong starting point for teams shipping on custom AOSP. The right question is: what can deliver firmware to a non-GMS build at fleet scale? The answer set for that question is a different, much smaller list than the answer set for "which Android MDM."

Android Enterprise Stops at the GMS Boundary. Your Fleet Doesn't.

Android Enterprise controls the devices Google certifies. Custom AOSP and non-GMS fleets need an OTA delivery path that doesn't assume Google Mobile Services, and Airwave was built to be that path.

Get Started with Airwave

Request early access to Esper Airwave

Book a Demo

FAQ

Can you push OTA updates to non-GMS Android devices?

Yes. The AOSP update mechanism (update_engine, signed packages, A/B partitions) operates independent of Google Mobile Services. What non-GMS devices lack is the managed delivery layer that registers devices, signs, gates, and targets fleet-wide delivery. Esper Airwave provides that delivery layer for any AOSP build, GMS or not.

Does the Android Management API support firmware updates on custom AOSP?

No. AMAPI's firmware management features depend on Google Play services and GMS certification. Devices running custom AOSP without GMS can't receive firmware policies through AMAPI because the enforcement infrastructure those policies require isn't present on the device.

How do you update AOSP devices without Google Play services?

The update mechanism exists natively in AOSP. What you need is a managed delivery system that handles device registration, package signing, an approval gate, and targeted delivery without depending on Play services. Airwave operates at the OS layer, below the GMS boundary, and delivers OTA packages to any AOSP build. On A/B-partition devices, Android's own bootloader-level rollback recovers a device that fails to boot a new build.

Can Airwave upgrade a device from Android 12 to Android 15?

No. Airwave delivers the update package your ODM or OS build team produces. It does not construct cross-major upgrade paths. If a real upgrade image from Android 12 to Android 15 doesn't exist for your device, no delivery system can manufacture one. Attempting it without a purpose-built upgrade payload results in boot loops or bricked devices.

What's the difference between Esper Foundation and Airwave for AOSP devices?

Foundation owns the OS layer. It's Esper's custom AOSP distribution, OEM-independent, supporting any form factor, ARM or x86, GMS or non-GMS. Airwave owns the delivery layer. It gets firmware packages from your build pipeline to every device in your fleet with signing and approval controls. Foundation builds the image. Airwave delivers it. Teams using Foundation get both layers integrated. Teams building their own AOSP can use Airwave independently for fleet-scale OTA delivery.

Do you need MDM enrollment to OTA-update an AOSP device with Airwave?

No. Airwave operates independently of MDM enrollment. Device registration for OTA delivery doesn't require a managed device profile, Google Play enrollment, or an MDM agent. If the device runs AOSP and has network access, Airwave can deliver firmware to it