Most teams shipping AOSP hardware inherit an update client they never evaluated. It came with the SoC or the reference build, it runs in the background, and it can reach out to an endpoint nobody on the team controls. Until someone reads the network logs, it's invisible. And then it's urgent.

TL;DR

• Custom AOSP devices often ship with a vendor OTA client (e.g., Rockchip RKUpdateService) the device maker didn't choose and can't govern.
• That client can generate outbound traffic to a vendor endpoint and accept externally pushed code, without your knowledge or approval.
• This isn't tech debt. It's an unaudited update path into every device in your fleet, which makes it a security and compliance exposure.
• Owning the OTA path means establishing a single update authority you control and shutting down the ones you didn't choose. Esper Airwave delivers firmware through a channel you govern, on any AOSP build, with no MDM enrollment required.
• For disabling a specific vendor service, start with the SoC vendor's AOSP documentation. For assuming full OTA authority, see the Esper docs.

What Is a Default OTA Client and Where Does It Come From?

A default OTA client is a background update service bundled into the SoC vendor's or ODM's reference image. It's baked into the board support package (BSP) your hardware vendor used as a starting point, and it ships on your device unless someone on your team explicitly removed it.

Rockchip's RKUpdateService is a concrete example. It's a system-level service included in Rockchip's AOSP reference builds. It checks for firmware updates against a Rockchip-controlled endpoint, and it has the permissions to apply what it receives. If your device runs a Rockchip SoC and your team built from the reference image, there's a strong chance RKUpdateService is present and active on every unit you've shipped.

The critical distinction: nobody on your team opted into this service. It's not something you installed. It's not something you configured. And the fact that you've never used it doesn't mean it's disabled. It has a network path, it has system-level privileges, and it's running right now.

This pattern isn't unique to Rockchip. Allwinner, Amlogic, MediaTek, and other SoC vendors include similar OTA infrastructure in their reference builds. The vendor and the package name change. The architecture of the risk does not.

Why Is an Inherited Update Client a Security Exposure?

The risk model is straightforward. An inherited OTA client creates two conditions simultaneously: outbound traffic to an endpoint outside your control, and the ability for that endpoint to deliver executable code to your device. Combined, that's an unaudited push path into your fleet.

You didn't choose the endpoint. You don't control what it serves. You have no review gate between that server and your device's firmware partition. In a regulated environment like healthcare, payments, food safety, or logistics, that's a finding. Not a theoretical one. An auditor asks, "Can you enumerate every path through which code reaches this device?" If the answer doesn't include the vendor OTA client, your audit is incomplete. If it does include the vendor OTA client but you can't demonstrate control over it, that's worse.

This is the pattern that surfaces in fleet security reviews. A routine network audit turns up devices generating outbound traffic to an endpoint nobody recognizes, and the source is the bundled SoC update service, active on every device in production. Nobody configured it. Nobody triggered it. It's doing exactly what it was designed to do: checking for updates from its vendor's infrastructure. The resolution is the same every time: take full ownership of the OTA update path and replace the inherited mechanism with one you control end to end.

The uncomfortable truth is that most device security reviews focus on the apps you install and the MDM you select. The OTA client that shipped in the BSP sits below that line of scrutiny. It's infrastructure nobody chose, so nobody reviews it.

How Do You Take Ownership of Your Device Update Path?

Reclaiming your update path is a four-step process. None of the steps are optional.

Inventory every update service in your image

Start with your system image. Enumerate every service with network access and system-level write permissions. On Rockchip-based devices, look specifically for RKUpdateService and related components. On other SoCs, check the vendor partition and pre-installed system apps for anything that resembles an update agent. If you built from a reference BSP and didn't strip it, assume it's there until you prove otherwise.

Identify outbound update traffic

Monitor network traffic from your devices in a controlled environment. Look for DNS queries and HTTPS connections to endpoints you didn't configure. Vendor OTA services tend to use predictable hostnames tied to the SoC maker's infrastructure. Catching that traffic is the fastest way to confirm a service is active.

Disable or remove the inherited client

Once identified, disable the vendor OTA client at the system level. The exact method depends on your SoC and build configuration. Consult the vendor's AOSP documentation for the correct approach to removing or disabling the service without destabilizing other system components. On Esper Foundation builds, this is a controlled operation because you own the OS layer.

Establish a single authoritative OTA mechanism

