Applivery now supports Android Open Source Platform (AOSP). Bringing enterprise-grade device management to every Android device, regardless of Google dependency.
If your organization manages Android devices that do not run Google Mobile Services, Applivery now gives you a new way to bring them under centralized control.
With AOSP support, IT teams can manage non-GMS Android devices from the same platform they already use for the rest of their fleet with policies, app distribution, monitoring and security controls in one place.
This extends Applivery’s Android management capabilities to more deployment scenarios, including industrial devices, IoT environments, dedicated hardware and private infrastructure setups.
Today, Applivery brings enterprise-grade management to Android Open Source Platform devices.
unlimited trial of Applivery
The challenge: manage Android beyond Google
The Android Management API provides a strong foundation for enterprise Android management. It is robust, well-supported and covers the vast majority of use cases organizations face when managing Android at scale.
But not every Android deployment operates under the same conditions. Some devices run without Google Mobile Services, are deployed in restricted or private networks, or use purpose-built Android builds for industrial and dedicated use cases.
In those scenarios, IT teams need a management approach that works with Android’s underlying management capabilities while adapting to non-GMS environments, preserving the same level of control through centralized policies, app distribution, monitoring and security enforcement from a single platform.
This is especially relevant for organizations managing:
- Devices in restricted or disconnected markets, where access to external services may be limited or unavailable. The devices sold and deployed there are non-GMS not by choice, but by geography.
- Environments with strict data sovereignty requirements, especially in highly regulated sectors such as critical infrastructure, defense, healthcare or financial services, where device data and management operations may need to remain within private or controlled infrastructure.
- Industrial and IoT hardware, such as warehouse terminals, connected displays, vehicle-mounted computers or embedded devices running purpose-built Android builds.These are purpose-built machines optimized for a single function, not consumer smartphones.
The result is often a fragmented fleet, some Android devices managed through standard enterprise workflows, and others handled manually, inconsistently or through separate tools.
Applivery’s AOSP support is designed to close that gap.
The solution: AOSP support in Applivery
Applivery now manages Android Open Source Platform devices as a fully supported operating system with the same depth, the same tooling, and the same interface already used for Android GMS, iOS, macOS, and Windows.
This is not a workaround. It’s a complete management implementation built specifically for non-GMS environments.
Because AOSP devices have no access to Google’s Device Policy Controller, Applivery has built its own, a custom DPC developed as a direct one-to-one mirror of Google’s, mapped against the Android Open Source API. It operates at the system level with access as deep as the OS allows without routing anything through Google’s infrastructure.
The management experience in Applivery is designed to be as consistent as possible with what IT teams already use for GMS devices same Dashboard, same policy structure, same overall approach. Where differences exist, they reflect the boundaries of what AOSP supports natively. Same policy structure. Same configurations. Same commands. If you already manage Android GMS devices in Applivery, you already know how to manage AOSP.
What's included
Everything available for Android GMS is available for AOSP:
- Policy management: a comprehensive set of restrictions, configurations, and device commands covering security, hardware controls, Wi-Fi, certificates, app management, and more.
- App distribution: deploy APK & AAB packages through the Applivery Self-Service App, a catalog that silently installs, updates, and uninstalls apps on managed devices with no Google Play dependency
- Kiosk mode: lock a device to a single app or a curated suite of apps and advanced kiosk mode including Applivery’s custom launcher (upcoming in June 26).
- Certificate management: deploy and manage certificates directly from the Dashboard
- Device monitoring: network information, installed apps, device settings, storage, and hardware status reports
- Always-On VPN: force all device traffic through a corporate VPN with optional lockdown mode
- OEM Configurations: apply manufacturer-specific managed configurations on supported hardware: Zebra, Bluebird, Samsung Knox, and more.
- Work profile / BYOD: to separate corporate and personal data on compatible Android devices while maintaining a consistent management experience through Applivery (upcoming in June 26).
How it works in practice
When we built Applivery Endpoint Management for GMS-enabled Android devices, we made a deliberate architectural decision, we did not want to simply build a static integration on top of Google’s Android Management API. We wanted to create a system capable of evolving at the same pace as Android itself.
To achieve this, we developed a unique AI-powered layer that continuously analyzes changes introduced in the Android Management API (AMAPI), including new policies, capabilities, constraints and configuration models. Based on those changes, this layer can automatically generate the corresponding platform updates required to support them inside Applivery.
In practice, this means that every time Google introduces a new Android Enterprise capability through AMAPI, Applivery can interpret the change, map it into our own product architecture, generate the required implementation logic and prepare a new release for our Product and Engineering teams to review, validate, test and ship.
This gives us an unprecedented time-to-market. More importantly, it allows us to offer day-zero support for new Android Enterprise capabilities in a way that would be extremely difficult to achieve through traditional manual development cycles.
With Applivery for AOSP, our goal was to remain as close as possible to that same model.
AOSP environments are different by nature. They do not rely on Google Mobile Services, Managed Google Play or Google’s Cloud DPC. However, instead of building a completely separate and disconnected management stack, we decided to replicate the architectural principles that made our GMS approach so powerful.
To do this, we created an AOSP-native management layer that mirrors the logic, structure and operating principles of Google’s Android Management API and Cloud DPC architecture. In other words, we built our own AOSP API and Custom DPC framework, designed to follow a similar specification and management philosophy to Google’s AMAPI-based model, while remaining fully independent from Google services.
This approach allows Applivery to manage AOSP devices through a familiar, scalable and policy-driven architecture. It also enables our existing AI layer, originally designed to learn from AMAPI, to consume and interpret this new AOSP API in a similar way.
As a result, our platform can adapt to AOSP management capabilities using the same automation principles we already apply to GMS devices. The AI layer can understand available policies, generate the required platform support and help keep our Custom DPC aligned with the evolution of our AOSP management model.
This is especially important for long-term maintainability. Instead of creating a one-off Custom DPC that would become increasingly hard to maintain over time, we have built a structured, API-driven and AI-assisted architecture that keeps our AOSP implementation consistent with the principles of Android Enterprise management.
The result is a Google-independent Android management model that preserves the security, scalability and product velocity of our existing AMAPI-based architecture, while extending Applivery’s capabilities to environments where Google services are not available, not reliable or not an option.
In short, Applivery for AOSP is not a separate product built outside our Android strategy. It is an extension of the same architectural vision: a unified, intelligent and highly automated Android management platform capable of supporting both GMS and non-GMS environments with the same level of consistency, speed and control.
Common use cases
A regional fleet that couldn't be managed centrally
A company deploying Android devices across markets where Google services are unavailable has been running those devices outside its MDM. Enrollment, policy assignment, and app updates are handled manually, or not at all, creating configuration drift and compliance gaps across the regional fleet.
With AOSP support, those devices enroll in Applivery using the same workflow as any other Android device. Policies apply automatically. Apps deploy centrally. The regional fleet becomes part of the same managed environment as every other device in the organization.
An on-premise deployment with zero external data flow
A critical infrastructure operator needs full MDM coverage for its terminals, but operates under strict data residency requirements that prohibit device data from leaving its private network. Routing management through any external cloud however trusted is not an option.
With Applivery deployed on-premise and AOSP support enabled, every management action stays entirely within the organization’s infrastructure. Enrollment requires no Google account, no Android Enterprise configuration, and no Managed Google Play organization. Device data, policy enforcement, and app distribution all remain inside the private network.
A mixed fleet managed from a single platform
A logistics operator runs a fleet that includes both standard Android smartphones (GMS) and warehouse terminals and vehicle-mounted displays (AOSP). Until now, these two device types required separate management tools, separate policy sets, and separate operational workflows.
With AOSP support, the entire fleet GMS and non-GMS is managed from the same Applivery dashboard. One policy structure. One app distribution pipeline. One platform.
For organizations running hardware from specific manufacturers Zebra, Bluebird, Samsung Knox, and others — Applivery also supports OEM-specific managed configurations applied silently through the DPC.
Why this matters beyond the immediate use cases
AOSP support is not just a new device type added to a list. It represents a structural change in how Android management works in Applivery.
By building a custom DPC mapped one-to-one against the Android Open Source API, rather than depending on Google’s implementation, Applivery now controls its own management layer for Android. That has a direct consequence for how quickly new Android versions can be supported: the same responsiveness available for GMS is now available for AOSP, from day zero of each new release.
For organizations that have been waiting for a single platform that covers every Android device in their fleet, that capability is now available.
Unified fleet management. IT teams manage GMS and non-GMS Android devices from the same interface, with consistent tooling and operational workflows. No platform switching, no policy duplication.
Zero-day support for new Android releases. Because Applivery’s DPC is mapped directly against the Android Open Source API, new Android versions can be supported immediately, the same responsiveness available for GMS, now extended to AOSP.
Operational independence from Google. For environments where Google dependency is a compliance issue, a geopolitical constraint, or an operational preference, Applivery now provides a complete Android management path that doesn’t require it.
Get started with AOSP management
AOSP support is available now in Applivery. If you operate non-GMS Android devices or are planning deployments in environments where GMS is unavailable or undesirable, contact us or explore the documentation to get started.
