AOSP Device Management: How to Manage Non-GMS Android Devices

Maverick Updated on Oct 3, 2026 Filed to: MDM

Android devices used in business do not always look or behave like consumer smartphones. A retailer may deploy customized point-of-sale terminals, a logistics company may use rugged scanners, and a manufacturer may operate dedicated Android controllers without Google Play or Google Mobile Services.

These purpose-built endpoints are often based on the Android Open Source Project, or AOSP. Their flexibility makes them suitable for specialized business environments, but it can also make enrollment, application distribution, security, and remote support more complicated.

AOSP device management is the process of enrolling, configuring, monitoring, securing, and remotely supporting enterprise devices built on the Android Open Source Project. It is particularly relevant to company-owned, dedicated, and unattended Android devices that do not rely on Google Mobile Services.

This guide explains how AOSP device management works, how it differs from Android Enterprise, and what businesses should test before managing non-GMS Android devices at scale.

1What Is AOSP Device Management?

AOSP device management gives an IT team centralized control over Android devices built on or customized from the Android Open Source Project.

Depending on the device, firmware, enrollment method, and management solution, administrators may be able to:

Enroll devices into a central console;
Apply device settings and restrictions;
Install and update private applications;
Configure single-app or multi-app kiosk mode;
Monitor device health and connectivity;
Remotely view or control unattended devices;
Distribute files and content;
Lock, wipe, retire, or reassign corporate endpoints.

AOSP itself is not a mobile device management product. It is the open-source foundation on which device manufacturers can build Android operating systems. An organization therefore needs a compatible MDM solution or an OEM-provided management layer to administer a fleet of AOSP devices.

1What Does AOSP Mean?

AOSP stands for Android Open Source Project.

Google describes AOSP as the publicly available source code that provides a complete implementation of the Android mobile platform. Device manufacturers can use and modify this code to develop Android variants for different hardware and use cases. Google also distinguishes the open-source platform from separately licensed services such as Google Play and Google Mobile Services.

Source: Google AOSP overview

This distinction matters in enterprise device management. Two devices may both run software derived from Android while providing very different Google service availability, device management APIs, system privileges, application installation options, firmware update mechanisms, and remote access capabilities.

2What Is an AOSP Device?

An AOSP device runs an operating system based on the Android Open Source Project. It may use an interface, firmware image, application set, and management framework customized by its manufacturer.

An AOSP device may not include:

Google Play Store;
Google Play Services;
Google Maps APIs;
Google account integration;
Managed Google Play;
Other components included in Google Mobile Services.

However, “AOSP device” and “non-GMS device” are not always interchangeable. AOSP is the open-source foundation of Android, while GMS refers to Google’s licensed applications and APIs. A manufacturer can build an Android-compatible device on AOSP and separately qualify it for Google services.

For device management purposes, businesses should verify the actual firmware and available management permissions instead of relying only on the “AOSP” label.

3What Types of AOSP Devices Do Businesses Use?

AOSP is particularly useful when a manufacturer needs to tailor Android to a fixed business purpose.

POS and Self-Service Kiosks

Retailers and hospitality companies use Android-based checkout terminals, ordering screens, vending machines, and payment devices. These endpoints normally run a limited set of applications and may remain unattended for long periods.

Digital Signage Devices

Media players, smart displays, and Android TV boxes can use customized Android builds to present advertising, menus, schedules, or public information.

Rugged and Warehouse Devices

Warehouses and logistics operations use handheld scanners, industrial tablets, vehicle-mounted terminals, and specialized Android devices built to withstand demanding environments.

Industrial and Custom OEM Devices

Manufacturers can adapt AOSP for control panels, medical equipment, appliances, communication devices, and other hardware that does not need a conventional consumer Android experience.

4How Does AOSP Device Management Work?

A typical management process involves five components:

Step 1: Enrollment: The device is connected to an MDM platform through an agent, deployment package, QR code, USB process, or OEM integration.
Step 2: Management authorization: The MDM agent receives the permissions available under the selected enrollment method.
Step 3: Configuration: Administrators assign applications, restrictions, kiosk settings, and other policies.
Step 4: Monitoring: The device reports information such as connectivity, storage, battery level, application status, and operating system version.
Step 5: Remote operations: Authorized administrators troubleshoot, update, lock, wipe, or retire the device.

Note : The depth of management depends on the device. Installing a standard management application does not automatically grant the same control available through Device Owner enrollment, an OEM-signed agent, or a system application.

2AOSP vs. Android, GMS, and Android Enterprise

AOSP, Android, GMS, and Android Enterprise describe related but different parts of the Android ecosystem.

Comparison	AOSP devices	Android with GMS	Android Enterprise
Primary meaning	Devices based on open-source Android code	Commercial Android devices with licensed Google services	Google enterprise management framework
Google Play	Not included by default	Usually included	Uses Managed Google Play
Google Mobile Services	Not included by default	Usually included	Commonly available on supported devices
Customization	Can be highly customized	Controlled by the OEM	Uses standardized management models
Common devices	POS, kiosks, signage, industrial hardware	Consumer and business phones or tablets	Work profiles, fully managed and dedicated devices
Management support	Depends on OEM, firmware, and MDM agent	Generally broad	Standardized through Android Enterprise APIs
Application delivery	Private APKs, OEM stores, or other methods	Google Play and direct deployment	Managed Google Play and approved enterprise apps

1AOSP vs. Standard Android

“Standard Android” is an informal term usually used for the commercial Android experience found on common phones and tablets. These devices often combine AOSP code with Google applications and APIs, OEM user interfaces, proprietary drivers, manufacturer security services, and cloud-based update systems.

AOSP provides the open-source platform, but a complete commercial device normally contains additional components.

2AOSP vs. Google Mobile Services

Google Mobile Services, or GMS, is a collection of Google applications and APIs that manufacturers can license for compatible devices. It can include Google Play Store, Google Play Services, and other familiar Google components.

GMS is not part of the open-source AOSP code. A device without GMS may still run Android applications, but any app that relies on proprietary Google APIs may not work as expected.

Before deploying an application to a non-GMS fleet, test whether it depends on:

Google push notification services;
Google Maps;
Google authentication;
Play Integrity or related APIs;
In-app components delivered through Google Play.

3AOSP vs. Android Enterprise

Android Enterprise provides standardized management options for compatible Android devices. These include work profiles, fully managed devices, corporate-owned devices with work profiles, and dedicated devices.

AOSP device management is less standardized. A non-GMS or customized device may not support the same enrollment methods or policy APIs available through Android Enterprise. The MDM provider may instead rely on Device Owner privileges, an installed agent, ADB enrollment, OEM APIs, or a preinstalled system component.

For that reason, support for Android does not necessarily mean that every MDM function will work on every AOSP device.

3Why Is Managing AOSP Devices More Difficult?

1Enrollment Is Less Standardized

Android Enterprise provides well-defined enrollment methods for compatible devices. AOSP fleets may instead require different approaches based on whether the device has a camera, Google services, USB debugging, a setup wizard, Device Owner support, or an OEM-preinstalled management agent.

A method that works on a tablet may not work on a screenless controller or Android TV box.

2Google Play May Not Be Available

Without Google Play or Managed Google Play, administrators need another way to distribute and maintain business applications.

That may involve uploading private APK files, maintaining an enterprise app library, scheduling releases, tracking installation status, preventing unauthorized apps, and testing whether app dependencies work without GMS.

Application management therefore becomes a central requirement rather than an optional MDM feature.

3Management Capabilities Vary by Device

The same MDM agent may have different capabilities on two AOSP devices. Important variables include Android version, OEM firmware, Device Owner status, root or system privileges, accessibility permissions, background execution restrictions, and whether the management agent is OEM-signed or preinstalled.

Silent installation, remote control, factory reset, system setting changes, and kiosk enforcement may require elevated privileges that a regular application does not have.

4Firmware and Security Updates Are Fragmented

