Android Enterprise FAQ

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

The account type chosen can have a significant impact on enrolment if not done so correctly.

User based accounts are tied to an EMM user and will be used across all devices enrolled by said user.

Device based accounts are created per-device irrespective of the user the device enrols under.

In either scenario, that standard limitation of 10 devices per Google account applies, therefore if using one EMM user account to enrol many devices – a common staging exercise – it is imperative device based accounts are selected.

How these account types are changed is EMM specific, so do reach out to your EMM vendor for instructions.

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, the minimum OS required for what the organisation wants to do, for example setting a passcode on a work profile (a challenge) requires Android 7.0, ensuring that passcode cannot be the same as the device passcode requires 9.0. More of these comparisons are made in considerations when migrating from device administrator to Android Enterprise.

Once determined, the best place to start looking is the Android Enterprise Recommended list. If nothing suits requirements, get in touch and I’ll try to help out!

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.

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.

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.

Yes.

Since Android 5.x (Lollipop), like all other OEMs, it has been possible to deploy for free a work profile or provision a fully managed device using Samsung devices and a preferred EMM solution. From Android 8.0 and Knox 3.0, Samsung further integrated AE by having the Knox Workspace container use the Android Enterprise Profile Owner APIs to inflate the Workspace, and as of late 2020 also began supporting zero-touch in addition to their existing KME service. Customers can optionally select to activate a Knox Platform for Enterprise licence to enable premium features on the device, including all of the APIs from the previously separate Knox Standard, Knox Custom and Knox Premium SDKs.

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.

Android 16 introduces several enterprise-relevant features and policy enhancements:

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

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

Android Enterprise support is coming to Android XR devices, though availability is currently limited.

The Samsung Galaxy XR, the first major Android XR headset, launched in late 2025 built on the Android XR platform. At launch, Android Enterprise device management features were not available. Google has confirmed these will be activated through a future software update.

Samsung Knox management is available for the Galaxy XR, meaning some enterprise management capabilities (remote setup, encryption, monitoring) can be used through Knox-compatible EMMs. Full Android Enterprise API support - including work profiles, managed Google Play, and AMAPI policy enforcement - is pending.

Other manufacturers including Lenovo are developing Android XR devices for enterprise use. These are expected to support Android Enterprise management once the platform features are activated.

If your organisation is evaluating XR headsets for enterprise deployment:

• Confirm Android Enterprise support status with the vendor before purchasing at scale
• Knox management may bridge the gap for Samsung XR devices until full Android Enterprise support arrives
• Expect the management experience to be broadly similar to phones and tablets once Android Enterprise is enabled, though XR-specific policies may develop over time

Sources:

• Android Enterprise coming to Android XR - Android Enterprise Customer Community
• Samsung Business Insights: How enterprises are using XR headsets

Note: The Android One programme appears to be no longer active. Google has not announced new Android One devices since approximately 2022, and the programme is no longer marketed or accepting new validations. The information below is retained for historical context.

Android One and Android Enterprise Recommended were two different programmes offering a bit of overlap in security and consistency.

Android Enterprise Recommended ensures devices validated meet the minimum requirements and recommendations of a consistent UX for management, 90 day security updates for 3 years and at least one letter upgrade (O to P, P to Q.. ). OEMs maintain their value-adds, bundled apps, custom UIs and more.

Android One took this a step further; any device in the Android One programme used a system image developed with Google. Like the Nexus days of old, the UI was vanilla Android and the Android One team had to approve any additional applications bundled with the device.

Updates had to be released every 30 days and the devices had to support two letter upgrades (O to Q, P to R, etc).

When combined with AER, Android One offered additional benefits validated to work in the enterprise.

For current device procurement decisions, Android Enterprise Recommended is the relevant programme to evaluate.

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.

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 works with fully managed, dedicated, and personally-owned work profile devices. It does not apply to the COPE (work profile on company-owned device) management mode. If KSP policies are applied to a fully managed device and the device is later switched to COPE, previously applied KSP policies may persist unexpectedly.

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?.

Sources:

• Samsung Knox Documentation: Knox Service Plugin managed configurations
• Samsung Knox: Knox Platform and Android Enterprise
• Android Enterprise Customer Community: OEM Config Policy with Samsung Knox Service Plugin

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

