AOSP Device Owner is a Public API

The Android Enterprise ecosystem has three distinct enforcement layers, each governed by different rules. Public discussion frequently treats them as a single object, which leads to incorrect conclusions about what is and is not permissible. The conflation has real procurement consequences — enterprise buyers reading current industry framing are being told that AOSP-based custom DPCs carry compliance risk, when the technical record does not support that.

The three layers are:

1. AMAPI partner program compliance — rules governing vendors building atop Google's Android Management API, including the permissible usage policy and approval quotas
2. AOSP DevicePolicyManager API compliance — rules governing the public Android Enterprise contract surface, available to any developer building a DPC, no partner-program approval required
3. Google Play Protect behavioral flagging — the on-device security warning system, which since 2025 has been used as a gatekeeper for custom DPCs not on Google's approved allowlist

These three layers have different scopes, different enforcement mechanisms, and different governance. Treating them as a single object is the source of most confusion in the discourse. This article separates them.

AMAPI is Google's commercial integration framework for Enterprise Mobility Management vendors. The permissible usage policy explicitly restricts certain use cases. Quotas now apply for new vendors. Approval is required, and approval is at Google's discretion.

Jason Bayton — Android Enterprise Certified consultant, Google Platinum Product Expert, and the first guest of Google's own "Android Talks Enterprise" series — has written publicly about this dynamic. From his December 2025 analysis:

The practical effect: vendors serving use cases AMAPI restricts — including device financing, device-as-a-service, and certain in-house enterprise solutions — have legitimate architectural reasons to deploy custom DPCs built on public AOSP APIs instead of integrating with AMAPI. Bayton is explicit about this:

And on whether AMAPI denial indicates wrongdoing:

AMAPI is a valid architecture for vendors whose use cases fit the permissible-usage policy and who have completed Google's approval process. It is not a universal compliance regime for Android device management. Conflating "not on AMAPI" with "not compliant with Android Enterprise" misunderstands what AMAPI actually is.

The Android Open Source Project has shipped a public DevicePolicyManager API since Android 5 Lollipop, released in 2014. The API is documented at developer.android.com, supported in the public Android SDK, and explicitly intended for production enterprise use. Device Owner mode — the privilege level a custom DPC takes on — is a documented Android Enterprise enrollment pattern. Google itself publishes the integration guidance.

The relevant API surface for a custom DPC implementation includes (non-exhaustive):

• setDeviceOwnerApp — install a DPC as Device Owner at provisioning time
• addUserRestriction — apply user-level restrictions (factory reset, USB transfer, install of unknown sources)
• lockNow — immediate device lock with optional policy flags
• wipeData — full-wipe enforcement at the policy plane's decision
• addPersistentPreferredActivity — launcher and intent control
• setApplicationHidden — application visibility
• setSuspendedPackages — application suspension
• transferOwnership — DPC migration between Device Owner apps (Android 9+)

These are public Android APIs. Any developer can build a DPC against them. Lockia's Cipher DPC is built on this API surface, and so are the custom DPCs Bayton himself has worked with and written about. From his April 2026 piece on the unrealized DPC-migration capability:

Bayton built a working proof of concept demonstrating that the public AOSP transferOwnership() API works end-to-end on Android 9+. The capability has been documented in the public API surface for eight years. The fact that no major EMM vendor has shipped it commercially is a vendor-choice issue, not an Android API limitation.

Google has not publicly stated that building a DPC on public AOSP APIs is non-compliant. There is no AOSP-level "approved DPC list." The DevicePolicyManager API is the documented public contract for enterprise device management on Android, and vendors who build on it are operating inside Google's own published Android Enterprise documentation, not outside it.

Since 2025, Google has used Play Protect — historically a malware-detection system — to also enforce a DPC allowlist during Android Enterprise provisioning. Custom DPCs not on the allowlist trigger "Harmful app blocked" warnings during enrolment, using the same warning interface used to flag actual malware.