Consumer Android devices often receive updates through an established OEM mechanism. Customized AOSP devices may follow a different update schedule or depend on the hardware vendor to produce and distribute firmware.

Before purchasing devices, identify who maintains the operating system, how security patches are delivered, how long the device will receive updates, whether updates can be scheduled, and what happens if an update breaks the business application or MDM agent.

MDM can help monitor versions and deployment status, but it cannot compensate for firmware that the manufacturer no longer maintains.

5Unattended Devices Are Difficult to Support On-Site

A kiosk, sign, or warehouse terminal may be hundreds of miles from the IT team. A minor application error can lead to a site visit if administrators cannot see or control the device remotely.

For unattended deployments, device management must go beyond inventory. IT teams need a practical method to identify a problem, access the affected endpoint, repair the application, and confirm that the device has returned to service.

4How to Manage AOSP Devices at Scale

Successful AOSP device management starts before enrollment. Organizations should validate the hardware, firmware, application, and management platform as a complete system.

Step 1: Audit Your Devices and Requirements
Create an inventory containing:
- Manufacturer and model;
- Android and firmware versions;
- GMS availability;
- Device ownership;
- Deployment location;
- Network type;
- Business application;
- Required peripherals;
- Required management actions;
- Expected device lifecycle.
Separate essential actions from optional ones. Remote control may be essential for unattended kiosks, while location tracking may be irrelevant for fixed digital signage.
Step 2: Confirm MDM and Device Compatibility
Do not rely only on a vendor’s general statement that it supports Android. Test the exact hardware and firmware you plan to deploy. At minimum, confirm whether the device supports:
- Installation and persistent operation of the MDM agent;
- Device Owner or another elevated enrollment mode;
- Private APK deployment;
- Silent application installation and updates;
- Kiosk mode;
- Remote viewing and control;
- Policy enforcement;
- Remote reboot, lock, wipe, or factory reset;
- Monitoring after the screen is turned off or the device restarts.
Note : A successful agent installation does not prove that every required management action will work.
Step 3: Choose an Enrollment Method
The right enrollment method depends on device capabilities, deployment stage, and required level of control.
QR Code or Deployment Package
QR codes and deployment packages can simplify enrollment when devices have a camera or can open a download link.
These methods are useful for distributed deployments but may require user interaction. Regular enrollment may also provide fewer system privileges than Device Owner enrollment.
ADB or USB Enrollment
ADB or USB enrollment is useful for existing devices, non-GMS hardware, or endpoints without a suitable setup wizard.
AirDroid Business documents a USB-based Device Owner enrollment option for Android 5.0 or later. It requires USB debugging, supports AOSP and non-GMS devices, and does not require a factory reset, although application accounts must be removed before enrollment.
Because USB enrollment requires physical access, it is normally best performed during staging rather than after devices are shipped.
Source: AirDroid Business enrollment documentation
Device Owner Enrollment
Device Owner is an Android management role intended for company-owned devices. It can provide an MDM agent with greater control over policies, applications, and kiosk behavior.
Device Owner normally needs to be configured during initial setup or before accounts and user data are added. Exact requirements depend on the enrollment method and firmware.
OEM Preinstallation
For large custom deployments, the manufacturer can sometimes preinstall the MDM agent or integrate it as a system application.
This can reduce manual setup and provide deeper permissions, but it requires cooperation among the business, device manufacturer, and MDM provider. It should be planned before the firmware image is finalized.
Step 4: Deploy and Update Business Apps
When Google Play is unavailable, businesses need a controlled channel for private APK distribution.
A practical application process should let administrators upload and review an APK, select a pilot group, schedule deployment, monitor results, expand the rollout, pause a problematic release, and remove obsolete versions.
Staged deployment is particularly important for fragmented AOSP fleets. Keep the previous stable APK available until the new version has been validated across representative hardware.
Step 5: Apply Security Policies and Kiosk Mode
A dedicated device should expose only the functions required for its business role.
- Application installation;
- Access to system settings;
- USB connections;
- Bluetooth and camera use;
- Status and navigation bars;
- Network configuration;
- Screen capture;
- Factory reset;
- Unknown application sources.
Kiosk mode can further limit a device to one application, several approved applications, or selected websites.
Security settings should remain recoverable. Before applying a strict kiosk profile to an entire fleet, verify that administrators can still update the business app, access network settings when necessary, and recover a device after a configuration error.
Step 6: Monitor Device Health
Central monitoring helps administrators find issues before local staff report them.
- Online and offline status;
- Last check-in time;
- Battery level and charging state;
- Storage and memory use;
- Network traffic;
- Android and firmware versions;
- Application installation status;
- Application foreground state;
- Device temperature, where supported.
A monitoring dashboard alone does not resolve incidents, but it can show which devices require attention and whether a problem affects one endpoint or an entire device group.
Step 7: Configure Alerts and Automated Actions
Alerts turn monitoring data into operational signals. Where supported, workflows can react by notifying an administrator, moving the device to another group, launching an application, switching a policy, clearing app data, or restarting the device.
- A critical device goes offline;
- Battery level falls below a threshold;
- Storage is almost full;
- A business application stops running;
- A device leaves an approved area;
- Network usage becomes abnormal.
Automation should be tested carefully. An overly broad workflow can interrupt an entire fleet just as quickly as it can repair one.
Step 8: Provide Remote Support
Remote support is especially valuable for devices deployed in stores, warehouses, vehicles, factories, and public locations.
A support session may involve checking status, viewing the screen, taking control when permitted, restarting the app, transferring a file, and confirming the expected kiosk state.
Remote control capability can depend on the manufacturer, Android version, enrollment mode, and installed control add-on. It should be tested on every target model before procurement.
Step 9: Retire or Reassign Devices Securely
A device leaving service should not retain corporate accounts, applications, certificates, or business data.
A decommissioning procedure should specify who authorizes removal, which data must be backed up, whether restrictions should be removed first, whether the device will be reused or destroyed, whether unenrollment is sufficient, and how the organization confirms that the device no longer checks in.
The correct action depends on ownership and enrollment mode. Deleting a console record is not always the same as removing management from the physical device.

