Android Enterprise FAQ

This is already handled with existing permission management capabilities in EMMs, Click here for more details on the change.

Adding accounts allows end-users to head into Settings - Accounts and add an account.

Configure credentials allows an end-user to configure account credentials in-app.

Both options have legitimate uses, for example the adding of accounts and configuring of credentials may be permitted in a COPE deployment as end-users would be allowed to add a Google account and download their own applications complete with personal accounts.

On the other hand, enabling add accounts in a fully managed or work profile deployment scenario would allow end-users to switch to their personal Google account within Google Play, providing full access to the Play Store from which they may install applications which encourage data leakage and raise DLP concerns (Dropbox sat alongside OneDrive, for example).

Restricting Android Device Policy to a single Google Workspace tenant is very straightforward. In your DPC extras, add the line:

{
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"com.google.android.apps.work.clouddpc.EXTRA_FORCED_DOMAINS": "[\"domain.name\"]"
}
}

If your organisation leans on multiple domains across organisational groups, here's an example of allowlisting 3 domains within the ZT DPC extras for Google Workspace:

{
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"com.google.android.apps.work.clouddpc.EXTRA_FORCED_DOMAINS": "[\"bayton.org\",\"jason.com\",\"impressivedomain.com\"]"
}
}

When a Google account entered during provisioning doesn't match one of these domains, a small red error will show beneath the text input as follows:

Please enter an email address for one of the following: bayton.org, jason.com, impressivedomain.com.

There is no path to convert a MADA device (GMS/Play Protect certified) to EDLA.

While Google offered a grace period during the introduction of the EDLA licence, this has long since closed. To convert a MADA device to EDLA, it must undergo new EDLA certification, and both SKUs (if >1000 are in market) must be supported for the licence period.

Officially no, these devices are not supported for Android Enterprise. These devices may also be referred to as AOSP, and an excellent example of an uncertified, AOSP device is the Kindle Fire.

Unofficially without GMS certification modern Android devices do allow for limited Android Enterprise management with an EMM that supports closed network or non-GMS management, or a custom DPC that directly interfaces the Device Policy Manager (DPM) APIs on the Android device. Your mileage may vary on what is possible, but assume that account and application based functionality that leans on Google Play services, Google Play, or any other aspect of the GMS suite of applications will not work.

Furthermore, standard provisioning methods will not work, as these are provided by Google's Set Up Wizard (SUW) flow. The only option, unless the AOSP device OEM implements a different solution, is to set an application as a Device Owner (DO) through ADB.

Throughout this site and across Google's official documentation and resources there are multiple references to the bind, or binding of a Google account to an organisation's EMM/MDM platform of choice in order to use Android Enterprise, but what is it?

Android Enterprise consists, very simplistically, of three aspects:

1. the on-device APIs
2. the advanced account, application, and Play Protect functionality
3. the additional solutions, such as zero-touch and many more 3rd party offerings

In order to leverage 2 and 3, an enterprise is required. This enterprise is created when an organisation goes through the process of linking a Google account - either via Google Workspace or with a standard consumer Google account (@gmail.com or under an existing email address) - to their EMM.

For the organisation it's a reasonably straightforward sign-in and setup flow (at least for those who don't use Workspace) that'll create an enterprise, which generates the appropriate authentication tokens and assign an enterprise ID to allow the EMM to then handle all account and application management going forward.

What sort of account and application management?

• The EMM will create, maintain, and delete managed Google Play accounts (for non-Workspace deployments)
• The EMM will assign the appropriate account to one or more devices, depending on use case (user or device-based)
• The EMM can import and deploy approved applications
• etc

This is a very high-level explanation only, and doesn't cover off the intricacies of things like Play EMM API, AMAPI, differences between Google Workspace and Google accounts, and a multitude of other factors that determine the features and functionality associated with binding for device management.

Android Enterprise was introduced with Android 5.0 Lollipop under the moniker Android for Work.

With that said, very few OEMs originally supported Android Enterprise in the earliest days of its existence; Android Enterprise was not a component of the Android Compatibility Definition Document (CDD) nor did Google throw any significant weight behind it. It is commonly considered a mandatory requirement from Android Marshmallow (6.x) and above, with reasonably universal compatibility almost guaranteed from Android Nougat (7.x).

If considering support for older versions of Android today, AE compatibility should be only one small factor in the decision. Other considerations should include:

• Android app compatibility for enterprise applications
• Security update support, for which only Android 12 and above is currently subject to Google's security backport support. Any older versions of Android require manual backporting by the OEM and cannot be guaranteed.
• The OEM and their commitment to security updates and support
• Management/API support for the Android Enterprise solution set, for example zero-touch is only supported on 8.0 (9.0 mainstream) and later.

No.

While the new signup flow introduced in 2024 now guides administrators towards creating a managed Google Workspace environment, there is no cost to this, and domain validation is optional.

Furthermore, should an organisation choose to opt out of Google Workspace, they can continue creating a bind with a standard Gmail account, and the EMM will create unique and generic managed Google Play service accounts on each Android device that allow sign in to the Google Play Store for application management as it has always been.

The greatest benefit to using a free Google Workspace environment comes from identity, allowing managed devices to authenticate as users in the company domain in order to benefit from user assignment and user-based policies. Google have additionally expanded the signup process to work with Microsoft 365 accounts to tie in automatic external identity management within Google Workspace, removing an additional SSO integration requirement.

I’ve encountered several examples of things not working quite right with AER devices, particularly when diving into the granularity of a specific function with a specific EMM.

The first point of contact for any device based issue would be the EMM vendor. While it may not be an issue which can be replicated on a different model or OEM, the EMM vendor will still investigate it, particularly if it can be replicated on one or more devices of the same model.

Before contacting the EMM, the organisation should ensure the issue can be replicated on more than one device. If so, attempt to collect logs from the EMM, the device (a bug report, though be aware this will collect personal account information also) and steps to replicate it along with all of the normal details – make, model, Android version, build number, etc. A video is always appreciated though do add the steps on paper also.

If the EMM can replicate it but cannot resolve it, they will have OEM contacts to reach out to progress it. If necessary, Google will be involved once all other avenues are exhausted, or it’s determined to be a platform issue.

I do a fair amount of device testing, so if you do come across something and your EMM is not providing the support needed, feel free to reach out and I’ll be happy to help.

Historically this has not been possible. An Android Enterprise ID (organisation ID) is associated with only one EMM at a time, and a Google account can only manage one bind at a time; under all normal circumstances attempting to bind with the same Google account on another EMM will return an error stating an Enterprise already exists.

From mid-2024 however, with the roll-out of Google's new customer signup process designed to bring the enterprise arms of Google Cloud, Google Chrome/ChromeOS, and Android under one domain-managed account, this is no longer a limitation.

With a new, enterprise domain-led bind approach, all organisations binding with their EMMs will be able to create an organisation account associated with a zero-cost managed Google Enterprise domain (think Google Workspace, or perhaps more apt, a Google Cloud Identity tenant). With this approach, once the domain is verified as owned by the organisation, multiple EMMs (or multiple accounts under one EMM) can create as many organisation IDs as desired, and all will be managed under one Google Enterprise console.

For organisations with existing binds to EMMs using a consumer Google/Gmail account, the existing, legacy behaviour still currently applies:

Attempting to bind with the same Google account on another EMM will return an error stating an Enterprise already exists.

It is possible to unbind from one EMM and then bind with another, however this will delete the existing Enterprise and create a brand new one, losing all approved applications, etc.

The only exception to the above is in high availability and/or disaster recovery scenarios where an instance of an EMM may be replicated, but no two EMMs should be generating managed Google Play accounts from the same Google account simultaneously.

Google are expected to support migrations to Google Workspace domains for existing organisations in the future.

Not all Android devices come with GMS, or Google Mobile Services, certification.

What is GMS?

GMS certified devices, or more recently rebranded by Google as Play Protect certified devices, are Android devices that have undergone the 60+ hour testing and approval process with Google or a 3PL lab on Google's behalf. This testing, which consists of various security & compatibility validations, ensure the Android device under test behaves, looks, and feels consistent with the rest of the Android ecosystem. It ensures an OEM doesn't preload harmful (as in malware, but also as in privacy) applications, it ensures the OEM builds are up-to-date on vulnerability management and have patched all known CVEs over 60 days old, and it ensures apps install properly, work consistently, and all ecosystem-wide behaviours and implementations meet Google's strict requirements.

Most of the requirements for an Android device heading to GMS certification can be found through the CDD, or Compatibility Definition Document. This is a public document that outlines every requirement for Android under MUST, SHOULD, and MAY.

If you come across references to CTS, VTS, BTS, STS, GTS, or less generally grouped as "XTS", these are the individual tests that make up the validation & certification process for GMS.

Before putting an Android device through these tests, the OEM must sign an agreement with Google; the GMS - Google Mobile Services - agreement is an additional contract that defines requirements for bundling Google applications on the Android device. Requirements include mandatory and optional Google apps (Google core and Google optional, respectively), home screen layouts, app icon positioning and much more. These requirements are further broken up into regional and use case agreements, such as MADA for most of the world, eMADA for Europe, EDLA for enterprise or non-standard form factors, and others. Each agreement also comes with requirements for longevity, transparency (i.e. period of support for software on a device lifecycle published publicly, etc).

Understandably a lot of this is NDA, so it's not easy to be overly transparent about Google's requirements and processes for certification.

How do I validate a device is GMS certified?

This is surprisingly not that easy to discern for the general public, as Google doesn't explicitly maintain a list of certified devices under the heading of certified devices.

Instead, there are three indirect means of validating devices are certified:

1. Check the OEM/ODM has an agreement with Google - https://www.android.com/certified/partners/
2. View Google Play's Compatibility document, as any certified device will show up here - https://support.google.com/googleplay/answer/1727131
3. On the device itself, head to Google Play > Settings > About > Play Protect certification. Your device should show "Device is certified"

If the OEM/ODM is listed in link 1, there's a reasonable assumption the hardware they provide has certification, since Google leans on OEMs to certify the hardware they make once they're granted an agreement.

But if the device is listed in link 2, you know for sure it's certified. These lists aren't updated daily, so the absence of a device doesn't immediately indicate a device isn't certified.

The caveat for 3 is a device may be whitelisted with Google before getting formal approval, so may not have passed GMS testing just yet. This can be cross-checked with the above links to form a reliable opinion.

Customer signup bind management

When a bind is associated to the customer signup flow introduced in 2024, it is permanently associated with the Google Workspace environment/domain used during the bind setup process.

While bind migration between Google Workspace environments is not currently documented by Google, it is no longer associated to a single Google account, and any user with the appropriate permissions within the Google Workspace tenant is able to manage the bind.

Information on user role management in Google Workspace can be found here, while managing users can be found here.

Legacy bind management

Yes, it is more recently possible to configure the accounts responsible for managing the Android Enterprise organisation (enterprise) ID

1. Log on to managed Google Play admin
2. Scroll down to Admins
3. Add or remove Google accounts as desired

Add an account

Adjust permissions

NB: Owners can add and remove other accounts, while Admins are limited to only managing the enterprise. This follows the same permissions model as other enterprise solutions Google offers, such as zero-touch.

Remove an account

Notes

The same recommendations continue to apply when adding new accounts - if you're making a new Google account to add in, please use the "current email address" option and associate the Google account with a work email address. This makes account recovery much simpler, and avoids questions around why emm.account.3@gmail.com exists in future.

In other words, don't do what I did when I bound my EMM to emmsetup@gmail.com back in 2017 (see above).

Note also that Google Workspace accounts are not supported for administering enterprises with the legacy bind management flow. If a Google Workspace user is invited, they will receive an invite only to be informed "G Suite users are not supported":

Perhaps this will be addressed in future, or at the very least engineering will update the message to reflect the Google Workspace branding.

One final point to mention, a Google account can only administer one enterprise. If an invited account is already administering another enterprise, they will see an error:

Yes, on userdebug and engineering builds.

By design, production Play Protect Certified Android builds ship with /system mounted read-only and protected by dm-verity. This ensures the partition can’t be tampered with, maintaining the integrity of the OS. On non-production builds, however, you can temporarily disable verity and remount /system as read-write in order to make changes.

Steps

1. Connect via ADB and disable verity:

adb root
adb disable-verity
adb reboot

2. After reboot, remount /system:

adb root
adb remount
adb shell
mount -o rw,remount /system

At this point /system is writable and you can make modifications.

1. Once finished, re-enable verity:

adb root
adb enable-verity
adb reboot

Considerations

• This only works on userdebug or engineering builds. Retail/production builds won’t permit it.
• Any changes may be lost after an OTA update, if it remains possible to do so.
• Leaving verity disabled weakens device integrity. Always re-enable once done.
• Mistakes in /system can break the OS or prevent booting, so proceed with caution.

This approach is intended for development and testing. For production devices, modifying /system is not supported.

If you see errors similar to:

• Since your organization has reached its usage limits, this device can’t be set up
• Organization reached its usage limits, your work profile can't be set up

..or any message similar to the above, this will be due to Google's choice to prevent anyone from using the Android Management API without business justification & approval.

Older projects, those created in early 2025 or prior, may only see this in relation to an unverified project exceeding 500 devices. In all cases the approach to unlock AMAPI for your organisation is to read, accept, and submit a quota increase form via the Permissible Usage page under AMAPI Guides:

https://developers.google.com/android/management/permissible-usage#quotas_and_restrictions

This process can take multiple weeks, so patience is required. It is imperative not to progress with development or engagements prior to approval being given.

Also note, approval for a quota does not mean product verification. Quotas still remain after approval is given. Verification is undertaken through the Android Enterprise Partner Portal.

There are many reasons an application may not be able to install on a device, from compatibility to environmental issues, but this document focuses on policy-induced issues.

Devices managed using Android Enterprise may restrict the ability to install or uninstall applications.

What causes this restriction?

An administrator has enabled one or both of the following restrictions:

• Disallow app installation
• Disallow app uninstallation