This is the most consequential and least-understood layer of the three. It is not AMAPI policy. It is not AOSP policy. It is a Play Protect enforcement mechanism applied at the device level. Bayton's analysis is direct:

On the user-facing impact of conflating legitimate management tools with malware warnings:

Bayton's recommendation, which Lockia shares:

A Play Protect flag is not equivalent to a Google compliance ruling. The two are operationally and architecturally distinct. Buyers evaluating DPC vendors should understand the distinction — and procurement frameworks should evaluate Play Protect approval status separately from AMAPI partnership status, because they are separate things.

Lockia's Cipher DPC is built on the public AOSP DevicePolicyManager API surface. We do not operate as an AMAPI partner. We follow Google's published developer guidance for legitimate DPC behavior — transparency, minimum-necessary permissions, no abuse of accessibility or notification or SMS APIs — and we participate in the Play Protect DPC allowlist approval process Google has documented.

The conflation we want readers to walk away rejecting: the claim that all non-AMAPI-approved DPCs are out of compliance with Android Enterprise. They are not. AMAPI compliance and AOSP compliance are different objects governed by different rules. A vendor building on the public AOSP API surface is operating within the published Android Enterprise contract. The Play Protect allowlist is a separate mechanism with its own approval path — also documented, also followable.

Lockia's use cases — device financing, OEM pre-configuration, public-sector device sovereignty, multi-region operator deployments — include several of the use cases AMAPI specifically restricts. The architectural choice to build on AOSP DPM was deliberate and necessary, not a workaround.

Enterprise buyers evaluating UEM vendors increasingly hear claims that "only AMAPI-validated solutions are Google-compliant." This claim conflates the three layers. The correct procurement question is layered:

1. Is the vendor's DPC built on AOSP DPM APIs or AMAPI? Both are valid. They have different commercial implications and different sovereignty implications. Neither is inherently more "compliant" than the other.
2. If AOSP DPM: has the vendor completed the Play Protect DPC allowlist approval? Required for clean provisioning UX without "Harmful app blocked" warnings.
3. If AMAPI: what is the vendor's quota status and use-case approval coverage? Critical for scale and for use cases AMAPI restricts.

These are three different questions. Conflating them obscures real architectural differences between platforms and pushes buyers toward vendors whose marketing matches a misunderstanding of Google's framework rather than vendors whose architecture matches the customer's actual procurement requirements.

Bayton's broader observation about Android Enterprise governance applies here. From his April 2026 piece:

The conflation of AMAPI partner-program enforcement with broader AOSP API usage, and the use of Play Protect as an enforcement gate against legitimate custom DPCs, serves the commercial interests of vendors who have completed AMAPI approval. It does not serve the interests of enterprise buyers who need device control independent of any single vendor's commercial roadmap. It does not serve the interests of the ecosystem.

The remedy, also from Bayton:

Enterprise buyers, particularly in regulated industries and public sector, are now waking up to the question. The Sovereign UEM category exists because customers are asking it. The right path forward is buyers asking the three procurement questions above with precision, and vendors representing their actual architecture and approval status accurately — not collapsing all three layers into a single marketing claim.

Lockia is the Sovereign UEM platform. Built on public AOSP APIs for Android, Lockia-operated MDM server for Apple. Independent of AMAPI partner-program quotas. Independent of Google service dependencies in the data path. Operated by Lockia, with customer-region deployment available. We participate in the Play Protect approval process. We follow published Android Enterprise developer guidance. We do not represent ourselves as AMAPI-validated, because we are not — and the use cases Lockia serves include those AMAPI restricts.

For enterprises, operators, and OEMs evaluating Sovereign UEM as a procurement category, the platform overview is here: the Sovereign UEM platform overview. For the technical implementation reference, see Sovereign UEM in Practice. For the side-by-side comparison of AOSP DPC versus AMAPI, see AOSP Device Owner vs Google AMAPI.

Citations in this article reference public writing by Jason Bayton, Android Enterprise Certified consultant and Google Platinum Product Expert, at bayton.org. Bayton is not affiliated with Lockia. His work is cited for accuracy and independence.