5How AirDroid Business Helps Manage AOSP Devices

AirDroid Business is an Android-focused device management platform for attended and unattended endpoints. Its official materials list device enrollment, remote access, monitoring, application management, Kiosk Mode, policies, alerts, workflows, and file management among its central capabilities.

Source: AirDroid Business device management overview

Its suitability for a particular AOSP fleet still depends on the hardware, Android version, firmware, and enrollment method.

1Enroll Non-GMS Devices with Flexible Deployment Options

AirDroid Business supports several Android enrollment paths, including regular enrollment, Device Owner methods, Android Enterprise enrollment, zero-touch enrollment, and Samsung Knox Mobile Enrollment.

For AOSP and non-GMS devices, USB-based Device Owner enrollment is particularly relevant because it does not require GMS or a factory reset. Devices that do not support USB debugging, ADB commands, or camera-based setup can use regular enrollment, although some policy capabilities may then be unavailable.

This gives businesses a way to match enrollment to the technical limits of different device types rather than depending on a single Google-based process.

2Distribute Private Apps Without Relying on Google Play

AirDroid Business includes an Application Management Service for uploading, distributing, updating, and maintaining business applications.

Documented capabilities include a private enterprise app library, forced installation on supported devices, scheduled releases, staged rollout by device or group, and custom app information and release notes.

These capabilities help organizations maintain private APKs on devices that do not use Google Play. Silent installation and removal still depend on the target device’s permissions and enrollment configuration.

Source: AirDroid Business AMS documentation

3Lock Devices into a Controlled Kiosk Environment

AirDroid Business Kiosk Mode can restrict devices to approved applications and websites.

Available configurations include application allowlists and blocklists, single-app mode, multi-app access, Kiosk Browser with website allowlisting, customized home-screen behavior, and restrictions on notification, display, network, and system settings.