AER is Google’s validation programme for devices, EMMs, Carriers and MSPs. It sets a baseline of enterprise requirements that participating vendors must meet and maintain.

Each category has its own list of requirements:

• Devices - must meet minimum hardware specifications, deliver security patches within 90 days, support at least one OS letter upgrade, and pass Android Enterprise management compatibility testing. The programme includes standard, rugged, and dedicated device categories
• EMMs - must support a defined set of Android Enterprise management features across all deployment scenarios
• Carriers and 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?

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.

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.

Sources:

• Google blog: Simplify Android Enterprise with managed Google domains
• Android Enterprise Help: Upgrade to managed Google domain
• Android Enterprise Customer Community: 2026 Planning Roadmap
• Managed Google domains: what, why, and how to upgrade

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.

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.

There have been isolated instances where during enrolment the DPC could collect a list of personal applications installed before migrating into the work profile, however by the time enrolment completes this will have been rectified to display only the applications in the work profile.

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

Android 8-10 – My normal advice, where supported through DPC extras (so NFC, QR, zero-touch, but not DPC identifier), is to enable system applications on COPE devices.

Organisations are providing a device provisioned for personal use, and as such the closer to stock it feels, the more familiar users will be with using it.

Most EMMs support the ad-hoc management of system applications, so there’s no reason bloatware can’t still be disabled, but things like system gallery, calculator, health apps and other OEM app suites being enabled should be harmless outside of the secure work profile.

Android 11+ – While there is still application management to a degree, the act of enabling or disabling system applications during provisioning is no longer supported.

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.

Android 8-10 – Yes, for work profiles on fully managed devices, however this would need to be supported by the EMM. VMware Workspace One UEM could do this for example by uploading an APK to the console, though there are no current examples of EMMs being able to push Google Play applications to both profiles.

Android 11+ – No, this is not supported for work profiles on company owned devices.

Note: Through personal usage policies on COPE devices it's possible to make apps available within the work profile, however these will not be installed.

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.

Yes, however this requires EMM support. I am not aware of any EMM that supports this today, despite its incredible value particularly to early Android Enterprise adopters.

Where the EMM does not support this, or the device runs Android 11, the organisation would need to retire and reprovision the device.

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.

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.

Microsoft is migrating 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 change began rolling out in early 2026.

• 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

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?

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.

No, both an enterprise wipe/retire/delete from the EMM and a full wipe on a fully managed device do the same thing, they reset the device back to factory settings.

Android Enterprise requires a DPC actively enrolled to provide management policies, without this, the device will reset.

Wherever possible, zero-touch offers the best experience both for organisations and users. For organisations, it provides not only the decreased overhead of not having to explain how to manually start provisioning a device (and the support required when users still don’t get it), but also the confidence of knowing should a device be factory reset accidentally or with intent, the device will jump back into zero-touch provisioning as soon as it’s connected to a network. This extends to Samsung’s KME equally for the same reasons. That doesn’t mean zero-touch is the fastest and most efficient provisioning method, in fact it’s probably comparable in speed to DPC identifier, however speed is but one consideration.

If zero-touch isn’t available, my personal preference is QR code provisioning as QR codes are persistent (normally), can be hosted anywhere or freely shared between employees, don’t need a dedicated provisioning device, and support DPC extras.

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.

No, fully managed devices do not allow end-users to add or remove device users (per AMAPI).

No.

The backup service offered by Android is disabled on fully managed devices. As a best practise, the organisation should offer end-users a cloud service - One Drive, Google Drive, Dropbox, etc - to which company data is automatically synced.

Yes, however EMM support on both EMM solutions is required, and I’m not aware of any today who support this except for the Android Management API (and this is only for Play EMM API to AMAPI migrations).

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.

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.

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.

More: Feature spotlight: Factory Reset Protection.

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

A reseller has the ability to upload any devices through their reseller portal, however it is their obligation to ensure that the device identifiers (IMEI or serial) are correct and that the organisation in question owns the devices, not another organisation or an employee. If the organisation does own these devices, can prove this, and can supply accurate device identifiers, please discuss this with a preferred reseller for assistance. It is up to the reseller if they wish to upload devices already purchased since there are consequences for resellers who upload incorrect data to the zero-touch portal.