Replace the inherited client with an update path you fully control. This is where architecture matters. Esper Airwave delivers firmware to your fleet through a channel you govern: signed builds, an approval gate, and delivery you authorize. Because Airwave operates at the firmware layer and requires no MDM enrollment of its own, it doesn't depend on removing or coexisting with whatever manages the application layer. The point that holds regardless: you can't have two update authorities on a device and call the path controlled. Establishing one you govern, and disabling the one you didn't, is the whole job. For how that delivery layer works on non-GMS builds, see How to Push OTA Updates to Custom AOSP and Non-GMS Android Devices.

The Update Client Nobody Audited Is the One That Should Worry You

Security teams spend weeks evaluating MDM vendors. They review app distribution pipelines. They audit cloud configurations and API endpoints. And then they ship thousands of devices running firmware with an OTA client that has standing permission to pull code from a server in a jurisdiction they've never verified.

That's not an edge case. That's the default state of most custom AOSP hardware.

The inherited OTA client doesn't show up in your MDM console. It doesn't appear in your app inventory. It doesn't trigger your sideloading policies. It operates at the system level, below the surface your security tooling is designed to monitor. You can run a locked-down, fully compliant device management stack and still have an open, uncontrolled firmware update channel on every unit in the field.

You can't claim a controlled update path while a second, unaudited one is live across your fleet. Every device with an active vendor OTA client has two update authorities: the one you chose and the one that came in the box. Only one of them answers to you.

Closing that gap isn't a "nice to have" hardening step. It's the difference between a fleet you actually control and a fleet you think you control.

Every Device With a Vendor OTA Client Has Two Update Authorities. Only One Answers to You.

The most dangerous update channel on an AOSP device is usually the one the team never chose: a vendor OTA client phoning an endpoint outside your trust boundary, with the standing ability to push code you never reviewed. Owning your OTA path isn't optional. It's the foundation of every other security claim you make about your fleet.

Request early access to Esper Airwave

FAQ

Is the default OEM OTA client on AOSP devices a security risk?

Yes. A default OEM OTA client has system-level permissions and communicates with an endpoint the device maker doesn't control. It can receive and apply firmware updates without your review or approval. Any service that can push code to your devices from outside your trust boundary is a security risk, regardless of whether the vendor intends it to be.

What is Rockchip RKUpdateService?

RKUpdateService is a system-level update service included in Rockchip's AOSP reference builds. It runs in the background on devices using Rockchip SoCs, checks for firmware updates against Rockchip's infrastructure, and has the permissions to apply those updates. It's present by default in BSPs derived from Rockchip's reference image unless explicitly removed during the build process.

How do I find out if my Android devices have a hidden update client?

Monitor outbound network traffic from a device in a controlled environment. Look for DNS queries and HTTPS connections to endpoints you didn't configure. You can also inspect the system partition of your device image for services with network and system-write permissions. On Rockchip devices, search for RKUpdateService specifically. On other SoCs, check for vendor-specific update agents in the vendor or system partitions.

How do you disable a vendor OTA client and control your own updates?

Disabling a vendor OTA client requires modifying the system image to remove or deactivate the service. The exact steps depend on the SoC vendor and your build configuration. Consult the vendor's AOSP documentation for safe removal procedures. After disabling the inherited client, establish a single authoritative OTA mechanism you control, such as Esper Airwave, so every firmware update flows through a channel your team governs.

Can you control firmware updates on devices managed by another MDM?

Airwave operates at the firmware layer and requires no MDM enrollment of its own, so it doesn't conflict with an MDM that manages the application layer, app distribution, policy, and configuration. For the full picture of delivering OTA to custom AOSP fleets, see How to Push OTA Updates to Custom AOSP and Non-GMS Android Devices (URL TBD).

Why is an unaudited update path a compliance problem?

Regulatory frameworks in healthcare, payments, food safety, and logistics require organizations to demonstrate control over every path through which code reaches a production device. An active vendor OTA client is a code delivery path you didn't authorize and can't audit. If you can't enumerate it during an audit, your device inventory is incomplete. If you can enumerate it but can't demonstrate control, that's a finding. For the specific PCI DSS 4.0.1 and HIPAA patch-window requirements, see How to Meet PCI DSS 4.0.1 and HIPAA Patch Windows on Android Fleets (URL TBD).