These controls are useful for POS terminals, ordering screens, check-in devices, digital signage, and other endpoints that should not operate like general-purpose tablets.

Source: AirDroid Business Kiosk documentation

4Monitor and Troubleshoot Unattended Devices Remotely

AirDroid Business combines device monitoring with remote access features such as View Mode, Remote Control, Remote Camera, and file transfer across its supported management interfaces.

An administrator can use monitoring and alerts to identify a device that needs attention, then start a remote session to investigate without immediately dispatching local support.

AirDroid Business also provides Black Screen Mode for supported remote-control scenarios. It can obscure remote maintenance activity on the physical display.

5Enforce Policies and Protect Corporate Devices

Policy and Kiosk configuration files can be assigned to device groups to standardize how endpoints are used.

Depending on device support and enrollment permissions, businesses can combine restrictions with device grouping, role-based administration, application controls, kiosk profiles, monitoring rules, alerts, workflows, and remote device actions.

Policies should always be tested under the same enrollment method used in production.

Source: AirDroid Business device compatibility guidance

6Important AOSP Compatibility Considerations

Note : No MDM platform can guarantee identical capabilities across every customized AOSP build.

Before adopting AirDroid Business or any other AOSP device management solution, test agent installation, enrollment persistence after reboot, remote control, private APK deployment, silent updates, kiosk recovery, policy enforcement, remote wipe, and behavior after a firmware update.

The test should use the final production model and firmware, not only a similar Android tablet.

6How to Choose an AOSP Device Management Solution

1Verify Support for Your Actual Hardware

Create a representative test group covering every device model, major firmware version, required peripheral, relevant network condition, and intended enrollment method.

If an OEM modifies Android heavily, two devices running the same Android version may still behave differently.

2Test the Critical Management Actions

Create a pass-or-fail checklist based on the deployment. A platform should not pass procurement simply because it can display the device in an inventory list.

Management action	Test result
Enroll using the intended method	Pass / Fail
Maintain enrollment after reboot	Pass / Fail
Install a private APK	Pass / Fail
Update or replace the application	Pass / Fail
Enter and recover from kiosk mode	Pass / Fail
Apply required restrictions	Pass / Fail
View or control the device remotely	Pass / Fail
Detect an offline or unhealthy device	Pass / Fail
Lock, wipe, or factory-reset the device	Pass / Fail
Re-enroll a retired device	Pass / Fail

3Evaluate Deployment and Maintenance at Scale

Consider what happens after the first ten devices become a fleet of hundreds or thousands.

Evaluate bulk enrollment, device grouping, policy assignment, staged rollouts, alert quality, automation, audit history, administrator permissions, integrations, and reporting.

A technically compatible platform can still create excessive work if every action must be completed one device at a time.

4Review Security, Hosting, and Compliance Requirements

Assess how the platform protects management traffic, administrator accounts, device information, and remote sessions.

Review role-based access, administrator auditability, authentication, collected device data, hosting location, on-premises requirements, remote access controls, and regulatory obligations.

Note : Compliance is not created by purchasing an MDM product. It depends on how the organization configures, operates, and audits the platform.

5Run a Pilot Before Full Deployment

A pilot should represent real operating conditions, not just a device connected to office Wi-Fi.

Test actual sites, restricted networks, long unattended sessions, reboot and power-loss scenarios, scheduled app updates, remote incidents, and firmware cycles.

Document every failure and confirm whether it comes from the MDM platform, firmware, business application, network, or hardware.

7How to Remove Device Management from an AOSP Device

Removing Android device management can mean several different things. The correct action depends on who owns the device, how it was enrolled, and what should happen to its data.

1Remove, Unenroll, Wipe, and Factory Reset: What Is the Difference?

Action	Typical result
Remove	Deletes or disconnects the device record from the management console
Unenroll	Ends the management relationship between the physical device and MDM platform
Uninstall	Removes the management agent when Android and the enrollment mode permit it
Wipe	Deletes corporate data or all device data, depending on the action
Factory reset	Returns the device to its original setup state and removes local data