This will change in future.

As of late 2020, all Android Go devices support zero-touch through expanded zero-touch availability. Prior to this, Android Go supported zero-touch on an opt-in basis. Validate support ahead of bulk purchase.

No.

While zero-touch is mandatory for Android Enterprise Recommended, devices that don’t meet Google’s requirements for storage or spec can and still do support provisioning via zero-touch.

Yes, via the CSV template provided, or the customer API

Yes, either by requesting a new account from a new reseller, or adding a new reseller through the existing console.

Nothing until the device is reset, at which point the new config will apply.

No, it is a free service, from Google at least. Reseller partners can choose to charge for this service, or bundle it as part of other offerings if they choose to do so.

Should you be unhappy with a reseller charging for the service, have a look for another reseller who does not.

No, zero-touch is for corporate-owned devices only.

No, please use an EMM solution for day-to-day device management.

Nothing until the device is reset, at which point it will not be prompted to enrol into management.

It will be forced to enrol back into management automatically following the data erase, unless a config has not been applied, or has since been removed.

As of late 2020 yes!

As zero-touch is a little light on features, Knox Mobile Enrolment has full support for Android Enterprise and a little more control over the how and when for device provisioning, so organisations may still opt not to use zero-touch on a Samsung device.

Through supported EMMs and the minimum Knox version (2.9), organisations can use either KME or zero-touch (9.0+) to deploy an Android Enterprise fully managed, dedicated, or COPE device, or work profile via KME only.

Yes, however this only affects new devices added and not those already on the console. For existing devices, leverage either CSV or API to make bulk changes.

The config won’t apply until after the device is reset. Anything after the “checking for updates” prompt is too late.

These are a selection of DPC-specific key-pairs which manipulate the enrolment experience. An example may be pre-populating the EMM server, or enabling system applications. They vary between EMMs so do validate before attempting to use one.

Nothing until after the device is reset. Zero-touch configurations only download during the setup wizard, and not after. This is also why once a device has been partially set up, it needs to be factory reset in order to pull down the zero-touch config once more.

As of late 2020, all GMS certified Android 9.0+ devices from all OEMs support zero-touch.

OEMs supporting zero-touch on 8.0/8.1 include:

• Sony
• Huawei
• HMD Global
• Google
• LG
• Motorola
• Sharp

Along with the change to globally support all Android 9.0+ GMS certified devices with the integration of zero-touch into GMS Core (Google Play Services), the previous Google-maintained list of zero-touch supported devices, including those running older Android versions, is no longer live.

A collection of DPC extras for various EMM/UEM vendors can be found here: Android Enterprise zero-touch DPC extras collection.

As EMM vendors begin supporting the zero-touch iFrame introduced in late 2020, manual editing of DPC extras should diminish as EMMs will handle it automatically.

Zero-touch resellers can be found globally. The complete list of resellers can be found here.

No, only authorised resellers. Customers are not able to add devices to the zero-touch portal at this time.

This will change in future.

Only console admins or owners from the customer portal, or the reseller. End-users cannot remove their device from zero-touch enrolment.

No, it does this extremely quickly.

The term “zero-touch” is aimed at admins and IT teams that no longer need to manually touch each device in order to undertake managed provisioning. This is in context of IT teams often pre-staging devices before shipping them to end users to avoid non-enrolment, which is no longer needed when devices are zero-touch registered.

It does not apply to the act of end-users running through the provisioning process, which has admittedly required more and more taps over the last few major Android versions due in part to the often unnecessary interruptions of unskippable privacy prompts.

The upload may complete successfully, but the device will not initiate the zero-touch enrolment flow once connected to a network. The device will need to be deregistered and re-registered with the correct manufacturer.

From 2020, the manufacturer field is no longer required for IMEI-based uploads and can be omitted, but it should still be used for Wi-Fi-only devices.

Yes.

Zero-touch is just a provisioning method which deploys an EMM agent to your device over the air (OTA), to enrol into a Fully Managed Device profile using Android Enterprise (not legacy Device Admin) APIs. Google do not provide a free EMM solution, though device management is available through Google Workspace (G Suite) with the appropriate licences.