When enabled, Android blocks these actions at the system level. This applies to all installation methods, including Google Play, APK files, and third-party app stores. This also includes any EMM-derived app installs or removals.

What will I see as an end user?

The experience varies slightly by Android version and device manufacturer, but commonly includes:

• Applications sit in Google Play trying to install, but never complete
• Applications do not uninstall, showing a notification stating uninstallation failed

This can appear as a fault, but it is expected behaviour when the policy is active.

Why would an organisation enable this?

These restrictions are what could be considered the nuclear option, and override all other known application restriction policies. It means no matter what policies could be applied, the device will not deviate from the state it was in when the policies were set.

Can I bypass this restriction?

No.

How do I install or remove an app I need?

You’ll need to contact your organisation’s IT administrator or support team. They can:

• Temporarily lift the restriction if appropriate
• Approve and remotely install the application
• Add the app to an allowlist

Is this a bug?

No.

If app installation or removal is blocked, the device is functioning exactly as configured. If the restriction is no longer required, the policy must be updated by the administrator.

Unfortunately this policy is set all too often as a default with the expectation EMM-derived application changes will override this policy. This is not the case.

If in doubt about app install/uninstall issues, validate these restrictions have not been set.

While it’s indeed true Android Enterprise was introduced as Android for Work with Lollipop (and supported even earlier with the app (but we don’t talk about that), Android Enterprise was an opt-in feature with little uptake and a lot of teething issues. From Android Marshmallow (6.0) it became a mandatory requirement.

In other words, Marshmallow is chosen as a reasonably reliable reference point for when Android Enterprise was guaranteed to be widely supported. There will be OEMs that can confidently state they supported it from Day Zero, however few did.

If the Google account used for your Android Enterprise bind is disabled or marked for deletion by Google, the consequences can be severe. Depending on the EMM and the state of the bind, devices may lose access to managed Google Play, app deployment may fail, and new enrolments could be blocked.

This situation most commonly affects organisations using a personal Gmail account (or a standard Google account under a non-Google email address) for their bind. Google may disable these accounts for perceived policy violations - sometimes without clear explanation - and the recovery process can be slow and uncertain.

Why this happens:

• Personal Google accounts are subject to Google's consumer Terms of Service, which include automated enforcement
• Accounts that appear inactive, send unusual traffic patterns, or trigger automated abuse detection may be flagged
• Enterprise activity through the bind (such as high volumes of account creation or app approval actions) can occasionally trigger these automated systems

What to do if your bind account is disabled:

1. Attempt account recovery through Google's standard process at accounts.google.com
2. Contact your EMM vendor and request they escalate through their Google partner channel
3. Raise the issue in the Android Enterprise Customer Community for visibility and support

Contact me if you can't progress, I can see what I can do to help. Ensure you have:

• The organisation (enterprise) ID
• A new Google account to take over the bind
• Business/contact details
• The old inaccessible Google account for reference (if you know it)

How to prevent this: The recommended approach is to migrate to a managed Google domain (Google Workspace or Cloud Identity). Domain-verified accounts are managed by the organisation rather than subject to consumer account enforcement. This also unlocks the ability to bind with multiple EMMs under one domain.

For more on what the bind is and how it works, see What is the Android Enterprise bind?.

For an in-depth take on this, check out:

• Android Enterprise vs Device Admin: Why DA is no longer suitable
• What is Android Enterprise?

Device Admin was introduced with Android 2.2 as a means of granting admin permissions to applications. Any number of admins could sit on a device and have excessive, often unnecessary control. It was widely abused by PHAs (malware, etc) and was very limited in scope of capability, leaving each OEM to build upon it in a fragmented and difficult to support manner.

Android Enterprise takes a more structured approach to device administration by permitting only one owner on a device at a time with scope for task delegation to other apps as defined by the management server. This approach is fundamentally more secure and easier to support as the APIs are universal cross-OEM.

Add in features such as no Google account management, silent app distribution, managed system updates, simple provisioning and streamlined enrolment, and it’s clear why Android Enterprise replaced Device Admin entirely.

If you need to unbind from your existing EMM, whether to -

• Move to another EMM
  • Related: Is it possible to bind with multiple EMMs at once?
• Start afresh with a new enterprise ID
  • If you're considering this because you can no longer access your existing bind, Google can assist. Escalate to your EMM who can in turn raise it as a partner ticket either through their BD or the Partner Portal. If the EMM is unhelpful, raise it in the Android Enterprise Customer Community & tag me (@jasonbayton).
  • If you're considering this because you want to use a new account to administer the bind, you don't need to!

Or any other perfectly valid reason, the steps to follow are straightforward.

Via your EMM

In the first instance, the simplest course of action is to unbind through your EMM. Here are some current links to this:

• Ivanti EPMM/MobileIron
• SOTI
• Omnissa Workspace ONE UEM
• Microsoft Intune

Feel free to submit a PR with additional EMM articles!

Some platforms don't support removing the bind through EMM administrative settings. Some platforms, like SOTI, only unbind and don't delete the enterprise ID. This is useful for future rebinding if platforms support it, but otherwise it's another step in the process an organisation is forced to take to fully delete the bind.

Via Google Play admin settings

If the EMM platform doesn't support deleting the bind, or if you no longer have access to the EMM to do so, you can head to Google Play Enterprise admin settings to do so:

1. Head to Google Play Enterprise admin settings - https://play.google.com/work/adminsettings
2. Select the menu dots on the right of your organisation
3. Delete organisation
4. Confirm delete

Here's a handy GIF that runs through it:

With the bind removed, you're now ready to re-use the account to create a new bind with your existing or alternative EMM provider.

Yes, but with important limitations.

Google supports migrating devices from a custom DPC (using the Play EMM API) to the Android Management API (AMAPI) without requiring a factory reset. This is done through the AMAPI SDK's DPC migration functionality.

Prerequisites:

• The device must be managed by a custom DPC integrated with the AMAPI SDK
• The device must be enrolled with the Google Play EMM API
• The device must belong to a Managed Google Play Accounts enterprise
• Android 9+ for fully managed devices; Android 11+ for work profiles on company-owned devices

Key limitations:

• Migration is only supported within the same EMM vendor. It cannot be used to move devices between different EMM providers
• The migration is irreversible. Once a device moves to AMAPI, it cannot be migrated back to the custom DPC
• The migration must be initiated by the custom DPC on the device, coordinated with the EMM backend

How it works:

1. The EMM sets up a policy in AMAPI for the migrating device
2. A migration token is created and sent to the custom DPC on the device
3. The custom DPC calls the migration method in the AMAPI SDK
4. Android Device Policy takes over management from the custom DPC

Notable example: Microsoft Intune completed its migration of Android personally-owned work profiles to AMAPI, with corporate-owned migrations following.

For more context on how DPC migration works and what to expect, see AMAPI publicly adds support for DPC migration.

From Android 15 it is possible to configure and deploy eSIM profiles, both full and partial, to Android devices.

Where a partial eSIM profile is deployed, it needs only a pointer to the relevant SM-DP+ server to fetch the full configuration.

For company owned devices - fully managed and work profile - it is possible to deploy configurations and prevent their removal. For personally-owned work profiles, configurations can be pushed, but end-users have the ability to remove the eSIM themselves.

Android 16 enhancements:

• Administrators can retrieve device EID (eSIM Identifier) values for both corporate-owned and personally-owned devices, enabling eSIM provisioning workflows at scale
• User-initiated eSIM addition can be controlled through the userInitiatedAddEsimSettings policy on company-owned devices (Android 15+)

Note that on Android 16+, when a work profile is removed from a personally-owned device, managed eSIM profiles are always wiped regardless of other policy settings.

Advanced Protection is a device-level security mode introduced with Android 16. It bundles a broad set of hardened security settings behind a single toggle in Settings > Security & Privacy, and is designed for users at higher risk of targeted attacks - journalists, executives, activists, and similar.

When enabled, Advanced Protection activates the following protections:

• Sideloading blocked - apps can only be installed from the Play Store and preloaded app stores
• Play Protect enforced - Google Play Protect remains on and cannot be disabled
• 2G disabled - the device will not connect to 2G networks, mitigating interception risks from IMSI catchers
• Insecure Wi-Fi blocked - the device will not auto-reconnect to known insecure (open/WEP) networks
• USB restricted - USB defaults to charging only while the device is locked, preventing data extraction
• Inactivity reboot - after 72 hours locked, the device reboots into a Before First Unlock (BFU) state where decryption keys are cleared from memory
• Memory Tagging Extension (MTE) - hardware-level memory safety on supported devices
• Intrusion logging - encrypted logs of sensitive system actions stored in the cloud
• Scam and spam protections - enhanced call screening and message scanning in Google Phone and Messages

This is distinct from the existing Google Advanced Protection Program (APP), which is an account-level security programme requiring hardware security keys. The Android 16 Advanced Protection mode is a device-level feature that does not require APP enrolment, and is available to any user on a supported device.

As of early 2026, Advanced Protection cannot be enforced or configured centrally by IT administrators through AMAPI. There is no policy field in the Android Management API to toggle it on or off. It must be activated individually by the end user on each device.

Google does provide the AdvancedProtectionManager API, which allows applications to query whether Advanced Protection is enabled and register callbacks for state changes. This means an EMM or compliance app could detect whether a user has enabled it and take action accordingly - for example, flagging non-compliant devices or gating access to sensitive resources - but it cannot enforce activation.

Many of the individual protections that Advanced Protection bundles are already available as separate AMAPI policies. For example, admins can already block sideloading (installUnknownSourcesDisabled), enforce Play Protect, restrict USB access, and manage system updates independently. What Advanced Protection offers is a user-facing shortcut that activates all of these at once, plus protections like MTE and intrusion logging that are not individually exposed through management APIs.

• What's new in the 2026 Android Security Paper?
• Android developer documentation: Advanced Protection Mode
• Google Security Blog: Advanced Protection

Device Trust from Android Enterprise is a set of verified device signals that Google provides to registered security and identity partners. It is accessed through the AMAPI SDK (v1.3.0+) and offers over 20 signals covering device state, configuration, and compliance posture.

Key characteristics:

• It works across all ownership models: company-owned, BYOD, and even unmanaged devices
• Access is restricted to partners registered through the Android Enterprise Partner Portal
• It requires a minimum of Android 10
• Signals are provided as a snapshot to the calling application on-device and can be requested as frequently as needed

Device Trust is distinct from Play Integrity. Play Integrity is a general-purpose API available to any app developer for verifying device and app integrity. Device Trust is specifically designed for enterprise security and identity providers that need granular posture data to inform access decisions.

Google recommends running Play Integrity checks before relying on Device Trust signals. If a device fails Play Integrity, the signals reported through Device Trust should not be considered reliable, as the device itself cannot be trusted.

Current integration partners include CrowdStrike, Okta, Omnissa, Urmobo, and Zimperium, among others (including me!).

For a hands-on look at how Device Trust works, see Device Trust from Android Enterprise: What it is and how it works.

Android Enterprise is not officially supported in mainland China due to restrictions on Google services, which affects essential functionalities such as account management, app distribution, and in-built security services. In fact, there are multiple countries not officially supported.

For organisations operating in these countries, leveraging existing solutions that support AOSP or closed-network enrolment can be a viable alternative. Solutions like Workspace ONE UEM and Microsoft Intune offer support for these approaches. Notably a considerable amount of management capability will be lost without full Android Enterprise management, leaving only on-device API support (restrictions) or any value-adds the respective platforms offer atop this, such as APK deployment.

It is worth noting that Chinese OEMs such as Xiaomi, Oppo, and Vivo ship different ROM variants for domestic and global markets. Global ROM variants (sold outside of mainland China) typically include GMS and support Android Enterprise. Domestic ROM variants sold within China do not include GMS and therefore do not support Android Enterprise. If sourcing devices from these OEMs, confirm whether the device ships with a global or domestic ROM before planning an Android Enterprise deployment.

There is no single best EMM for every organisation. The right choice depends on existing infrastructure, budget, platform mix, and the deployment scenarios required. Here are the key considerations:

Google validates EMM solutions through the Android Enterprise Recommended programme. AER-validated EMMs have demonstrated support for a standard set of Android Enterprise features. Starting with an AER-validated EMM is sensible, though it is not a guarantee of quality or completeness - see What is Android Enterprise Recommended?.

• Deployment scenario support - does the EMM support the scenarios you need? Fully managed, work profile (BYOD), COPE, dedicated/kiosk? Not all EMMs support all scenarios equally
• AMAPI vs custom DPC - is the EMM built on Google's Android Management API (AMAPI) or does it use a custom Device Policy Controller? AMAPI-based EMMs receive new Android features faster as Google ships them directly. Custom DPC EMMs may offer unique features but depend on the vendor to implement new Android capabilities
• Zero-touch enrolment support - if you plan to use zero-touch, confirm the EMM supports it and that the integration works with your reseller
• OEMConfig support - for OEM-specific features (Samsung Knox, Zebra, Honeywell, etc.), the EMM needs to support OEMConfig or have direct OEM integrations
• Multi-platform requirements - if you also manage iOS, Windows, macOS, or ChromeOS, a unified platform may be preferable
• Managed Google Play integration - all AE-capable EMMs integrate with managed Google Play, but the quality of the app management experience varies
• Pricing model - per-device, per-user, or tiered. Consider total cost including any add-on modules for advanced features

• Request a trial and test your specific deployment scenarios before committing
• Check community forums and peer reviews for real-world experiences with the EMM and your target devices
• Confirm the EMM's update cadence for new Android version support - some vendors are significantly faster than others
• If you have an existing EMM for other platforms, evaluate the Android Enterprise capability of that platform first before introducing a separate solution

Android Enterprise devices require access to several Google services in order to provision, receive policies, install applications, and maintain compliance. Organisations operating behind firewalls or with URL-filtering proxies need to ensure the following domains are accessible.

At minimum, devices need access to:

• *.google.com - covers Google Play, managed Google Play, account services, and FCM (Firebase Cloud Messaging) for push notifications
• *.googleapis.com - API endpoints for device management and app distribution
• *.gstatic.com - static content delivery
• *.android.com - Android-specific services
• play.google.com / play.google.com/work - managed Google Play access
• accounts.google.com - authentication
• fcm.googleapis.com - push notifications for policy delivery

Google maintains the full and current list of required endpoints in the Android Enterprise network requirements support article.

In addition to the Google endpoints above, your EMM vendor will have their own set of required domains and ports. These vary by vendor and should be confirmed with your EMM documentation. Common examples include:

• Microsoft Intune: *.manage.microsoft.com, *.microsoftonline.com, and several others documented by Microsoft
• VMware Workspace ONE: device services endpoints specific to your tenant
• Google Endpoint Management: covered by the Google domains above

• Blocking *.google.com with narrow allowlisting - some organisations attempt to allowlist only specific Google subdomains. This is fragile, as Google rotates and adds subdomains regularly. The broad *.google.com wildcard is strongly recommended
• SSL inspection - deep packet inspection or SSL decryption on managed device traffic can interfere with certificate pinning used by Google Play Services and the Android Device Policy app. If devices fail to check in or provision, consider exempting Android Enterprise traffic from SSL inspection
• FCM (push notifications) - if FCM is blocked, devices will not receive real-time policy updates and will fall back to periodic polling, resulting in significant delays in policy application
• IP allowlisting - Google rotates IP addresses regularly, it is more reliable to use hostname-based allowlisting

If devices are failing to provision or check in, Google provides a connectivity diagnostics guide. Many EMM platforms also include device-level connectivity checks in their diagnostics tools.

MANAGED INFO HUB also has an Android Enterprise connectivity check baked in for app-derived testing of endpoint accessibility.

This question comes up often and isn’t always simple to answer.

Organisations ideally need to understand the use case for the devices to be selected. This could be normal knowledge worker devices for employees needing a corporate phone, something tough (doesn’t need to be rugged) to withstand harsher environments, or something bespoke such as a kiosk on a reception desk used for checking in or something with an integrated printer/scanner.

After this, consider the minimum Android version required for the features the organisation needs. For example, work profile pausing requires Android 14, Private Space requires Android 15, and the latest provisioning improvements require Android 16. More version-specific comparisons are available in considerations when migrating from device administrator to Android Enterprise.

Additionally, consider:

• Zero-touch support - if the organisation wants hands-off provisioning, ensure the OEM and reseller support zero-touch enrolment
• OEMConfig availability - for Samsung (Knox Service Plugin), Zebra, Honeywell, and others, OEMConfig provides extended management capabilities beyond stock Android Enterprise
• Security update commitment - look for devices offering at least 3-5 years of security patches
• GMS certification - ensure the device is Play Protect certified, as uncertified devices do not support Android Enterprise

The Android Enterprise partner directory is a good starting point for identifying validated devices. If nothing suits requirements, get in touch and I’ll try to help out!

Identity Check is a security feature introduced with Android 16 that requires biometric authentication for sensitive actions, even if someone has the device PIN or password.

When Identity Check is enabled, actions such as changing passkeys, modifying security settings, or accessing sensitive app data require the device owner's fingerprint or face authentication. A PIN, pattern, or password alone is not sufficient for these actions.

How does this affect enterprise?

For managed devices, Identity Check adds a layer of protection against scenarios where a device PIN is compromised or shared. This is particularly relevant for:

• Shared device or shift-based deployments where PINs may be known by multiple people
• High-security environments where biometric verification is required for sensitive operations
• Devices used in environments where shoulder-surfing or PIN observation is a concern

Identity Check can be configured through AMAPI policy on fully managed and corporate-owned work profile devices. Administrators can enforce biometric requirements for sensitive actions without relying solely on the standard screen lock.

This feature is part of Android's broader move towards zero-trust security principles at the device level, complementing existing features like Device Trust signals and hardware-backed attestation.

Android Enterprise supports two management architectures, and they are fundamentally different in how the EMM controls the device.

A custom DPC (Device Policy Controller) is an EMM-developed application that runs on the device and directly calls Android's device management APIs. The EMM builds, maintains, and distributes this app - examples include Omnissa Workspace ONE Intelligent Hub, Ivanti's MDM agent, SOTI MobiControl, and IBM MaaS360.

With a custom DPC, the EMM's own app is the Device Owner or Profile Owner on the device. It receives policy from the EMM server and enforces it locally using DevicePolicyManager and related platform APIs. App distribution is managed through the Google Play EMM API.

This gives the EMM direct control over the enforcement layer, but also means they are responsible for keeping up with Android platform changes, handling compatibility across Android versions, and maintaining the DPC app itself.

With AMAPI, Google provides the on-device management client - Android Device Policy (ADP). The EMM does not build a DPC. Instead, the EMM declares a desired policy state via a REST API, and Google's ADP app on the device enforces it.

The EMM's role shifts from building device-level enforcement logic to managing policy configuration and backend integration. Google handles the on-device agent, platform compatibility, and feature rollout.

AMAPI-based EMMs include Google's own management tools, Microsoft Intune (for BYOD work profiles, with corporate-owned migrations underway), Hexnode, Mosyle, and others. Many traditional custom DPC vendors are also migrating to AMAPI over time.

Google is actively steering the ecosystem towards AMAPI. New custom DPC registrations are no longer accepted, and significant portions of the Play EMM API were deprecated in September 2021 with a final turn-off date of 30 September 2025.

Existing custom DPC EMMs continue to function and are supported, but organisations should be aware that the long-term direction is AMAPI. Many EMMs now offer both architectures during a transition period.

Devices can be migrated from a custom DPC to AMAPI without a factory reset, provided the EMM supports it.

Yes, fully.

Samsung has supported Android Enterprise since Android 5.0 (Lollipop), offering work profile, fully managed, dedicated, and COPE deployment scenarios through any compatible EMM.

From Android 8.0 and Knox 3.0, Samsung further integrated its Knox management platform with Android Enterprise. The Knox Workspace container, for example, uses the Android Enterprise Profile Owner APIs rather than a proprietary implementation. This means managing a Samsung device through Android Enterprise also gives access to the Knox layer underneath.

Samsung devices support all standard Android Enterprise provisioning methods, including zero-touch enrolment (added in late 2020) and Samsung's own Knox Mobile Enrolment (KME) service. Organisations can use either, though configuring both on the same device is not supported.

KPE extends Android Enterprise with Samsung-specific capabilities - granular hardware controls, advanced networking, kiosk customisation, firmware management, and more. KPE Premium licences are provided at no cost, but they must be activated for KSP policies to take effect.

KPE features are accessed through the Knox Service Plugin (KSP), Samsung's OEMConfig implementation. KSP works with any EMM that supports managed app configurations.

From Android 15, several Knox SDK APIs are restricted to apps running as Device Owner or Profile Owner only. From Android 16, all Knox SDK APIs require the Android Enterprise management framework. Legacy Device Administrator deployments on Samsung devices will lose Knox functionality entirely on Android 16 and later.

Yes. From early 2026, AMAPI supports Access Point Name (APN) management through the apnPolicy setting within DeviceConnectivityManagement. This comes after years of support for custom DPC vendors.

Administrators can define APN configurations that are pushed to company-owned devices. These policy-enforced APNs override any user-configured APNs on the device, ensuring consistent cellular connectivity settings across the fleet.

This is particularly relevant for:

• Organisations using private APNs for cellular connectivity
• Deployments where devices must connect through a specific mobile network gateway
• Kiosk and dedicated device deployments relying solely on cellular data

• APN management applies to company-owned devices only (fully managed and COPE)
• The feature requires EMM support - check with your EMM vendor to confirm they have implemented the apnPolicy setting
• Personally-owned work profile devices are not supported for APN policy enforcement

Before this AMAPI addition, APN management was typically achieved through:

• OEM-specific APIs (such as Samsung Knox OEMConfig)
• Custom DPC implementations
• Manual configuration during device setup

The AMAPI approach standardises this across all Android Enterprise-compatible devices running supported Android versions.

From January 2026, AMAPI defaults the enterpriseDisplayNameVisibility setting to ENTERPRISE_DISPLAY_NAME_VISIBLE. This means the enterprise name configured during the Android Enterprise bind setup is now displayed on company-owned devices by default - typically on the lock screen or in device settings.

Previously, the enterprise name was not actively configured, so could result in differing experiences across vendors. The default behaviour change means organisations that never set this policy field are now seeing the enterprise name appear without having made any policy changes.

Through your EMM's AMAPI policy configuration, set enterpriseDisplayNameVisibility to one of:

• ENTERPRISE_DISPLAY_NAME_VISIBLE - the enterprise name is shown on the device (now the default)
• ENTERPRISE_DISPLAY_NAME_NOT_VISIBLE - the enterprise name is hidden

If the enterprise name shown is incorrect or undesirable, the display name itself is configured at the enterprise level during bind setup and can be updated through the AMAPI enterprises.patch method. This will require a support ticket to your EMM vendor.

This applies to company-owned devices (fully managed and COPE) managed through AMAPI-based EMMs. Personally-owned work profile devices are not affected.

When evaluating Android devices for enterprise deployment, two certification types determine the management capabilities available: GMS (through the MADA agreement) and EDLA.

GMS certification is the standard certification for consumer smartphones and tablets. Devices certified under the MADA (Mobile Application Distribution Agreement) include the full suite of Google apps and services - Play Store, Chrome, Gmail, Maps, and critically for enterprise, Google Play Protect and Android Enterprise support.

GMS-certified devices are listed on the Android website and typically support all Android Enterprise deployment scenarios: fully managed, work profile, COPE, and dedicated device (kiosk). Android Go, Android TV, WearOS, etc aren't obviously included in this, though Android XR should fall under much of the same mandate when it's ready.

EDLA certification is designed for dedicated and enterprise-focused devices that may not suit the typical consumer GMS use case. This includes kiosks, digital signage, ruggedised handhelds, point-of-sale terminals, and other single-purpose devices.

• Standard smartphones and tablets for knowledge workers: GMS (MADA) certification. These devices will support all management scenarios and provide the full Android experience.
• Kiosks, signage, ruggedised devices, or other dedicated-use hardware: EDLA certification is typically more appropriate. The devices are designed for purpose and don't carry unnecessary consumer apps, services, and may be more appropriate in terms of formfactor.
• AOSP (uncertified) devices: These have no Google services, no Play Store, and limited Android Enterprise management support. They are not suitable for enterprise management through the Android Management API, but platforms may provide an alternative management framework under AOSP.

No. As of early 2024, Google Play System Updates (Mainline modules) are no longer controlled by Android Enterprise system update policies.

Previously, the system update policy applied to both OTA system updates and Google Play System Updates. This is no longer the case - Mainline updates now download automatically in the background and install on the next device reboot, regardless of any configured system update policy, freeze period, or maintenance window.

This means:

• Freeze periods do not apply to Mainline updates. Even during a configured freeze window, GPSU updates will continue to install
• Maintenance windows are ignored for Mainline update installation
• Postpone policies have no effect on when Mainline updates are applied
• The device behaves like an unmanaged device specifically for Mainline updates

Administrators can still use compliance policies to check that devices have current Mainline modules installed, but cannot directly control the timing of their installation.

OTA system updates (full Android version upgrades and monthly security patches) continue to respect system update policies as before.

For more details, see Google Play System Updates and Android Enterprise.

By default, all new Google Cloud projects using the Android Management API are allocated a "default" quota of 0 devices per project. This is separate from the API request rate limits covered elsewhere.

What the device quota means

The device quota limits how many devices can be enrolled across all enterprises created under a single Google Cloud project. For most organisations using a commercial EMM, this is managed by the EMM vendor and is not something individual customers need to worry about - the EMM's project quota covers their entire customer base.

When this matters

The quota becomes relevant if you are:

• Building a custom management solution directly on the AMAPI
• Running a proof of concept with the AMAPI quickstart
• Operating a smaller EMM platform with a growing device count

Requesting an increase

To obtain an initial quota, you must apply through Google's partner validation process. This involves demonstrating that your solution meets Google's requirements for an EMM partner. The process is documented in the AMAPI permissible usage page.

Note that quota increases are not automatic and require review. Community reports indicate response times of 7 or more business days, with some requests taking multiple weeks. Plan well ahead if you anticipate scaling beyond the default limit - do not wait until devices are failing to enrol before requesting an increase. Initiating the quota request early in the development or procurement phase avoids enrolment failures during growth.

A managed Google domain is an organisation-owned domain (e.g. company.com) registered with Google and managed through the Google Admin console. It replaces the older managed Google Play Accounts enterprise model, where a personal Gmail address was used to create and administer the Android Enterprise bind.

When Android Enterprise originally launched, organisations could bind using any Gmail account. This was simple but introduced risks:

• Account security - a personal Gmail account used for the bind could be compromised, disabled, or lost if the individual left the organisation
• No centralised administration - there was no role-based access, no MFA enforcement, and no SSO integration
• Single-EMM limitation - managed Google Play Accounts enterprises could only bind to one EMM at a time

A managed Google domain addresses all of these. Administration moves to corporate-owned credentials with proper identity governance, and the enterprise can bind multiple EMMs simultaneously - useful for organisations operating across regions or divisions.

Google now directs all new Android Enterprise customers to use a managed Google domain. Existing organisations on the older model are encouraged to upgrade, and Google's 2026 planning guidance lists this as a foundational step.

The upgrade is:

• Free - there is no cost to create a managed Google domain
• Non-disruptive - enrolled devices, approved apps, and EMM configurations remain intact
• One-way - you cannot revert to a Gmail-based bind after upgrading

Google provides a guided migration path. Your EMM vendor may also offer specific guidance for the process.

Follow Google's official upgrade guide: Upgrade to managed Google domain

After upgrading, manage your enterprise through the Google Admin console rather than play.google.com/work.

There is no self-service option to rename the managed Google Play organisation name. For managed Google domain enterprises, the organisation name is inherited from the Google Workspace or Cloud Identity domain configuration and must be changed through the Admin console under Account settings. Choose the name carefully before initiating the bind or upgrade.

In early 2026, Google introduced a Model Context Protocol (MCP) server for the Android Management API. This allows AI assistants - including Claude, Gemini, and ChatGPT - to query enterprise device management data through natural language.

What it does

The MCP server exposes a set of tools that AI applications can call to retrieve information from an AMAPI-managed enterprise. These include:

• Listing enrolled devices and retrieving device details
• Viewing policy configurations
• Checking available applications
• Querying compliance status

This means an administrator could ask an AI assistant questions like "which devices in my fleet are running an outdated security patch?" or "show me the policy applied to this device group" and receive structured answers pulled directly from the AMAPI backend.

Is it read-only?

The initial release focuses on read-only operations. The tools retrieve and display data but do not modify policies, enrol devices, or push changes. This is a deliberate design choice to allow organisations to experiment with AI-assisted management without risk of unintended configuration changes.

Prerequisites

To use the AMAPI MCP server, you need:

• A Google Cloud project with the Android Management API enabled
• Two IAM roles assigned: MCP Tool User (roles/mcp.toolUser) and Android Management User (roles/androidmanagement.user)
• OAuth 2.0 authentication (API keys are not accepted)

The server endpoint is https://androidmanagement.googleapis.com/mcp.

Learn more

You can find a full guide with an example product, here.

Why this matters

For larger enterprises, querying device fleet status, auditing policy compliance, and investigating device issues currently requires navigating EMM consoles or writing API calls manually. The MCP integration enables conversational access to this data, which can speed up troubleshooting and compliance reporting.

This is an AMAPI-level feature, not an EMM feature. Organisations using a commercial EMM (Intune, Workspace ONE, etc.) interact with this through their EMM's console, not directly. The MCP server is most relevant to organisations building custom management solutions on AMAPI or those wanting to supplement their EMM's reporting with AI-driven queries.

Android 15 introduced several enterprise-relevant features and behaviour changes that impact device management.

• Content protection policy - a new AMAPI policy enables enhanced on-device scanning for apps that attempt social engineering tactics, such as fake system dialogs or overlay attacks. This leverages Play Protect's real-time behavioural analysis and is available on fully managed and dedicated devices. See What is the content protection policy in AMAPI?
• Enterprise Factory Reset Protection (EFRP) always enforced - on company-owned devices, EFRP is now enforced after a hard factory reset regardless of whether OEM unlocking was toggled on. Previously, enabling OEM unlocking could bypass EFRP
• Private Space - a new isolated profile area for personal apps, separate from the work profile. On company-owned devices, admins can disable Private Space via policy. See the Private Space FAQ section for details

• Foreground service restrictions - certain foreground service types (camera, MediaProjection, data sync) can no longer be started from BOOT_COMPLETED broadcast receivers. This breaks common patterns used by kiosk management and fleet monitoring agents that relied on starting services at boot
• PendingIntent cancellation on stopped state - PendingIntents registered by an app are now wiped when the app enters the "stopped" state. This affects watchdog and self-healing flows in fleet management agents that relied on persistent alarms
• Edge-to-edge display enforcement - apps targeting API 35 are forced into edge-to-edge rendering, which can break kiosk app layouts that assumed fixed system bar dimensions. See Why is my kiosk app UI broken after updating to Android 15?.

• Initial support for deploying and managing eSIM profiles on company-owned devices, including the ability to push full and partial eSIM configurations and prevent their removal

For a full list of enterprise changes, refer to What's new for Android in the enterprise on the Android Developers site, and check out Android 15: What's new for enterprise? for a detailed breakdown.

Conditional access allows organisations to gate access to corporate resources based on whether a device meets defined security and compliance requirements. The concept applies across EMM platforms, though the implementation and terminology varies.

How it works

The EMM evaluates the device against a compliance policy - checking signals such as OS version, security patch level, encryption status, root detection, and Play Protect status. The result (compliant or non-compliant) is shared with the identity provider (such as Microsoft Entra ID, Okta, or Google Workspace), which then permits or blocks access to corporate applications and data accordingly.

Common compliance signals for Android Enterprise

• Minimum OS version and security patch level
• Device encryption enabled
• Root/bootloader unlock detection (via Play Integrity or equivalent)
• Google Play Protect scanning enabled
• Device not jailbroken or rooted
• Minimum EMM agent version
• Password complexity requirements met
• No blocked applications installed (work profile scope)

Deployment model considerations

• Work profile (BYOD): Compliance is evaluated within the work profile scope. Personal-side signals are limited by design - organisations cannot see personal applications or data
• Fully managed: Full device compliance is possible, including hardware attestation and broader policy evaluation
• COPE: Combines work profile isolation with company-owned device compliance, offering a middle ground
• Dedicated devices: Compliance targets device groups rather than user groups, since dedicated devices may not have user-associated accounts

Device Trust

For organisations wanting compliance signals without full EMM enrollment, Device Trust from Android Enterprise provides over 20 device signals accessible via the AMAPI SDK. This enables zero-trust architectures where access decisions are made based on device posture without requiring a work profile or full management.

Best practices

• Start with report-only mode before enforcing conditional access policies, to identify devices that would be blocked
• Set realistic compliance windows - give users time to update before blocking access
• Communicate clearly to end users what compliance requirements exist and how to remediate
• Test across device manufacturers, as OEM-specific behaviours can affect compliance signal reporting

There is no self-service option to rename a managed Google Play organisation after it has been created.

The organisation name set during the Android Enterprise bind is visible in several places:

• The managed Google Play store (shown to end users)
• The Google Admin console (for managed Google domain enterprises)
• On managed devices when enterpriseDisplayNameVisibility is enabled (the AMAPI default since January 2026)

If the wrong name was entered during bind setup, or the company has rebranded, there is no edit button in any console to change it.

For AMAPI-managed enterprises:

The enterprise display name shown on devices can be updated through the AMAPI enterprises.patch method by setting the enterpriseDisplayName field. This typically requires a support ticket to your EMM vendor, as most EMM consoles do not expose this setting directly.

Note that this changes the display name on devices only - it does not change the underlying organisation name in managed Google Play or the Google Admin console.

It also only applies to new enrolments, so this is a limited option.

For the underlying organisation name:

• Managed Google Play Accounts enterprises - no rename option exists. The only path is to delete the enterprise bind entirely and recreate it, which requires re-enrolment of all devices
• Managed Google Domain enterprises - the organisation name is tied to the Google Workspace/Cloud Identity domain configuration. Changes to the organisation name must be made through the Google Admin console under Account settings

Choose the organisation name carefully during bind setup. If using a managed Google domain, ensure the domain's organisation name is correct before initiating the Android Enterprise bind, as the name is inherited from the domain configuration.

Android One and Android Enterprise Recommended were two different programmes with some overlap in their focus on security and consistency.

Android Enterprise Recommended is an active validation programme ensuring devices meet Google's minimum enterprise requirements - including hardware specifications appropriate for enterprise use. OEMs must publicly disclose the end date for security update support per device. OEMs maintain their own UIs, bundled apps, and value-adds. Note that Google dropped the mandatory 90-day security update and minimum OS upgrade requirements from the programme several years ago.

Android One went further on the software side. Devices in the programme used a system image developed with Google, offering a near-stock experience with minimal bloat. Security updates were required every 30 days, and devices supported two major OS upgrades - commitments that were stronger than AER at the time.

When combined, the two programmes offered a strong proposition: a clean, fast device with enterprise validation and aggressive update commitments.

In practice, the distinction is now historical. The Android ecosystem has matured significantly since Android One's peak. Leading OEMs like Samsung and Google now ship up to seven years of updates on flagships, with several years of support increasingly common on mid-range devices, making the update advantage Android One once held far less relevant. AER remains the active programme organisations should focus on for device selection, alongside checking the specific OEM's published update commitments for each device model.

AER is Google’s validation programme for devices, EMMs, and MSPs.

Each will have a list of requirements to meet in order to validate, and will re-validate on an annual basis. AER for Carriers was announced in 2018 but was subsequently shelved by Google.

• Devices - must meet minimum hardware specifications, publicly disclose the security update support end date and update frequency, support at least one major OS upgrade (with a recommendation of up to seven for Android 16 devices), and pass Android Enterprise management compatibility testing. The programme includes standard, rugged, and dedicated device categories. Note: the previous mandatory 90-day security patch requirement was dropped for devices validating on Android 15 and later; OEMs must now instead publish their update cadence and end-of-support date for transparency
• EMMs - must support a defined set of Android Enterprise management features across all deployment scenarios
• MSPs - must demonstrate competency in deploying and supporting Android Enterprise for their customers

Validated vendors re-validate on an annual basis.

AER is a minimum bar, not a seal of quality. A device being AER-validated means it met the requirements at the time of validation. It does not guarantee:

• Timely delivery of future security patches beyond the commitment period
• Bug-free Android Enterprise behaviour
• Feature parity with other AER devices

Organisations should still evaluate devices against their own requirements, ideally through hands-on testing, rather than relying solely on AER status for procurement decisions.

More details: What is Android Enterprise Recommended?

A major Android OS update (such as Android 15 to 16) delivered via OTA is not a factory reset - device management state, profiles, apps, and data all persist through the upgrade. There is no re-enrolment required.

• Device owner / profile owner registration - the DPC remains registered as device or profile owner after the reboot into the new OS version
• Work profile - the profile, its apps, and all work data remain intact
• Policies - enterprise policies continue to apply. The device syncs with the EMM on next check-in and re-applies the current policy set
• Managed configurations - app-level managed configs are retained and continue to be served by the RestrictionsManager
• App data - both personal and work app data persist, just as with any OTA update
• Zero-touch / KME registration - cloud enrolment registrations are unaffected by OTA updates, as these are server-side records

Major version updates can introduce behavioural changes that affect managed devices, even without a re-enrolment:

• Deprecated APIs and policy changes - each Android version may deprecate or change the behaviour of management APIs. For example, Android 11 fundamentally changed the COPE model, automatically migrating legacy COPE devices to the new work profile on company-owned device experience during the upgrade. See Android 11 COPE changes for details
• App compatibility - apps targeting older SDK versions may lose functionality or encounter permission changes under a newer OS. Android 14 introduced a minimum targetSdkVersion requirement for app installation, and Android 15/16 raised it further
• UI and behaviour changes - Android 15 introduced edge-to-edge enforcement for apps targeting API 35, and Android 16 extends this with large screen layout changes. Kiosk and dedicated device apps are particularly affected. See edge-to-edge FAQ
• OEM-specific bugs - major OS updates from OEMs occasionally introduce enterprise-related issues. Samsung devices have historically seen zero-touch enrolment failures and work profile issues following major updates
• Sticky configurations - in some Android versions, certain configurations have been observed to become permanently applied after a reboot, making them unchangeable without re-enrolment. This was notably documented on Android 14

• Use system update policies - device owners can set automatic, windowed, or postpone policies to control when OTA updates install. Postponement provides up to 30 days per update for testing. See managing system updates for more on what these policies control
• Use freeze periods - on Android 9+, freeze periods can suspend all system updates for up to 90 days, giving time to validate compatibility with business-critical apps. A 60-day gap between freeze periods is required
• Test with a pilot group - enrol test devices on the new OS version before allowing the update across the wider fleet. Most EMMs support phased rollout by device group
• Review version-specific changes - Google publishes enterprise-specific changes for each Android version at What's new for Android in the enterprise. Check for deprecations, new restrictions, and behavioural changes that may affect deployed policies or apps
• Monitor OEMConfig compatibility - OEMConfig apps may need updates to support new OS versions. Check with the device manufacturer for updated OEMConfig releases ahead of major OS rollouts

System update policies apply only to fully managed and dedicated devices. For work profile (BYOD) deployments, the device owner is the end user, and the organisation has no control over when OS updates are installed.

If your organisation uses Google Workspace (or Cloud Identity) and wants to manage Android devices through a third-party EMM, the Workspace side of the setup is straightforward. There are three things to do, and an optional fourth.

Google Workspace includes its own device management - Google Endpoint Management (GEM). This must be turned off for any organisational units that will be managed by the third-party EMM. Not set to Basic - turned off. Basic still applies GEM policies and collects device inventory, which can cause unexpected issues.

Admin Console > Devices > Mobile & endpoints > Settings > Universal > General > Mobile management

Select the target OU, choose Turn off mobile management, and save.

The EMM handles this through the standard Android Enterprise signup flow. During setup within the EMM console, the admin is redirected to Google to authenticate with a super administrator account. This creates the enterprise binding - an enterprise ID tied to the managed Google domain. There's no token to copy or code to enter; the EMM orchestrates the process.

Since mid-2024, a single managed Google domain can support multiple EMM bindings, each with its own enterprise ID. This is useful during migrations or where different parts of the organisation use different EMMs.

Once the binding exists, it appears in the Admin Console under:

Admin Console > Devices > Mobile & endpoints > Settings > Third-party integrations > Android EMM

Select the OU and assign the EMM provider. Different OUs can use different EMMs.

In the same section, there is an Authenticate Using Google toggle per EMM provider. When enabled, end users enrolling devices through that EMM are required to sign in with their Google Workspace account during enrolment. This is optional and depends on EMM support.

That's it. The third-party EMM takes over Android Enterprise management for the assigned OUs, and GEM stays out of the way.

Yes. Google has published Android Enterprise for Android XR documentation, confirming management support for XR headsets and wired glasses.

Management is possible on fully managed devices only. There is no work profile - COPE or BYOD - support. EMMs may use AMAPI or a custom DPC.

The XR validation requirements are adapted from the standard mobile set:

• Core management is intact - provisioning (QR, zero-touch, DPC identifier), security (passcode, wipe, compliance, Play Integrity), silent app distribution, managed configurations, Wi-Fi, certificates, and system update policies are all required
• Camera and screen capture controls are mandatory - reflecting the always-on spatial cameras in XR headsets
• Dedicated device features are included - lock task mode, persistent preferred activities, and dedicated device security policies are part of the XR validation, confirming Google expects many XR deployments to be kiosk-style
• Some mobile features are relaxed or removed - NFC provisioning, eSIM, Smart Lock, keyguard features, and advanced IME management are absent. Advanced VPN, store layouts, and several Play management features are recommended rather than required

• Lock task mode supports a single 3D app only. No status bar means no notifications or Quick Settings in lock task
• Media Projection (screen casting) must be limited to 2880x2880 resolution
• Custom DPCs for XR require managed Google Accounts for enrolment

• Samsung Galaxy XR - the only shipping Android XR headset (launched October 2025). Samsung Knox management is also available
• XREAL Project Aura, Samsung smart glasses, and Google AI glasses are announced for 2026 but not yet available

• Fully managed only - XR devices are company-owned, purpose-deployed hardware under this management model
• Confirm EMM support before purchasing at scale. Not all EMMs will have XR support immediately
• Samsung Knox provides additional management capabilities for Galaxy XR alongside Android Enterprise
• Test lock task mode carefully if planning kiosk-style deployments - the single 3D app limitation and lack of notifications are material constraints

For a detailed analysis including the full feature comparison with mobile validation, see Android Enterprise lands on Android XR.

Yes. On devices and networks that support 5G network slicing, AMAPI can route traffic for specific applications through dedicated enterprise slices rather than the default carrier data path.

A 5G network slice is a logically separate path through the carrier network with its own quality of service, latency, and bandwidth characteristics. An enterprise can subscribe to one or more slices from a participating carrier and configure managed devices to use them.

In AMAPI, this is controlled through two policy fields:

• preferentialNetworkService at the policy level enables preferential network service on the device
• preferentialNetworkServiceSettings defines up to five preferential network configurations, each identified as PREFERENTIAL_NETWORK_ID_ONE through PREFERENTIAL_NETWORK_ID_FIVE
• preferentialNetworkId on each application policy assigns that application to one of the configured slices. A defaultPreferentialNetworkId can also be set at the policy level for any application that does not specify one

• Device must be running Android 13 or later for per-app routing on fully managed devices. Work profile-wide routing (all work apps through one slice) has been possible since Android 12
• The device must support 5G slicing and be connected to a 5G network from a carrier that has provisioned slices for the enterprise
• The enterprise must have a commercial arrangement with the carrier to obtain slices and the mapping between PREFERENTIAL_NETWORK_ID_n values and actual carrier slices
• The EMM must expose the relevant AMAPI fields in its console. Not all EMMs have exposed these yet

• Guaranteeing bandwidth for a video conferencing or field-service app during periods of congestion
• Separating payment or point-of-sale traffic onto a slice with defined latency and routing guarantees
• Routing CCTV, telemetry, or industrial IoT app traffic through a dedicated slice distinct from general browsing and messaging

• Slicing is a carrier capability, not a device capability alone. Without an enterprise slice provisioned by the mobile network operator, the policy has no effect
• Slicing does not substitute for an enterprise VPN. Slicing controls the path through the carrier network; it does not by itself terminate the traffic inside the corporate network
• Coverage for 5G slicing remains limited geographically and by carrier in 2026, so organisations should confirm coverage in the regions where devices operate before relying on it

Android 16 introduces several enterprise-relevant features and policy enhancements. It also marks the shift to a semi-annual release cadence, with a major platform update in Q2 and a smaller feature update in Q4 each year.

Network management

• Block the use of Thread networks on managed devices
• Enable or disable the NFC controller
• Configure APN settings via AMAPI
• Support for 5G network slicing configuration

Provisioning and setup

• Streamlined enterprise setup flow, reducing provisioning steps and failure rates
• Zero-touch customer portal improvements including audit logging and granular admin roles
• Automatic time and timezone configuration control

App management

• Managed Google Play now supports Android App Bundles (AAB) for private apps, simplifying deployment and updates
• AppFunctionManager policy for controlling app function availability

Device information

• Admins can retrieve device EID values for both corporate-owned and BYO devices, supporting eSIM management workflows

Security

• Advanced Protection mode brings Google's strongest security features to enterprise devices with a single toggle
• Identity Check requires biometric authentication for sensitive app access when outside trusted locations

Large screen behaviour changes

• Apps targeting API 36 can no longer enforce fixed orientation, aspect ratio, or resizability restrictions on displays with a smallest width of 600dp or greater
• android:screenOrientation, android:resizeableActivity="false", and aspect ratio declarations are ignored on these displays
• This does not affect phones (sub-600dp screens), and lock task mode itself is unaffected — the change is in how apps render within a locked context
• Kiosk and dedicated device deployments on tablets or large-screen hardware should audit apps for fixed orientation or non-resizable declarations, and test on target hardware before rolling out Android 16
• Privately distributed apps not published to the public Play Store are not immediately required to target API 36, but apps submitted to Google Play must target API 36 from August 2026

For a full list of enterprise changes, refer to What's new for Android in the enterprise on the Android Developers site.

Samsung Knox extends Android Enterprise with additional device management capabilities through the Knox Service Plugin (KSP), an OEMConfig-based application. Understanding how these layers interact is important for avoiding policy conflicts.

Android Enterprise provides a standard set of management APIs that work across all certified Android devices. Samsung Knox adds Samsung-specific APIs on top, accessible through KSP.

When managing Samsung devices, an EMM typically applies:

1. Android Enterprise policies - standard restrictions, app management, compliance rules
2. Knox Service Plugin policies - Samsung-specific features like firmware update control, hardware key remapping, Samsung DeX management, and enhanced security settings

KSP is deployed as a managed application with managed configurations. The EMM pushes a configuration profile to KSP, which then applies the Samsung-specific policies locally on the device.

Some policies exist in both Android Enterprise and KSP. If the same policy is set in both, the device may not apply them predictably. Common overlap areas include:

• Wi-Fi configuration
• Password/passcode requirements
• Camera restrictions
• Screen capture restrictions

Best practice: set each policy in only one place. If a capability is available through both standard Android Enterprise and KSP, choose one and be consistent across your policy set.

KSP supports all Android Enterprise management modes: fully managed, dedicated, personally-owned work profile, and COPE (work profile on company-owned device). All modes require Android 9.0 with Knox 3.2.1 or later. Note that the COPE implementation changed significantly in Android 11 - for Android 9-10 this was "work profile on fully managed device", while Android 11 and later uses "work profile on company-owned device".

If KSP policies are not applying as expected:

• Enable verboseMode in the KSP managed configuration to see which policies are deployed
• Ensure the KSP app is up to date - version mismatches between the console configuration and the on-device KSP version can cause failures
• Check for policy overlap with standard Android Enterprise settings

For more on OEMConfig generally, see What is OEMConfig?.

The account type chosen for an Android Enterprise deployment determines how managed Google Play accounts are created, how many devices a single account can serve, and - on Play EMM API-backed platforms - whether an incorrect choice could cap enrolment at ten devices.

This distinction applies to managed Google Play accounts - the Google-account flavour created automatically as part of Android Enterprise enrolment. Google Workspace deployments can avoid the switch entirely by authenticating users with their Workspace identity, but if "authenticate with Google" is disabled, the same managed Google Play account model (and the same device/user choice) applies.

User-based accounts are tied to an EMM user identity. The same managed Google Play account is reused across every device that user enrols, so app entitlements, history, and approvals follow the user from device to device.

Device-based accounts are created per device. Each device gets its own unique, throwaway managed Google Play account with no concept of a human owner. Two devices enrolled "by the same user" receive two completely separate Google accounts.

• Dedicated / kiosk / COSU deployments, where no human identity is associated with the device
• Fully managed corporate-owned devices in most real-world fleets
• Bulk / staging enrolment, where one operator enrols hundreds of devices under their own EMM login before handing them out
• Rugged, shared-use, and shift-worker devices that pass between multiple humans
• Any scenario where a single EMM user account will enrol more than 10 devices

• BYOD work profile deployments where the device belongs to a named individual and per-user Play entitlements or app purchase continuity matter
• 1:1 corporate-owned work profile where the human-to-device mapping is permanent
• Deployments small enough that the 10-device limit will never be hit per user

In practice, most modern deployments default to device-based accounts unless there is a specific reason to preserve per-user Play state.

AMAPI abstracts this decision away from administrators. Managed Google Play accounts are created and destroyed as part of the device provisioning lifecycle, and the user field on the enrolment token is deprecated and ignored - EMMs no longer control account grouping at the API level.

In practice, AMAPI-based EMMs create a fresh per-device account for fully managed and dedicated deployments, and create a single account tied to the named user for BYOD work profile enrolments. The behaviour is determined by the enrolment flow the EMM exposes (corporate-owned vs personally-owned), not by an administrator-facing toggle. Check your EMM's documentation if you need to confirm what it does for a given enrolment type.

Custom DPC / Play EMM API platforms - think older Ivanti EPMM, AirWatch/Omnissa Workspace ONE, MaaS360, and similar - handle this explicitly. The EMM calls Users.insert (or generateAuthenticationToken flows) with an accountIdentifier it chooses, and whether that identifier represents a human user or an ephemeral device account is the EMM's implementation choice. This is where the setting is usually exposed to administrators as a literal "device-based vs user-based" toggle.

When the bind is established with a Google Workspace domain and authenticate with Google is turned on, devices are associated with Workspace user accounts directly. If authenticate with Google is disabled, it follows the path of the approaches listed above.

The 10-device cap also applies here. So be mindful that users may over time need to remove old devices from their Google accounts.

Google has transitioned the root certificate used in Android hardware key attestation chains. This affects any organisation or service that validates attestation certificates from Android devices.

Timeline:

• February 2026: New root certificate introduced alongside the existing root
• April 10, 2026: RKP-enabled devices (Remote Key Provisioning) now exclusively use the new root certificate. From this date, all attestation chains from RKP-enabled devices are rooted in the new ECDSA P-384 key

Who is affected?

Any system that validates Android key attestation certificates needs to update its trust store to include the new root. This includes:

• EMM platforms performing device integrity checks via attestation
• Zero-trust access solutions using hardware-backed key attestation
• Solutions that verify device attestation as part of compliance
• Identity providers using Device Trust signals alongside attestation

What should I do?

1. Check whether your attestation verification system hardcodes the existing root certificate
2. Ensure the new root certificate is present in your trust store. The April 10 cutover has now passed and chains from RKP-enabled devices will fail validation against trust stores that still only contain the old root
3. Test attestation validation against both roots, since factory-keyed devices continue to chain to the old root
4. If you rely on a commercial EMM or identity provider, confirm with your vendor that they have updated their systems

The new root certificate is published in Google's key attestation documentation.

Any attestation verification system that did not add the new root before April 10, 2026 will now reject certificates from RKP-enabled devices, which includes most modern Android devices. Both the old and new root certificates are published at https://android.googleapis.com/attestation/root. Older devices with factory-provisioned keys that do not support key rotation will continue using the previous root indefinitely, so trust stores must retain both roots.

Yes, however this process needs to be supported by the EMM. Few EMMs support this today, so it’s important to ask your vendor (or prospective vendor) if this is something you’d like to do.

The process itself will vary, but it may range from a checkbox in a profile to assigning a specific configuration, or simply a change at the folder/org/group level settings the devices sit within.

Once the process begins, affected devices will be prompted by the DPC to begin work profile setup. In this process the DPC will migrate from the parent profile (device) to a work profile. Understandably many legacy profiles/configs/policies will cease to function and so equivalent Android Enterprise policies should be in place.

Android 8-10 – Yes. This is because the DPC sits both in and outside of the work profile normally, and the DPC will collect an app inventory surrounding it. Organisations can opt to disable this within the EMM under a privacy policy, and EMMs may even disable it by default, however do consider there is a privacy consideration when installing personal applications.

Android 11+ – No, this is because in Android 11, work profiles on fully managed devices was deprecated in favour or work profiles on company owned devices. This new deployment scenario aligns the privacy aspect with that of a work profile deployment, because it sort-of is one.

When a device is deployed as a company owned work profile (COPE) or personally owned work profile (BYOD) device, a secondary profile is created on the device known as a work profile. This is where all corporate apps and data reside on the device, and is fully isolated and separately encrypted on the device.

Unless explicitly set, the work profile doesn't have any additional authentication required, allowing an end-user to open work applications on the device as desired.

A work challenge is what Google call the password applied to the work profile that shares most of the same policies associated with a device password policy. It can be applied in the following ways:

• For devices with no device password set, as the only password required on the device, and only prompted when work apps are opened.
• For devices with a password set, to share the device password between the device and the work profile (when unlocking the device, the work profile also unlocks).
• For devices with a password set, to require a unique password for the work profile, requiring additional authentication when work apps are opened.

Here's an example of a work challenge policy requiring a unique password on a device:

Note the scope above is set to Profile (as in, the work profile). This sets a work profile-specific password policy that has no impact on the parent policy directly.

I say directly, because unless a policy is set mandating a separate work and personal password as pictured above, the end user is able to adopt the work profile password as the device password also, through the device setting Use one lock.

By mandating separate profile passwords, this avoids that.

No.

It is not possible to deploy applications into the parent profile in a personally-owned work profile deployment. This is covered, as well as other aspects of this use case, with considerations when deploying MTD with Android Enterprise.

Yes.

As of 2020, Intune supports work profiles on fully managed devices from Android 8.0. This is because Google’s Android Management API introduced support for the deployment scenario (albeit silently, intentionally avoiding stating as such in its wider Android 11 COPE announcement).

There are a few options available:

Reboot the device and re-enrol as sometimes all it takes is a reboot, and the EMM will prompt its deletion as it provisions the profile once again.

Manually delete the work profile by heading to Settings > Accounts. The work profile will be listed and should be removable here.

Connect the device to ADB if the profile still won’t delete. This requires enabling ADB debugging on the device via Developer options and a working ADB setup on a computer. A Google search will assist in getting this setup if necessary. Once the computer can detect the device over ADB, run the following:

adb shell pm list users

This should return a list of active users where user 0 is the parent (device/default) user, and any other number (10, 12, 200 etc) should be the work profile.

Users:
  UserInfo{0:Owner:4c13} running
  UserInfo{12:Work profile:1030} running
  UserInfo{150:Secure Folder:10061030} running

To remove the work profile run:

adb shell pm remove-user 12

Making sure of course the number reflects the returned value in the previous command.

This should remove the work profile.

When a work profile is removed - whether by the admin, the user, or an automated compliance action - everything inside the work profile is deleted. Everything outside it is left untouched.

• All apps installed within the work profile
• All app data within those apps (emails, files, cached data, databases)
• The managed Google Play account (or managed Google account) associated with the work profile
• Work contacts, work call logs, and work calendar entries
• Files and downloads stored within the work profile's isolated storage
• All policies and configurations set by the EMM
• On Android 16+, managed eSIM profiles on personally-owned devices are always wiped when the work profile is removed

• All personal apps and personal app data
• Personal photos, files, and downloads
• Personal Google account(s) and their data
• Personal contacts, call logs, and messages

On Android 11+ COPE devices, removing the work profile works the same as BYOD - work data is deleted, personal data survives, and the device transitions to an unmanaged personal device.

On Android 8-10 COPE (legacy WPoFMD), the behaviour was different. Removing the device owner triggered a factory reset, wiping everything. Removing only the work profile while the device owner remained intact left the device in a partially managed state, which most EMMs handled by forcing a full wipe.

• Admin-initiated remote wipe: The EMM admin issues a corporate wipe command. Only the work profile is removed on BYOD and Android 11+ COPE.
• User-initiated removal: Users can delete their own work profile from device settings. On company-owned devices, this may be restricted or show a message directing the user to contact IT.
• Compliance enforcement: If the device remains non-compliant with policy (password, encryption, patch level), the EMM may automatically remove the work profile. For AMAPI-based EMMs, the default is to remove the work profile after 10 days of non-compliance, though this is configurable.
• Account invalidation: If the managed account associated with the work profile is revoked or becomes invalid server-side, the work profile will eventually stop functioning and may be removed.

On fully managed devices (no work profile), a wipe command or unenrolment triggers a full factory reset. All data on the device is erased. There is no personal/work separation to preserve.

See also: What can my organisation see on my managed device?

The work profile runs a separate instance of Google Play Services, maintains its own app data, and syncs independently from the personal side of the device. This effectively doubles some of the background processes that would otherwise run once, and can result in noticeable battery impact.

Common contributors to work profile battery drain include:

• Google Play Services - the work profile runs its own instance of Play Services, which handles push notifications, account sync, and Play Protect scanning independently
• App sync frequency - work apps such as Outlook, Teams, or Slack maintain their own sync schedules within the work profile. If multiple apps are syncing frequently, the cumulative impact adds up
• Battery optimisation exclusions - some EMM vendors recommend or require that certain work apps are excluded from Android's battery optimisation (Adaptive Battery, Doze). This prevents the OS from hibernating those apps, increasing background activity
• Play Protect scanning - Play Protect runs separately within the work profile, scanning installed apps on its own schedule

For end users:

• Check battery usage in Settings to identify which work profile apps consume the most power
• Reduce sync frequency for work apps where possible (if not enforced by policy)
• Ensure the device OS and work apps are up to date, as battery improvements are shipped regularly
• Turn the work profile off when not needed, Digital Wellbeing allows scheduling this also.

For administrators:

• Review app sync and refresh policies - aggressive sync intervals across multiple apps compound battery drain
• Avoid blanket exclusions from battery optimisation unless genuinely required
• Consider deploying fewer apps to the work profile where practical
• On Samsung devices, check the Device Care battery settings for work profile apps being kept active unnecessarily

There is no way to eliminate the overhead of running a work profile entirely, as the separation is fundamental to how the profile provides data isolation. However, the impact should be manageable on modern devices with reasonable app deployment and sync configurations.

Delayed or missing notifications from work profile apps is a common complaint, particularly for messaging and email applications like Teams, Outlook, and Slack.

The most frequent cause is Android's battery optimisation. Adaptive Battery and Doze mode aggressively limit background activity for apps that are not being actively used, and work profile apps are not exempt from this by default. When a work app is hibernated by the system, it cannot process push notifications until the next maintenance window, which may be minutes or longer.

On the device:

1. Open Settings > Apps and select the affected work app (look for the briefcase icon)
2. Tap Battery and set it to Unrestricted (rather than Optimised or Restricted)
3. On Samsung devices, also check Settings > Battery > Background usage limits and ensure the app is not in the sleeping or deep sleeping list

Via EMM policy:

• Some EMM platforms allow administrators to configure battery optimisation exemptions for specific apps. Check your EMM documentation for managed configuration options

Other considerations:

• Ensure the notification permission is granted for the app (required from Android 13 onwards - see How do I manage the new notifications runtime permission in Android 13?)
• If the work profile is paused, notifications from work apps will not be delivered until the profile is resumed
• Network restrictions or VPN configurations that only apply within the work profile may also delay push notification delivery if the connection is intermittent

Yes. Users can turn off the work profile through the quick settings tile or device settings. When the work profile is turned off:

• Work apps are greyed out in the launcher and cannot be opened
• Work notifications stop
• Work apps are fully stopped and cannot run in the background
• The work profile user enters a shutdown state

When the profile is turned back on, apps restart and begin syncing. This can result in a flood of notifications arriving at once, particularly if the profile has been off for a while.

From Android 10, users can also schedule the work profile to turn off and on automatically through Digital Wellbeing. This allows setting a recurring schedule - for example, turning the work profile off at 6pm and back on at 8am on weekdays - to support work-life balance without needing to toggle it manually each time.

Administrators can limit how long a user may leave the work profile off through the workProfileMaxDaysWithNoWork policy in AMAPI (or the equivalent setting in the EMM console). If the profile remains off beyond this limit, the user is prompted to turn it back on. If they do not, the work profile data may be wiped depending on the compliance policy in place.

MAM (Mobile Application Management) and work profiles are both approaches to protecting corporate data on personal devices, but they work differently.

MAM (app protection policies)

MAM applies data loss prevention policies at the application level without requiring device enrolment. The EMM manages individual apps rather than the device. This is sometimes called "MAM without enrolment" or "MAM-only". With MAM:

• No device enrolment is required
• Policies apply only to supported apps (typically Microsoft or apps integrated with the MAM SDK)
• Corporate data within those apps is protected (copy/paste restrictions, save-as controls, encryption)
• The organisation has no visibility into the device itself
• There is no separate container - managed and personal apps coexist in the same space

Work profiles (Android Enterprise)

A work profile creates an operating system-level container that separates work apps and data from personal apps and data. With work profiles:

• The device is enrolled with the EMM
• All apps within the work profile are managed, regardless of whether they have MAM SDK integration
• Data separation is enforced by Android at the OS level, not by individual apps
• The organisation gains device-level compliance information (OS version, patch level, encryption status)
• VPN, Wi-Fi, and certificate configurations can be deployed to the work profile

Which should I use?

Work profiles provide stronger isolation and broader app support. MAM is lighter-touch and may be preferred when enrolment is not desired or when only a small number of specific apps need protection. Some organisations use both: work profiles for users who need full corporate app access, and MAM-only for users who need access to just one or two apps (such as email).

The choice is often EMM-specific. Not all EMMs support MAM without enrolment on Android, and the available policy controls vary.

No.

User applications and app data residing outside of the work profile are not visible to the DPC within a work profile. System applications are, however once again the data associated with the apps is separately stored, meaning personal account details associated with Gmail would not show up alongside a corporate exchange account within the EMM.

On devices running Android 10 and earlier, there were isolated instances where during enrolment the DPC could briefly collect a list of personal applications installed before migrating into the work profile. This behaviour was addressed and is no longer possible from Android 11 onwards.

As of Android 11 this answer also applies to COPE, work profiles on company owned devices.

This is one of the most common questions from employees whose organisation has deployed a work profile on their personal device.

What your employer can see:

• Applications installed within the work profile
• Data associated with work apps (email, files, contacts within the work profile)
• Device-level information: device model, OS version, serial number (company-owned), and security patch level
• Whether the device meets compliance requirements (screen lock enabled, encryption status, OS version)

What your employer cannot see:

• Personal apps and app data outside the work profile
• Personal browsing history, photos, messages, or contacts
• Personal email accounts
• Location (unless a work app explicitly requires it and you have granted permission)
• Call logs or SMS messages on the personal side

The work profile creates a separate, isolated container on the device. Work apps appear with a small briefcase badge to distinguish them from personal apps. Your organisation's management policies apply only within this container.

Your employer can remove the work profile remotely, which deletes all work data from the device. This does not affect personal data, apps, or accounts outside the work profile.

For more on how the work profile works, see What is Android Enterprise and why is it used?.

No. There is no supported method to migrate a device from fully managed (Device Owner) to COPE - work profile on company-owned device (Profile Owner) - without a factory reset.

This is an Android platform constraint, not an EMM limitation. The management mode is set during initial device provisioning and cannot be changed in-place. There is no API in DevicePolicyManager or AMAPI to convert a Device Owner into a Profile Owner, or to add a work profile to an already-provisioned fully managed device while simultaneously changing the management architecture.

Fully managed and COPE are fundamentally different architectures:

• Fully managed: The EMM holds Device Owner. The entire device is under corporate control with no profile separation.
• COPE (Android 11+): The EMM holds Profile Owner with a subset of device-level policies. There is a clear separation between a personal profile and a work profile, with privacy protections aligned to the BYOD model.

Converting between these modes would require restructuring the device's user and profile architecture at the OS level - creating a personal profile, migrating user data, and downgrading the DPC from Device Owner to Profile Owner. Android does not support this.

The AMAPI DPC migration feature only supports migrating from a custom DPC to Android Device Policy within the same management mode. It cannot change the mode itself. A fully managed device migrated via DPC migration remains fully managed.

The only path from fully managed to COPE is a factory reset and re-enrolment:

1. Back up any user data on the device that needs to be preserved.
2. Wipe the device through the EMM or manually.
3. Re-provision as COPE using QR code or zero-touch enrolment. Note that NFC provisioning and afw# are not available for COPE on Android 11+.
4. Restore work apps and data through Managed Google Play and any managed configurations.

For organisations managing large fleets, plan this as a phased rollout. Zero-touch and Samsung KME can streamline reprovisioning significantly by ensuring devices automatically enrol into the correct COPE configuration on first boot after reset.

Prior to Android 11, COPE was implemented as a "fully managed device with a work profile" (sometimes called WPoFMD). The device was provisioned as fully managed first, and a work profile was added on top. The EMM held full Device Owner control over the entire device.

Android 11 replaced this with a new architecture where the EMM acts as Profile Owner only, with a defined subset of device-level policies. This change improved user privacy but also means there is no continuity between the old and new COPE models. Devices running the old WPoFMD model on Android 9-10 cannot be migrated to the modern COPE model without a factory reset.

For more on the Android 11 COPE changes, see Android 11 COPE changes.

Work profile enrolment can fail for several common reasons. Here are the most frequent causes and how to address them:

Insufficient storage

The work profile requires a minimal amount of free storage to create. If the device is low on storage, the work profile creation will fail silently or with a generic error. Free up space before attempting enrolment again.

Outdated management application

Most EMMs require a current version of their management application (such as the Microsoft Company Portal, or the relevant EMM agent) to complete enrolment. If the management app is outdated, update it from Google Play before retrying.

Existing work profile already present

A device can only have one work profile at a time. If a previous enrolment attempt partially completed, a residual work profile may exist. Navigate to Settings > Accounts (or Settings > General management > Work profile) and remove the existing work profile before re-enrolling. See how to remove a residual work profile for more guidance.

Google Play Services issues

Ensure Google Play Services is up to date. An outdated or corrupted Play Services installation can prevent the work profile from being provisioned. Clear the cache and data for Google Play Services, then update it.

Device not supported

Some older or uncertified devices may not support the work profile. Ensure the device is GMS certified and running a supported version of Android.

Network connectivity

The device needs a stable internet connection throughout enrolment. The process involves downloading the management app into the work profile, syncing policies, and installing assigned applications. Intermittent connectivity can cause failures at any stage.

Account restrictions

If the organisation uses a managed Google domain, ensure the user's Google account is not restricted from enroling. Check for domain-level restrictions in the Google Admin console that may prevent work profile creation.

If none of these resolve the issue, check the EMM admin console for device-specific enrolment logs and error codes.

The short answer is no - not on any modern COPE deployment. The longer answer depends on which era of COPE is in question.

On Android 8-10, COPE was implemented as a work profile inflated on top of a fully managed device. Because the EMM held device owner privileges, it had the same level of control as a fully managed deployment - including the ability to deploy applications to the parent (personal) profile.

In practice, this was limited. Some custom DPC EMMs - notably VMware Workspace ONE UEM - supported uploading APKs to the console for parent profile deployment. However, no EMMs supported pushing Google Play applications to both profiles simultaneously. It was a niche capability used primarily for deploying in-house apps or security tools (like MTD agents) to the personal side.

Google fundamentally redesigned COPE in Android 11. The device is no longer fully managed with a work profile on top. Instead, it uses an enhanced work profile model where the EMM is a profile owner, not a device owner. This was an explicit trade-off: more user privacy at the cost of IT control.

Deploying or force-installing applications to the parent profile is not possible on Android 11+, regardless of whether the EMM uses AMAPI or a custom DPC. The OS-level change applies to all management architectures.

Through personal usage policies, COPE deployments on Android 11+ can control which apps are available in the personal Play Store:

• Allowlist mode (personalPlayStoreMode: WHITELIST) - restricts the personal Play Store to only apps explicitly approved by the administrator. Everything else is blocked and automatically uninstalled if already present.
• Blocklist mode (personalPlayStoreMode: BLACKLIST) - allows full Play Store access, blocking only specific apps listed by the administrator.

These policies control availability, not installation. The organisation cannot force-install apps to the personal side or silently deploy managed configurations to personal apps, but they absolutely can dictate what is and isn't permitted on the personal profile. It is management - just not the same granular, per-app management available within the work profile.

Organisations that genuinely need to deploy and manage apps across the entire device should use a fully managed (work-only) deployment instead of COPE. This gives device owner-level control but removes the personal profile entirely. There is no middle ground on Android 11+ - it is either full control with no personal space, or a work profile with privacy boundaries.

For more on the COPE changes, see Android 11 COPE changes.

Android 11 fundamentally changed how COPE works. Prior to Android 11, COPE was implemented as a work profile on a fully managed device (WPoFMD) - the device was fully managed with corporate visibility and control, and a work profile was layered on top for app separation.

From Android 11, Google replaced this with work profiles on company-owned devices (WPoCOD). COPE devices are no longer fully managed at their core. Instead, they are essentially enhanced work profile devices with a flag marking them as company-owned, which unlocks a handful of additional device-wide policies that standard BYOD work profiles don't have.

This was a significant reduction in corporate control. Organisations lost visibility of personal apps, network logs, and usage statistics. Device-wide VPN, parent profile app management, APN configuration, and certificate management on the personal side all went away.

For the full breakdown of what changed, including migration paths for existing deployments: Android 11 COPE changes.

Since Android 11, the COPE model has remained architecturally the same - it is still a work profile on a company-owned device. Google has incrementally added back some capabilities in later releases:

• Android 12 introduced personal usage policies allowing organisations to control whether personal accounts, camera, and screen capture are available on the device. These are coarse controls compared to what WPoFMD offered, but better than nothing.
• Android 13 added the notification permission requirement, which impacts how work apps surface notifications after initial setup.
• Android 14 refined work profile behaviour and introduced cross-profile restrictions.
• Android 15 introduced Private Space, which is relevant for COPE as it creates another isolated area on the device that admins have no visibility of. Private Space can be disabled on company-owned devices via policy. Android 15 also changed re-enrolment behaviour: after a factory reset, COPE devices now require the Google account to be re-entered during setup rather than inheriting the previous session.
• Android 16 continues with the same COPE architecture. New capabilities include APN configuration via AMAPI, eSIM EID retrieval for provisioning workflows, and NFC controller management - all applicable to COPE as a company-owned deployment scenario.

If your organisation needs strong device-wide control and visibility, fully managed (COBO) remains the better choice. COPE is best suited to deployments where the organisation accepts limited personal-side visibility in exchange for offering employees genuine personal use on a company device.

By default, the work profile is isolated from the personal profile. Applications, data, and accounts in one profile cannot access those in the other. This is the foundational privacy and security guarantee of the work profile model.

However, administrators can selectively relax this boundary using cross-profile policies. The level of control depends on whether the device is personally-owned (BYOD) or company-owned (COPE).

What can be configured

• Copy and paste - administrators can allow or block clipboard sharing between profiles. By default on personally-owned devices, copy from work to personal is blocked, but personal to work is permitted
• Intent sharing - controls whether personal apps can resolve intents (share targets, links) from work apps, and vice versa. For example, opening a link from a work email in a personal browser
• Connected apps - specific apps can be enabled for cross-profile data sharing with themselves. For example, allowing the personal and work instances of Google Calendar to display events from both profiles in a single view. This requires administrator approval and the app must support it
• Contact searching - work contacts can be made visible to the personal profile for caller ID and search, so incoming calls from work contacts display correctly on the personal side
• Work profile widgets - apps from the work profile can be allowed to place widgets on the personal home screen. Disabled by default

BYOD vs COPE differences

On personally-owned work profiles, the default cross-profile restrictions are more permissive toward the user - for example, sharing from personal to work is allowed by default. On company-owned (COPE) devices, administrators have broader control and can lock down both directions.

Best practices

• Enable contact searching for usability - users expect caller ID to work regardless of profile
• Be cautious with connected apps, as they bridge the data boundary. Ensure any connected app is approved for handling corporate data
• Document the configured cross-profile policies for end users so they understand what is and is not shared

For more on work profile architecture, see What is an Android work profile?.

WearOS does not currently support Android Enterprise work profiles or managed accounts. There is no work profile equivalent on WearOS, and no mechanism to add managed accounts, install work apps, or sync work profile data to the watch.

Notifications - work profile notifications bridge to the watch by default. The WearOS companion app (Pixel Watch, Galaxy Wearable, etc.) uses NotificationListenerService to mirror phone notifications to the watch, and as a system app it can read cross-profile notifications. This works the same way as Android Auto's work profile notification support.

However, an organisation's MDM policy can restrict this using setPermittedCrossProfileNotificationListeners, and some EMMs block cross-profile notification listeners by default. If work notifications are not appearing on the watch, check with your IT team whether the watch companion app has been allowlisted.

WearOS has no concept of a work profile, managed account, or enterprise management. This means:

• Work accounts cannot be added to the watch - there is no managed Google Play or work account provisioning on WearOS
• Work apps cannot be installed on the watch - apps like Outlook, Teams, or Gmail on the watch cannot access work profile data
• Work calendar does not sync to the watch - calendar sync requires account-level access, not just notification bridging
• Work contacts are not available natively on the watch for caller ID or search

Some users configure their corporate account directly in the personal profile (outside the work profile) to enable watch sync, but this bypasses management policies applied within the work profile and is not recommended for organisations with data protection requirements.

Google has not announced WearOS support for work profiles. This is a known gap in the ecosystem and has been raised in the Android Enterprise Customer Community. Given the growing adoption of wearables in enterprise environments, it remains a commonly requested feature.

A major Android OS update (such as Android 15 to 16) delivered via OTA is not a factory reset - device management state, profiles, apps, and data all persist through the upgrade. There is no re-enrolment required.

• Device owner / profile owner registration - the DPC remains registered as device or profile owner after the reboot into the new OS version
• Work profile - the profile, its apps, and all work data remain intact
• Policies - enterprise policies continue to apply. The device syncs with the EMM on next check-in and re-applies the current policy set
• Managed configurations - app-level managed configs are retained and continue to be served by the RestrictionsManager
• App data - both personal and work app data persist, just as with any OTA update
• Zero-touch / KME registration - cloud enrolment registrations are unaffected by OTA updates, as these are server-side records

Major version updates can introduce behavioural changes that affect managed devices, even without a re-enrolment:

• Deprecated APIs and policy changes - each Android version may deprecate or change the behaviour of management APIs. For example, Android 11 fundamentally changed the COPE model, automatically migrating legacy COPE devices to the new work profile on company-owned device experience during the upgrade. See Android 11 COPE changes for details
• App compatibility - apps targeting older SDK versions may lose functionality or encounter permission changes under a newer OS. Android 14 introduced a minimum targetSdkVersion requirement for app installation, and Android 15/16 raised it further
• UI and behaviour changes - Android 15 introduced edge-to-edge enforcement for apps targeting API 35, and Android 16 extends this with large screen layout changes. Kiosk and dedicated device apps are particularly affected. See edge-to-edge FAQ
• OEM-specific bugs - major OS updates from OEMs occasionally introduce enterprise-related issues. Samsung devices have historically seen zero-touch enrolment failures and work profile issues following major updates
• Sticky configurations - in some Android versions, certain configurations have been observed to become permanently applied after a reboot, making them unchangeable without re-enrolment. This was notably documented on Android 14

• Use system update policies - device owners can set automatic, windowed, or postpone policies to control when OTA updates install. Postponement provides up to 30 days per update for testing. See managing system updates for more on what these policies control
• Use freeze periods - on Android 9+, freeze periods can suspend all system updates for up to 90 days, giving time to validate compatibility with business-critical apps. A 60-day gap between freeze periods is required
• Test with a pilot group - enrol test devices on the new OS version before allowing the update across the wider fleet. Most EMMs support phased rollout by device group
• Review version-specific changes - Google publishes enterprise-specific changes for each Android version at What's new for Android in the enterprise. Check for deprecations, new restrictions, and behavioural changes that may affect deployed policies or apps
• Monitor OEMConfig compatibility - OEMConfig apps may need updates to support new OS versions. Check with the device manufacturer for updated OEMConfig releases ahead of major OS rollouts

System update policies apply only to fully managed and dedicated devices. For work profile (BYOD) deployments, the device owner is the end user, and the organisation has no control over when OS updates are installed.

Microsoft has migrated its Intune personally-owned work profile implementation from a custom Device Policy Controller (the Company Portal app) to Google's Android Management API (AMAPI). This migration began in early 2026 and is now largely complete, with remaining devices being auto-migrated.

• The Company Portal app is being replaced by the Microsoft Intune app as the primary user-facing application for personally-owned work profile devices
• Web-based enrolment is being introduced, allowing users to begin enrolment from a URL rather than manually installing an app first
• Required apps cannot be uninstalled by users under the new implementation, aligning with how corporate-owned devices already behave

AMAPI is Google's modern management API and receives new features and platform capabilities before custom DPC integrations. By moving to AMAPI, Intune gains:

• Faster access to new Android Enterprise features
• Consistent behaviour across all four management modes (fully managed, dedicated, COPE, and BYOD work profile)
• Reduced maintenance burden of a custom DPC

Microsoft will automatically migrate remaining devices from the custom DPC implementation to AMAPI. Administrators should:

• Review their existing personally-owned work profile policies for compatibility
• Communicate the change to end users, as they will see the Microsoft Intune app replace Company Portal in their work profile
• Test the new enrolment flow in a pilot group before broad rollout

No. Intune's corporate-owned work profile (COPE), fully managed, and dedicated device management modes already use AMAPI. This migration only affects the personally-owned work profile scenario.

Sources:

• Microsoft Community Hub: New policy implementation and web enrollment for Android personally owned work profile
• Microsoft Learn: Android Enterprise work profile overview

System app behaviour on COPE devices changed fundamentally with Android 11. Understanding how it works across both eras is important for getting the personal profile experience right.

On Android 8-10, COPE was implemented as a work profile inflated on top of a fully managed device. The EMM held device owner privileges, meaning the entire device - personal side included - was under management.

During provisioning, the DPC extra android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED controls whether non-vital system apps are kept or disabled on the parent profile. This is supported through QR code, NFC, and zero-touch provisioning (but not DPC identifier).

My recommendation for COPE in this era was to set this to true - enable all system apps. The organisation is providing a device intended for personal use, so the closer to stock it feels, the more familiar the user will be with it. Gallery, calculator, health apps, camera, and other OEM app suites being present on the personal side should be harmless outside of the secure work profile.

If specific system apps need removing - bloatware, for instance - most EMMs support ad-hoc system app management post-provisioning. There is no reason to strip everything and selectively re-enable when the opposite approach is simpler and more user-friendly.

For more on how system apps are determined during provisioning, see what are vital apps?.

Google redesigned COPE in Android 11. The device is no longer fully managed with a work profile on top. Instead, it uses an enhanced work profile where the personal side is treated much like a consumer device. The EMM is a profile owner, not a device owner.

This means:

• The personal profile retains all OEM and system apps by default. There is no provisioning extra to strip or control them - the personal side provisions as it would on a consumer device.
• The EMM cannot install, uninstall, or manage apps on the personal profile in the way it could on Android 8-10. Parent profile app management was removed entirely.
• Personal app control is limited to Play Store availability through personal usage policies - allowlist or blocklist modes for Play Store apps. This does not affect pre-installed system apps.

In practice, this is the right outcome for most COPE deployments. Users get a personal profile that looks and feels like their own device, and the organisation controls what can be additionally installed from Google Play without dictating the core device experience.

For the full picture on what changed with COPE in Android 11, see Android 11 COPE changes.

Unless an enterprise policy prohibits device-wide application installation from unknown sources, yes.

Follow this FAQ.

No.

If you'd like to see this change, raise it in the Android Enterprise Customer Community, or through your existing EMM support channels as a feature request.

More information can be found here.

The Private Space is a separated, isolated profile on the Android device, similar to the work profile. If a VPN configuration is created on one profile (be that personal/parent, work, or Private Space), it won't apply for the applications running in another profile. To have Private Space apps running in a VPN, configure a VPN application within the Private Space.

Application management within the Private Space is limited to only company-owned work profile devices. Personally owned devices - or BYOD - cannot manage the Personal Space in any way. Fully managed devices do not support Private Space.

For company-owned work profile devices enrolled into AMAPI, the personal usage policies of personal Play Store mode and personal applications apply both to the parent (personal) profile, and the Private Space.

If your organisation already leverages policies to allow or block applications in the parent profile on a COPE device, these will carry over automatically to the Personal Space.

Note: It is not possible to set different personal Play Store modes, or configure separate allow/blocklist policies between the parent profile and the Personal Space.

No.

Applications and data stored within the Private Space are not visible to enterprise administrators, this follows the existing premise set with the parent profile in a work profile (company/personally-owned) deployment. If this is an organisational concern, application policies can be set for company-owned work profile deployments.

This may sound contradictory to Are Private Space applications truly hidden?, however this is because the EMM agent runs within the work profile, which is intentionally restricted from visibility of apps outside of it.

Applications within the Private Space may be detected through the use of ADB, or on-device package viewers. While application data is fully secure and isolated from visibility, the presence of the applications themselves cannot today be entirely hidden from view for anyone determined enough to go looking for them.

Note: From Android 16, on-device package managers can no longer detect applications outside of their own user. This reduces (but doesn't remove) the risk of application use being discovered.

EMMs leveraging the Android Management API (AMAPI) are subject to the default policy requirements Google sets. In February 2024 Google adjusted the default, unset behaviour for UsbDataAccess from ALLOW_USB_DATA_TRANSFER to DISALLOW_USB_DATA_TRANSFER. If your policies did not previously explicitly allow USB data transfer, this function will be blocked on your managed devices.

To reverse this, please set USB data transfer explicitly to allow, and redeploy your policies.

If you find networks with captive portals configured simply never launch the portal for authentication when a device is in a Kiosk environment, this is because it must be configured to do so.

Captive portals are typically handled through a dedicated application preloaded on all Android devices, and access can be granted by adding the respective package name to the EMM policy as an allowed application.

The common package name for this is:

com.google.android.captiveportallogin

android Tip For specific OEM implementations, search captive portal in the Android system apps database.

What this does is add the package name to the LockTask allowlist, enabling the app to open without triggering a security exception.

Yes. From February 2026, the Android Management API supports configuring Private DNS on company-owned devices running Android 10 and above.

The new privateDnsSettings policy field supports three modes:

• User choice - the end user can configure Private DNS in device settings (default behaviour)
• Automatic - the device uses the network's DNS-over-TLS server automatically when available
• Specified host - the administrator defines a specific Private DNS hostname, such as a corporate DNS resolver

This is available for fully managed devices and work profiles on company-owned devices. It does not apply to personally-owned work profile deployments.

Before this addition, administrators had no standardised way to enforce Private DNS configuration through AMAPI, and often relied on OEM-specific OEMConfig policies or VPN-based DNS solutions. This brings Private DNS management in line with what custom DPCs could already achieve through the platform DevicePolicyManager APIs.

No, not on a device that has already been set up with user accounts.

Setting a device as fully managed (Device Owner mode) is only possible during the initial device setup, before any accounts are added. This is by design - Android enforces this restriction to prevent a management agent from silently taking control of a device that a user has already configured.

There are limited exceptions:

• ADB command (dpm set-device-owner): This can set Device Owner on a device that has been set up but has no Google accounts or secondary users present. However, this is a development and testing tool, not a production deployment method. It also requires USB debugging to be enabled and is not practical at scale. It cannot be used with AMAPI.

• DPC migration: If a device is already managed by one DPC, it may be possible to migrate to another DPC or to AMAPI without a factory reset, depending on vendor support. See Can I migrate devices from a custom DPC to AMAPI? for details.

For production deployments, the supported methods all begin from a factory reset state: QR code, zero-touch, KME, NFC, DPC identifier, or managed Google account provisioning. See How can I provision a fully managed device? for the full list.

No. Picture-in-Picture (PiP) mode does not function when a device is in lock task (kiosk) mode.

When an application calls enterPictureInPictureMode() on a device with lock task active, the request is silently ignored. This is by design - lock task mode restricts the device to a controlled set of applications and prevents system UI elements that could allow users to navigate away from the kiosk experience.

Common enterprise use cases affected include:

• Video conferencing apps (Teams, Meet, Zoom) that rely on PiP to allow multitasking during calls
• Monitoring or streaming apps that need to overlay video while the primary kiosk app runs
• Navigation apps used alongside a primary field-service application

There is no official workaround within the standard lock task API. Some options organisations have explored:

• Multi-app kiosk - rather than a single-app kiosk, configure a multi-app kiosk that includes both the primary app and the video/overlay app, then handle the split-screen or overlay behaviour within the apps themselves
• OEM-specific APIs - some OEMs offer proprietary APIs that may support overlay behaviour in restricted modes. Check with your device manufacturer
• Custom launcher - a custom kiosk launcher application may be able to manage windowing behaviour outside of standard lock task constraints

This is an active area of community feedback. Google has not indicated whether PiP support in lock task mode is planned.

There are several options for provisioning into any fully managed deployment scenario (COBO, COPE, COSU):

• NFC (5.0+): With the use of a provisioning app provided by your EMM of choice on a spare device, simply input basic environment details and bump NFC radios with a freshly factory reset (or brand new out of box) device to begin provisioning.
• Managed Google account (6.0+): Begin setting up a device as normal (including connecting to a network) and at the Google account prompt, enter a managed Google account (Google Workspace, Google Cloud Identity) address and authenticate as normal.
• DPC identifier (6.0+): Begin setting up a device as normal (including connecting to a network), but at the prompt to enter a Google account opt instead to input the DPC identifier of your EMM. Plenty of examples are available here.
• QR code (7.0+): With a QR code provided by either the EMM solution or a counterpart provisioning app (the same potentially used to provision via NFC), simply tap 6 times on the welcome screen to launch the QR reader. Wi-Fi details are required unless provided within the QR payload.
• Zero-touch (8.0+): Devices purchased through an authorised reseller may be assigned to a zero-touch customer account, and with a configuration created and assigned, the device will automatically begin zero-touch provisioning as soon as network connectivity is established.
• KME (Knox 2.8+): Samsung devices running Knox 2.8 or above are compatible with Android Enterprise provisioning via KME. Devices added to the KME portal with a profile assigned will begin KME provisioning from a factory reset state.
• Other: Your device OEM may support other methods of provisioning. Reach out to them to request details.

More details:

• Did you know? Android Enterprise fully managed provisioning methods
• Android Enterprise provisioning guides

Lost Mode is an Android Enterprise management feature that allows administrators to remotely lock and locate a company-owned device that has been lost or stolen.

When activated by an administrator:

• The device is locked, preventing unauthorised access
• The device's location is reported to the admin console
• An audio alert can be played to help physically locate the device
• A message and contact number can optionally be displayed on the lock screen

Lost Mode is available on:

• Fully managed devices running Android 11 or later
• COPE devices (work profile on company-owned device) running Android 13 or later

It is an AMAPI-only feature. EMMs using a custom DPC do not have access to Lost Mode unless they have implemented their own equivalent.

Lost Mode can activate location reporting regardless of the device's existing location settings on fully managed devices. On COPE devices, location accuracy depends on the device's configuration and whether location services were enabled prior to activation.

Lost Mode is activated through your EMM console. The specific steps vary by vendor - check your EMM's documentation for instructions. The feature must be supported by your EMM's AMAPI implementation.

Sources:

• Android Enterprise Help: Lost mode
• Android Enterprise Help: What's new - Lost Mode

Not normally by default, though do validate with your EMM vendor. If confirmed disabled however FRP kicks in after a reset, log a ticket with EMM support.

If so desired, allowlisted Enterprise Factory Reset Protection is available and offers a simple, albeit caveated means of ensuring devices can’t simply be wiped and re-setup without Android Enterprise provisioning taking place. For zero-touch devices there’s no need to leverage it.

From Android 15, FRP behaviour has changed. OEM unlocking no longer bypasses FRP after a hard reset, and Enterprise FRP is always enforced on managed devices regardless of OEM unlock status. This makes configuring EFRP more important than before, particularly for fully managed devices without zero-touch, as recovery from an unexpected reset without EFRP configured is considerably harder.

More: Feature spotlight: Factory Reset Protection.

In most cases, no - not without a factory reset.

Android Enterprise fully managed devices are bound to a single EMM enterprise. Moving a device from one EMM to another typically requires a factory reset and re-provisioning under the new EMM, unless both the inbound and outbound EMM supports DPC migration via their custom DPCs.

More recently, DPC migration via the Android Management API (AMAPI) has become possible. This allows devices managed by a custom DPC (using the Play EMM API) to migrate to AMAPI (Android Device Policy) without a factory reset. However, this is a one-way migration from custom DPC to AMAPI within the same enterprise - it cannot be used to migrate between two different EMM platforms.

For organisations planning an EMM change, the practical approach is to phase the migration by factory resetting devices in batches and re-provisioning them under the new EMM. Zero-touch enrolment simplifies this significantly, as the device configuration can be updated in the zero-touch portal to point to the new EMM before the reset.

Factory Reset Protection (FRP) and Enterprise Factory Reset Protection (EFRP) serve similar anti-theft purposes but work differently.

Standard FRP is tied to the Google account signed into the device. If the device is factory reset (via recovery, not through Settings), the device will require the previously signed-in Google account credentials before it can be set up again. This is a consumer anti-theft feature present on all GMS-certified Android devices.

On fully managed devices, FRP typically activates - if enabled via policy - based on whichever Google account was present on the device - this could be the managed Google Play account provisioned by the EMM. If that account is deleted or no longer accessible (common after EMM unenrolment), recovering the device can be difficult.

Enterprise FRP is a policy-driven feature that allows administrators to specify one or more Google account email addresses that can unlock the device after a factory reset. This is configured through the EMM as part of the device policy.

Key differences:

• EFRP is administrator-controlled - the unlock accounts are set by policy, not tied to whichever account happened to be signed in
• EFRP is optional - administrators must actively configure it; it is not enabled by default on most EMM platforms

From Android 15, FRP behaviour has changed significantly:

• OEM unlocking no longer bypasses FRP. Previously, enabling OEM unlock in developer options would skip FRP after a hard reset. This is no longer the case
• Enterprise FRP is always enforced after a hard reset on managed devices running Android 15+, regardless of OEM unlock status

This makes configuring EFRP more important than ever for organisations managing fully managed devices, as recovery from an unexpected reset without EFRP configured becomes considerably harder.

For more detail, see Feature spotlight: Factory Reset Protection.

It depends on the management configuration.

On a fully managed device, Android Auto requires the following to function:

1. Android Auto (or the built-in car projection service) must not be blocked through app allowlisting/blocklisting policies
2. USB connections must be permitted if using a wired connection. Some EMM policies disable USB data access, which will prevent Android Auto from connecting
3. Bluetooth must be permitted if using wireless Android Auto

The most common cause of Android Auto not working on fully managed devices is an overly restrictive app policy. If the organisation uses an app allowlist (only approved apps can run), Android Auto and its required companion services must be explicitly included.

For COPE (work profile on company-owned) devices, Android Auto runs in the personal profile by default and is generally unaffected by work profile policies.

If Android Auto fails to connect, check the EMM console for USB, Bluetooth, or app restriction policies that may be interfering.

The content protection policy is an AMAPI feature available on Android 15+ that enables enhanced scanning of apps for deceptive or potentially harmful behaviour on the device.

When enabled, the device leverages Google Play Protect's on-device scanning capabilities to detect apps that may attempt social engineering tactics, such as impersonating system dialogs or overlaying content to trick users into providing credentials or granting permissions.

This is particularly relevant for organisations deploying devices to frontline or less technically experienced workers, where the risk of social engineering through deceptive apps is higher.

The content protection policy complements but does not replace standard Play Protect scanning. It is focused on real-time behavioural analysis of app UI patterns rather than static malware detection.

This policy applies to fully managed and dedicated devices. For work profile deployments, the work profile already benefits from Play Protect scanning within its scope.

Normally this would suggest either the respective Android Enterprise configurations aren’t assigned to the device, or there’s an issue with the binding between the EMM and Google.

Ensure the user of the device is in the correct Active Directory group (if relevant) or EMM group to receive the correct profiles, otherwise check the binding.

Occasionally and with some EMMs this may also happen if more than one device is enrolled with the same Device Identifier, e.g.: Serial Number or IMEI. Validate all Device Identifiers are unique (at least within an OEM/model) as it's not uncommon to see duplicates in the wild.

Other considerations:

• Invalid or expired enrolment token/code - Enrolment codes/tokens may have a configurable expiry. If the token used during provisioning has expired, the device may reset rather than enrol. Regenerate the token and try again
• Compliance policy mismatch - if the device fails a compliance check immediately upon enrolment (for example, the OS version is below the minimum required by policy), some EMM configurations will trigger an immediate wipe rather than placing the device into a non-compliant state
• Sign-in URL misconfiguration - an incorrectly configured sign-in URL can cause the provisioning flow to fail after the initial setup steps, resulting in a reset
• Missing policy - As described above, if a device is missing a policy - particularly in AMAPI - it will wipe after a period of time.

No. On a fully managed device, both an enterprise wipe/retire and a full wipe result in a factory reset. The entire device is under management with no separation between corporate and personal data, so there is nothing to selectively remove.

Android Enterprise requires a DPC actively enrolled as Device Owner to provide management policies. Removing the DPC means removing everything, and the device resets to factory settings.

The behaviour is different for other deployment scenarios:

• Work profile (BYOD): Removing management deletes only the work profile. Personal apps, data, and accounts are completely unaffected. This is the closest Android Enterprise gets to a true selective wipe.
• COPE (Android 11+): The EMM can remove just the work profile (preserving personal data), issue a full factory reset, or - with AMAPI - use the RELINQUISH_OWNERSHIP command to convert the device to an unmanaged personal device.
• COPE (Android 8-10): The older architecture treated COPE as a fully managed device with a work profile on top. Removing management factory resets the device, same as fully managed.

Not through the device UI, no. On a fully managed device, end users are always blocked from adding or removing OS-level users regardless of policy configuration.

Whether the EMM can do it programmatically depends on the management architecture in use.

AMAPI does not support secondary user management at all. While the policy schema includes addUserDisabled and removeUserDisabled fields, the documentation explicitly states that for devices where managementMode is DEVICE_OWNER, the user is never allowed to add or remove users. There is no API for the EMM to create, remove, or switch between OS-level users either.

A custom DPC operating as Device Owner has significantly more capability here. Android's DevicePolicyManager exposes several user management APIs:

• createAndManageUser() - create secondary users programmatically (Android 7.0+)
• removeUser() - remove secondary users (Android 5.0+)
• switchUser() - switch the active user on the device (Android 7.0+)
• startUserInBackground() / stopUser() - manage user sessions without switching (Android 9.0+)

This is one of the remaining capability gaps between AMAPI and custom DPC. If your organisation relies on multi-user device scenarios, check whether your EMM exposes these APIs.

A common use case for secondary users is shared devices - kiosks, shift terminals, or front-of-house equipment. Custom DPCs can create ephemeral users (using the MAKE_USER_EPHEMERAL flag on createAndManageUser()), where all user data and apps are automatically deleted when the user session ends, the device switches users, or the device reboots. This requires Android 9.0+ and is documented in detail in Google's dedicated devices guide.