Note : These terms are not always used identically by every MDM vendor. Administrators should confirm the expected result before performing a destructive action.

2How Administrators Remove an AOSP Device from MDM

A general offboarding process is:

Step 1: Confirm that the device is authorized for removal.
Step 2: Back up any required business data.
Step 3: Remove or disable kiosk restrictions if needed.
Step 4: Revoke certificates, accounts, and application access.
Step 5: Send the appropriate unenrollment, wipe, or reset action.
Step 6: Remove the console record at the correct stage.
Step 7: Confirm that the physical device no longer receives policies or accesses company resources.

Note : For company-owned devices, end users should not attempt to remove management without IT authorization.

3Why Some AOSP Management Agents Cannot Be Uninstalled Directly

An MDM agent may be configured as Device Owner, a device administrator, a system application, or an OEM-preinstalled component. Android may block ordinary uninstallation while those privileges remain active. The administrator may need to remove management authorization first, use a vendor-specific process, or reset the device.

4When Is a Factory Reset Required?

A factory reset may be appropriate when Device Owner management cannot otherwise be removed, the device is being transferred, corporate data must be completely erased, the agent is built into managed firmware, setup-time enrollment must be repeated, or the endpoint cannot recover from an incorrect kiosk or policy configuration.

Before resetting a device, confirm that necessary files, activation information, network settings, and business application data can be restored.

Part 8: FAQs About AOSP Device Management

Do AOSP Devices Have Google Play?

Not by default. AOSP provides the open-source Android platform, while Google Play is part of Google’s separately licensed ecosystem. Some devices built on AOSP may qualify for Google Play and GMS, while others ship without them.

Can AOSP Devices Work Without Google Mobile Services?

Yes. AOSP devices can run without Google Mobile Services, but applications that depend on proprietary Google APIs may lose functionality. Test authentication, maps, notifications, integrity checks, and other dependencies before deployment.

Can You Install Apps on AOSP Devices Without Google Play?

Yes. Applications can be installed through private APK deployment, an enterprise app library, ADB, OEM tools, or a compatible MDM solution. Silent installation may require Device Owner, system, root, or OEM-granted privileges.

Can an MDM Remotely Control AOSP Devices?

It may be able to, but support varies by device. Remote control depends on the Android version, OEM firmware, management agent, enrollment mode, and any required control add-on. Test the exact model before deployment.

Does AOSP Enrollment Require a Factory Reset?

Not always. Some Device Owner enrollment methods require a factory reset or setup-time configuration, while others use ADB or USB enrollment without resetting the device. Requirements depend on the device and MDM platform.

Can AirDroid Business Manage AOSP and Non-GMS Devices?

AirDroid Business documents support for AOSP and non-GMS devices through USB-based Device Owner enrollment, as well as regular enrollment for devices that cannot use that method. Available policies and remote actions depend on the model, firmware, Android version, and enrollment permissions.

9Conclusion: Test AOSP Management on Your Actual Hardware

AOSP device management is not simply a matter of selecting an MDM platform that lists Android support. Customized firmware, missing Google services, OEM restrictions, and enrollment permissions determine what administrators can actually do.

Before scaling a deployment:

Step 1: Identify the management actions each device requires.
Step 2: Confirm the enrollment and system permissions available on the target hardware.
Step 3: Test private app deployment, kiosk mode, monitoring, remote control, and device removal.
Step 4: Run a pilot under real operating conditions.
Step 5: Expand only after the complete device-management workflow is stable.

For organizations managing kiosks, POS terminals, digital signage, rugged endpoints, and other non-GMS Android devices, AirDroid Business provides enrollment, application management, kiosk, monitoring, alerting, and remote support capabilities in one platform.

Test it with the exact AOSP hardware and firmware your organization plans to deploy before committing to a full-scale rollout.

Mobile Device Management Free Trial

Click a star to vote

152 views

Maverick

For more than 8 years, Maverick has dig deep into IT and mobile device management. He delivers practical MDM solution tips and strategies for various endpoints management.

Discussion