This action results in the device being irreversibly removed from zero-touch management. Please contact the device reseller to add it back in. The IMEI or serial (Wi-Fi only devices) will be required.

Any currently-enrolled devices will not be impacted until they are factory reset.

This could be a few things:

• Check the manufacturer name is correct, the example CSV file downloaded from the portal lists Google as the manufacturer, and resellers may not have changed it.
• Confirm the IMEIs are correct.
• Confirm a configuration is present and assigned to the device.
• Is the device being setup on Wi-Fi? Try cellular to rule out restricted networks.
• Is the device connected to a network at all? Check and connect if required.
• Is the device running 8.0+? With the exception of Pixel, no device running less than Oreo will support ZT.
• Does the OEM support ZT on the device? Unless Android Enterprise Recommended, zero-touch is optional and may therefore not be supported even on 8.0+ devices.

There are reports from the Android Enterprise Customer Community and other forums of devices running Android 15 and later failing to trigger zero-touch or KME enrolment following a factory reset, instead defaulting to the personal setup wizard.

This behaviour appears to be related to timing changes in Android 15's setup flow. In some cases, the device completes the initial setup screens before the zero-touch or KME configuration is fetched and applied, resulting in the device landing on the home screen as an unmanaged personal device.

Network connectivity timing - the device needs an active internet connection very early in the setup flow for zero-touch or KME to activate. If the device connects to Wi-Fi after certain setup screens have already been passed, the provisioning trigger may be missed. Ensure devices have network access as early as possible during setup, ideally via a known Wi-Fi network or mobile data.

Profile assignment after reset - if the device's IMEI or serial number was recently re-assigned in the zero-touch or KME portal, there can be a propagation delay. Verify that the correct configuration or profile is assigned and has had time to propagate before resetting the device.

Dual-SIM devices - on dual-SIM devices, the reseller should register the primary (first) IMEI. Registering the secondary IMEI can cause zero-touch to fail silently. Alternatively, register by serial number.

Samsung-specific considerations - configuring both zero-touch and KME on the same Samsung device is not recommended, as the two enrolment methods can conflict. Choose one and remove the other from the respective portal.

GMS Core version - devices with significantly outdated GMS Core versions may not process zero-touch enrolment correctly. This is more common on devices that have been in storage for an extended period. If the device can access the Play Store briefly before reset, allow GMS Core to update first.

1. Confirm the device IMEI or serial number is correctly registered in the zero-touch console or KME portal
2. Check that a valid configuration or profile is assigned (not just registered)
3. Factory reset the device again, ensuring Wi-Fi is connected at the earliest possible stage
4. If using a SIM, ensure mobile data is available before Wi-Fi is configured
5. Check for known issues in Google's zero-touch documentation

If the issue persists across multiple devices of the same model, it may be an OEM-specific bug. Raise it with the OEM and consider logging it in the Android Enterprise Customer Community.

Zero-touch supports provisioning into any corporate-owned deployment scenario:

• Fully managed (COBO) - the device is entirely under corporate control with no personal profile
• Dedicated (COSU) - a fully managed device locked to a specific app or set of apps (kiosk mode). The device provisions as fully managed, and the policy determines that it operates as a dedicated device
• COPE - a corporate-owned device with a work profile for work/personal separation. Prior to Android 11 this was implemented as a work profile on a fully managed device (WPoFMD). From Android 11, it is a work profile on a company-owned device (WPoCOD) with enhanced privacy for the personal side

The deployment scenario is not set in the zero-touch portal itself. It is determined by the EMM configuration assigned to the device.

For AMAPI-based EMMs, the enrolment token includes an allowPersonalUsage setting:

• PERSONAL_USAGE_ALLOWED provisions a COPE device (work profile on company-owned device)
• PERSONAL_USAGE_DISALLOWED provisions a fully managed device
• PERSONAL_USAGE_DISALLOWED_USERLESS provisions a fully managed device without a user sign-in step (commonly used for dedicated/kiosk devices)

For custom DPC EMMs, the DPC extras payload provided in the zero-touch configuration determines the deployment scenario. The specific extras vary by vendor - check your EMM's documentation for the correct values.

In all cases, the zero-touch portal simply pulls the assigned configuration for the device during setup. The EMM handles the rest during provisioning and enrolment.

Zero-touch is for corporate-owned devices only. It requires devices to be purchased through an authorised zero-touch reseller and registered to a zero-touch customer account. Employee-owned devices are not eligible for zero-touch enrolment.

For more on zero-touch, see What is Android zero-touch enrolment?.

No.

App shortcuts supported with device admin are not available for Android Enterprise. Instead, it’s possible to deploy shortcuts for Android Enterprise devices as web applications through the Google Play iFrame.

Instead of a bookmark/shortcut that opens in the default browser, web apps are legitimate applications that open with Google Chrome.

More information: Create and manage web apps for Android Enterprise

When deploying the iFrame, a UEM vendor decides what they wish to support. On that basis, the iFrame may lack private app upload, web app creation or bundle support.

It’s possible for a UEM to implement multiple iFrames with these features separated out, so is worth checking this functionality isn’t placed elsewhere on the console.

Should additional features not be available anywhere, please get in touch with your UEM provider to discuss this.

Yes this is possible, however not concurrently. Android supports only profile-wide VPN (or always-on VPN) natively, and the per-app VPN functionality often alluded to when multiple VPNs are brought up would have to be supported in-app.

When one VPN is running profile-wide and another is initiated, it will disconnect the first. Should these VPNs have failure protection and automatic reconnect (or leverage always-on VPN for this) the two VPN solutions will repeatedly disconnect one another.

To permit or block a selection of URLs in Chrome managed config, you need to add the URLs to the relevant list. The format for this is as follows:

[scheme://][.]host[:port][/path][@query]

Setting multiple URLs in succession would look like this:

["http://www.example.com", "https://www.example.com", "http://*", "https://example.com?sda"]

More format examples can be found here, but in a nutshell:

• * targets everything. This is useful for preventing access to everything via a blocklist, then explicitly allowlisting certain domains or URLs
• 192.0.2.1 targets this specific IP
• .domain.com explicitly blocks the root domain, but not its subdomains
• domain.com blocks everything in that domain

It's important to note that some EMMs require brackets for this to work properly, which is why I used them in the multiple URLs example. Google's documentation doesn't mention this, but it's a crucial step.

Yes, it is possible to manually install an APK to the work profile or any other user present on the Android device via ADB.

First, locate the user ID of the profile or user you wish to target:

adb shell pm list users

This will output a user list of all users on the device, for example:

UserInfo{0:Jason:4c13} running
UserInfo{10:Work Profile:1030} running
UserInfo{11:Private space:1090}

Besides the primary user, which is always userID 0, the above example also shows a Work Profile and a Private space (Private Space is Android 15+)

With the appropriate userID identified, install an APK as follows:

adb install --user 10 /path/to/yourfile.apk

Your application should install, and appear shortly within the appropriate profile.

For fully managed devices, a single configured VPN policy will create a global VPN connection that can route all device traffic by default.

For devices with multiple profiles, be that a work profile or Private Space, a VPN configuration applies only to the profile it is deployed within.

Yes, as long as the work profile device is company owned. Personally-owned work profile devices offer no personal app management.

For company owned devices, personal usage policies allow organisations to:

1. Set the personal Play Store mode to allowlist, preventing access to the full app store and limiting available applications to only those configured by the administrator.
2. Set the personal Play Store mode to blocklist, allowing full access to Google Play other than applications explicitly blocked by the administrator.

In both cases, applications not permitted to be on the personal profile will be automatically removed.

These policies do not provide any access or visibility to the applications or data within the parent profile. Personal privacy is maintained, but it allows organisations to ensure company owned devices do not run applications unsuitable for an enterprise environment.

If you're looking to configure the bookmarks available in managed Chrome, you can use the below format. More examples can be found via Google's documentation.

[
  {
    "toplevel_name": "Company bookmarks"
  },
  {
    "name": "Homepage",
    "url": "mydomain.com"
  },
  {
    "children": [
      {
        "name": "HR",
        "url": "mydomain.com/hr"
      },
      {
        "name": "Submit a ticket",
        "url": "mydomain.com/it-support"
      }
    ],
    "name": "Internal URLs"
  },
  {
    "name": "Android resources",
    "url": "bayton.org/android"
  }
]

Be aware on managed Android devices, bookmarks can't be placed on the home screen. For that use case, you should consider web apps instead.

Other things to consider -

• The order you input the subfolders and URLs reflects directly in Chrome
• If you input a child folder (e.g.: "children"), ensure you list the name (e.g.: "name":"Internal URLs")
• All normal json rules apply. You can use a json validator to be sure it's valid before committing it
• If Chrome doesn't show the bookmarks, though other configs (eg homepage) change, the syntax is invalid

For all EMMs that support it, the Google Play iFrame supports the simple, few-step process of uploading an APK for distribution to your Enterprise.

Unlike adding an APK directly into the UEM console, uploading to Google Play is safer, easier to manage and less likely to lead to issues compared with pushing APKs directly. Benefits include:

• Google's extensive Play infrastructure allows faster, lower-bandwidth installations
• Basic validation for feature support avoids repetitive installation failures for unsupported devices
• Smaller installation files (AAB)
• Delta updates, where supported (AAB)
• Native installation vs that of the DPC or a companion app

More information: Create and manage private apps for Android Enterprise

Where the Play iFrame isn’t supported, it’s possible to upload and distribute through the Google Play Console but keep in mind there’s a $25 fee to set up a developer account.

Note: Google Play will only permit one package name (com.app.name) for an application across the whole Google Play estate, meaning if you wish to upload an app privately today, and make it available publicly later, you must use unique package names for each upload.

By default, the managed Google Play iFrame will automatically organise and display assigned applications in the Google Play app on mobile devices.

While this is simple, it lacks control.

For organisations interested in customising the Google Play experience for managed devices, Google offers app collections. App collections allow defining an explicit layout, such as below, with the applications curated by the organisation.

While it's great, it can also become a burden. Applications assigned won't automatically pop up in Google Play after app collections are created, for example, and keeping this up to date is a reason organisations try it out, and subsequently abandon the idea.

Unfortunately the managed Google Play iFrame doesn't support just turning it off. Instead, a support request will likely need to be raised with the EMM vendor.

• If the EMM vendor uses the older Play EMM API with a custom DPC, they can leverage a simple API command: setStoreLayout. This can either be supported in-console, or as an action the support team can perform.

• If, however, the EMM vendor uses AMAPI, they will have to reach out to Google to turn the feature off as AMAPI hasn't yet adopted the API to attain feature parity.

Once disabled, the Play Store on devices will return to standard behaviour.

Google Play Protect now enforces an allowlist of approved Device Policy Controllers (DPCs) during provisioning. If your DPC isn’t on the list, Play Protect can flag it as “Harmful app blocked” even when it’s legitimate.

Before you appeal:

• Align to the Play Protect unwanted software and warning dev guidance: be transparent, avoid silent installs, and justify sensitive permissions (SMS, notifications, accessibility, overlays).
• Make sure your use case fits Google’s permissible usage for enterprise management. If you don’t need a sensitive permission, remove it while you apply.

Then submit an appeal using Google’s DPC allowlist form (linked from the Play Protect warning/help article). Explain the business use case, the permissions you request, and how users are informed. While waiting, advise users/admins that the warning is about allowlisting, not malware, and that the “continue” option may appear if permitted in your flow.

Read more on this can be read in the full article: The DPC allowlist.

Yes. The Android Management API now supports managing default application settings on managed devices.

Administrators can configure a prioritised list of apps for each default app type (such as browser, phone dialler, SMS, and others). The system evaluates the list in order and sets the first installed and qualified app as the default. If no app from the list is available, the existing default is retained.

Optionally, administrators can also prevent end users from changing the default app selection, ensuring the organisation's preferred apps remain in use.

This is particularly useful for:

• Enforcing a corporate browser as the default across a managed fleet
• Ensuring a specific phone or messaging app is always the default on dedicated devices
• Preventing users from switching to unsanctioned alternatives for key app categories

Prior to this feature, default app management through AMAPI required workarounds such as OEMConfig policies or was not possible at all, leaving it to end-user choice.

Yes. As of 2025, the Android Management API supports direct APK installation to managed devices.

Historically, all application deployment through AMAPI required apps to be distributed via managed Google Play. This meant every app - including internal line-of-business apps - needed to be uploaded to managed Google Play as a private app before it could be deployed.

With direct APK support, EMMs built on AMAPI can now push APK files directly to devices. This is particularly useful for:

• Internal apps that don't need to go through managed Google Play
• Apps that can't be published to Play for compliance or technical reasons
• Testing and development workflows where the overhead of Play publishing is unnecessary
• Situations where managed Google Play is unavailable or restricted

This does not replace managed Google Play as the primary distribution mechanism. Managed Google Play remains the recommended approach for most app deployment, as it handles versioning, updates, and licensing automatically. Direct APK installation is an additional option for scenarios where Play distribution is impractical.

For details on how this works, see AMAPI finally supports direct APK installation.

This is one of the most common managed Google Play issues reported by administrators.

The most likely cause is that your managed Google Play store is configured in Custom layout mode (also known as collections mode). When this mode is active, approved apps will not appear in the Play Store on managed devices until they are explicitly added to a collection.

Custom layout mode is typically enabled when an administrator edits collections within the managed Google Play iFrame in their EMM console. Once enabled, the store switches from showing all approved apps to showing only apps that have been placed in collections.

To resolve:

1. Open the managed Google Play iFrame in your EMM console
2. Navigate to the store layout or collections section
3. Add the missing app to an appropriate collection
4. Save and allow time for the change to propagate to devices

If you want all approved apps to be visible without collections:

• Some EMMs allow you to switch the store layout back from Custom to Basic mode, which shows all approved apps without requiring collections. The process for this varies by EMM.

Other possible causes:

• The app approval hasn't fully propagated yet. Allow up to an hour for newly approved apps to appear.
• The app is region-restricted and unavailable in the device's location.
• The app is assigned to a different policy or device group than the affected devices.
• For private apps, the app may still be in review or processing after upload.

No.

I’d recommend taking a look at Hypergate.

There is a project which was initiated (but not wholly supported) by Google to bring Kerberos support to Android through an application. Take a look at the respective GitHub repo to learn more, though note the project has seen no activity since 2019 and should be considered abandoned.

Related: Setup Kerberos Authentication on Ivanti EPMM (formerly MobileIron Core) for Android Enterprise

This is a known limitation of the Android Management API.

When deploying apps via closed testing tracks (also known as app tracks) through managed Google Play, the managed configuration schema (managed properties) is only pulled from the production version of the app. If the app has never been published to production, or if the production version has a different configuration schema than the track version, the EMM will either show no managed config options or show outdated ones.

This affects organisations that:

• Distribute internal apps exclusively through closed tracks without ever publishing to production
• Test new managed config options in a track version before promoting to production
• Use app tracks for staged rollouts where the track version has configuration changes not yet in production

Workaround: Publish the app to production with the correct managed configuration schema, even if the production version is not the one actively deployed to devices. The production listing controls what managed config options are available in the EMM console, regardless of which track version is installed on devices.

For more detail on this limitation, see Managed configurations and app tracks.

Yes. As of September 2024, Google Play Protect no longer sends sideloaded applications for cloud scanning on enterprise-managed devices.

Previously, when an app was installed outside of Google Play or managed Google Play (including apps pushed by an EMM's own installer), Play Protect would prompt the user to send the app to Google for scanning. This was an additional layer of protection beyond on-device detection.

Google removed this behaviour on managed devices in response to enterprise feedback. Organisations raised concerns about private, internally developed applications being uploaded to Google's servers for analysis - a data handling concern for security-conscious environments.

Partially. On-device Play Protect detection continues to function. Known malicious applications will still be flagged and may be removed regardless of how they were installed. What has changed is that unknown apps (those not in Google's database) are no longer sent for cloud-based analysis on managed devices.

For most enterprise deployments where apps are distributed through managed Google Play or a trusted internal pipeline, this change has minimal practical impact. Organisations that rely heavily on sideloaded apps from less controlled sources should consider additional endpoint security measures.

No. On personal (unmanaged) devices, Play Protect continues to offer the cloud scanning prompt for sideloaded apps as before.

Sources:

• Google Play Protect no longer sends sideloaded applications for scanning on enterprise-managed devices - bayton.org
• Google Play Protect - Android Enterprise Help