This page lists the complete set of Android Enterprise features.
If you intend to manage more than 500 devices, your EMM solution must support all the standard features (Enterprise Solutions Directory as offering a Standard Management Set.
) of at least one solution set before it can be made commercially available. EMM solutions that pass standard feature verification are listed in Android'sAn extra set of advanced features is available for each solution set. These features are denoted in each solution set page: work profile on personally-owned device , work profile on company-owned device, fully managed device, and dedicated device. EMM solutions that pass advanced feature verification are listed in Android's Enterprise Solutions Directory as offering an Advanced Management Set.
Key
standard feature | advanced feature | optional feature | not applicable |
1. Device provisioning
1.1. DPC-first work profile provisioning
You can provision a work profile after downloading the EMM's DPC from Google Play.
1.1.1. The EMM's DPC must be publicly available on Google Play so users can install the DPC on the personal side of the device.
1.1.2. Once installed, the DPC must guide the user through the process of provisioning a work profile.
1.1.3. After provisioning is complete, no management presence can remain on the personal side of the device.
- Any policies put in place during provisioning must be removed.
- App privileges must be revoked.
- The EMM's DPC must be, at minimum, turned off on the personal side of the device.
1.2. DPC-identifier device provisioning
IT admins can provision a fully managed or dedicated device using a DPC identifier ("afw#"), according to the implementation guidelines defined in the Play EMM API developer documentation.
1.2.1. The EMM's DPC must be publicly available on Google Play. The DPC must be installable from the device setup wizard by entering a DPC-specific identifier.
1.2.2. Once installed, the EMM's DPC must guide the user through the process of provisioning a fully managed or dedicated device.
1.3. NFC device provisioning
NFC tags can be used by IT admins to provision new or factory-reset devices according to the implementation guidelines defined in the Play EMM API developer documentation.
1.3.1. EMMs must use NFC Forum Type 2 Tags with at least 888 bytes of memory. Provisioning must use provisioning extras to pass non-sensitive registration details such as server IDs and enrollment IDs to a device. Registration details shouldn't include sensitive information, such as passwords or certificates.
1.3.2. After the EMM's DPC sets itself as the device owner, the DPC must open immediately and lock itself to the screen until the device is fully provisioned. 1.3.3. We recommend the use of NFC tags for Android 10 onwards due to the deprecation of NFC Beam (also known as NFC Bump).
1.4. QR code device provisioning
IT admins can use new or factory-reset device to scan a QR code generated by the EMM's console to provision the device, according to implementation guidelines defined in the Play EMM API developer documentation.
1.4.1. The QR code must use provisioning extras to pass non-sensitive registration details such as server IDs and enrollment IDs to a device. Registration details must not include sensitive information, such as passwords or certificates.
1.4.2. After the EMM's DPC sets up the device, the DPC must open immediately and lock itself to the screen until the device is fully provisioned.
1.5. Zero-touch enrollment
IT admins can preconfigure devices purchased from authorized resellers and manage them using your EMM console.
1.5.1. IT admins can provision company-owned devices using the zero-touch enrollment method, outlined in Zero-touch enrollment for IT admins.
1.5.2. When a device is first turned on, the device is automatically forced into the settings defined by the IT admin.
1.6. Advanced zero-touch provisioning
IT admins can automate much of the device enrollment process by deploying DPC registration details through zero-touch enrollment. The EMM's DPC supports limiting enrollment to specific accounts or domains, according to the configuration options offered by the EMM.
1.6.1. IT admins can provision a company-owned device using the zero-touch enrollment method, outlined Zero-touch enrollment for IT admins.
1.6.2. After the EMM's DPC sets up the device, the EMM's DPC must open immediately and lock itself to the screen until the device is fully provisioned.
- This requirement is waived for devices that use zero-touch enrollment registration details to fully provision themselves silently (for example, in a dedicated device deployment).
1.6.3. Using the registration details, the EMM's DPC must ensure that unauthorized users can't proceed with activation once the DPC is invoked. At a minimum, activation must be locked down to users of a given enterprise.
1.6.4. Using the registration details, the EMM's DPC must make it possible for IT admins to pre-populate registration details (for example server IDs, enrollment IDs) aside from unique user or device information (for example username/password, activation token), so that users don't have to enter details when activating a device.
- EMMs must not include sensitive information, such as passwords or certificates, in the zero-touch enrollment's configuration.
1.7. Google Account work profile provisioning
For enterprises that use a managed Google domain, this feature guides users through the setup of a work profile after entering their corporate Workspace credentials during device setup or on a device that is already activated. In both cases, the corporate Workspace identity will be migrated into the work profile.
1.7.1. The Google Account provisioning method provisions a work profile, according to the defined implementation guidelines .
1.8. Google Account device provisioning
For enterprises that use Workspace, this feature guides users through the installation of their EMM's DPC after they enter their corporate Workspace credentials during initial device setup. Once installed, the DPC completes the setup of a company-owned device.
1.8.1. The Google Account provisioning method provisions a company-owned device, according to the defined implementation guidelines .
1.8.2. Unless the EMM can unequivocally identify the device as a corporate asset, they cannot provision a device without a prompt during the provisioning process. This prompt must take a non-default action such as checking a checkbox or selecting a non-default menu choice. It's recommended the EMM is able to identify the device as a corporate asset so there's no need for the prompt.
1.9. Direct zero-touch configuration
IT admins can use the EMM's console to set up zero-touch devices using the zero-touch iframe.
1.10. Work profiles on company-owned devices
EMMs can enroll company-owned devices that have a work profile.
1.10.1. Deliberately blank.
1.10.2. IT admins can set compliance actions for work profiles on company-owned devices.
1.10.3. IT admins can deactivate the camera in either the work profile or the entire device.
1.10.4. IT admins can deactivate screen capture in either the work profile or an entire device.
1.10.5. IT admins can set an allowlist or blocklist of applications that can or cannot be installed in the personal profile.
1.10.6. IT admins can relinquish management of a company-owned device by removing the work profile or wiping the entire device.
1.11. Dedicated device provisioning
Deliberately blank.
2. Device security
2.1. Device security challenge
IT admins can set and enforce a device security challenge (PIN/pattern/password) from a predefined selection of 3 complexity levels on managed devices.
2.1.1. Policy must enforce settings managing device security challenges (parentProfilePasswordRequirements for work profile, passwordRequirements for fully managed and dedicated devices).
2.1.2. The password complexity must map to the following password complexities:
- PASSWORD_COMPLEXITY_LOW - pattern or pin with repeating (4444) or ordered (1234, 4321, 2468) sequences.
- PASSWORD_COMPLEXITY_MEDIUM - PIN with no repeating (4444) or ordered (1234, 4321, 2468) sequences, alphabetic, or alphanumeric password with a length of at least 4
- PASSWORD_COMPLEXITY_HIGH - PIN with no repeating (4444) or ordered (1234, 4321, 2468) sequences and a length of at least 8 or alphabetic or alphanumeric passwords with a length of at least 6
2.2. Work security challenge
IT admins can set and enforce a security challenge for apps and data in the work profile that is separate and has different requirements from the device security challenge (2.1.).
2.2.1. Policy must enforce the security challenge for the work profile. By default, IT admins should set restrictions only for the work profile if no scope is specified IT admins can set this device-wide by specifying the scope (see requirement 2.1)
2.1.2. The password complexity should map to the following password complexities:
- PASSWORD_COMPLEXITY_LOW - pattern or pin with repeating (4444) or ordered (1234, 4321, 2468) sequences.
- PASSWORD_COMPLEXITY_MEDIUM - PIN with no repeating (4444) or ordered (1234, 4321, 2468) sequences, alphabetic, or alphanumeric password with a length of at least 4
- PASSWORD_COMPLEXITY_HIGH - PIN with no repeating (4444) or ordered (1234, 4321, 2468) sequences and a length of at least 8 or alphabetic or alphanumeric passwords with a length of at least 6
2.3. Advanced passcode management
2.3.1. Deliberately blank.
2.3.2. Deliberately blank.
2.3.3. The following password lifecycle settings can be set for each lock screen available on a device:
- Deliberately blank
- Deliberately blank
- Maximum failed passwords for wipe : Specifies the number of times users can enter an incorrect password before corporate data is wiped from the device. IT admins must be able to turn off this feature.
2.4. Smart lock management
IT admins can manage what trust agents in Android's Smart Lock feature are permitted to unlock devices. IT admins can turn off specific unlock methods like trusted Bluetooth devices, face recognition, and voice recognition, or optionally turn off the feature entirely.
2.4.1. IT admins can disable Smart Lock trust agents, independently for each lock screen available on the device.
2.4.2. IT admins can selectively allow and set up Smart Lock trust agents , independently for each lock screen available on the device, for the following trust agents: Bluetooth, NFC, places, face, on-body, and voice.
- IT admins can modify the available Trust agent configuration parameters.
2.5. Wipe and lock
IT admins can use the EMM's console to remotely lock and wipe work data from a managed device.
2.5.1. The EMM's DPC must lock devices.
2.5.2. The EMM's DPC must wipe devices.
2.6. Compliance enforcement
If a device is not in compliance with security policies, work data is automatically restricted.
2.6.1. At minimum, the security policies enforced on a device must include password policy.
2.7. Default security policies
EMMs must enforce the specified security policies on devices by default, without requiring IT admins to set up or customize any settings in the EMM's console. EMMs are encouraged (but not required) to not allow IT admins to change the default state of these security features.
2.7.1. The EMM's DPC must block installing apps from unknown sources, including apps installed on the personal side of any Android 8.0+ device with a work profile.
2.7.2. The EMM's DPC must block debugging features.
2.8. Security policies for dedicated devices
Dedicated devices are locked down without an escape to allow other actions.
2.8.1. The EMM's DPC must turn off booting into safe mode by default.
2.8.2. The EMM's DPC must be opened and locked to the screen immediately on first boot during provisioning, to ensure no interaction with the device in any other way.
2.8.3. The EMM's DPC must be set as the default launcher to ensure allowed apps are locked to the screen on boot, according to the defined implementation guidelines.
2.9. Play Integrity Support
The EMM uses the Play Integrity API to ensure devices are valid Android devices.
2.9.1. The EMM's DPC implements the Play Integrity API during provisioning, and by default only completes provisioning of the device with corporate data when the device integrity returned is MEETS_STRONG_INTEGRITY .
2.9.2. The EMM's DPC will perform another Play Integrity check every time a device checks in with the EMM's server, configurable by the IT admin. The EMM server will verify the APK information in the integrity check response and the response itself before updating corporate policy on the device.
2.9.3. IT admins can set up different policy responses based on the outcome of the Play Integrity check, including blocking provisioning, wiping corporate data, and allowing enrollment to proceed.
- The EMM service will enforce this policy response for the result of each integrity check.
2.9.4. If the initial Play Integrity check fails or returns a result that does not meet strong integrity, if the EMM's DPC has not already called ensureWorkingEnvironment then it must do so and repeat the check before provisioning completes.
2.10. Verify Apps enforcement
IT admins can turn on Verify Apps on devices. Verify Apps scans apps installed on Android devices for harmful software before and after they're installed, helping to ensure that malicious apps can't compromise corporate data.
2.10.1. The EMM's DPC must turn on Verify Apps by default.
2.11. Direct Boot support
Apps can't run on Android 7.0+ devices that have just been powered on until the device is first unlocked. Direct Boot support ensures that the EMM's DPC is always active and able to enforce policy, even if the device has not been unlocked.
2.11.1. The EMM's DPC leverages device encrypted storage to perform critical management functions before the DPC's credential encrypted storage has been decrypted. Management functions available during Direct Boot must include (but are not limited to):
- Enterprise wipe, including the ability to wipe factory reset protection data as appropriate.
2.11.2. The EMM's DPC must not expose corporate data within device encrypted storage.
2.11.3. EMMs can set and activate a token to turn on a forgot my password button on the lock screen of the work profile. This button is used to request the IT admins securely reset the work profile password.
2.12. Hardware security management
IT admins can lock down hardware elements of a company-owned device to ensure data-loss prevention.
2.12.1. IT admins can block users from mounting physical external media on their device.
2.12.2. IT admins can block users from sharing data from their device using NFC beam . This subfeature is optional since the NFC beam function is no longer supported in Android 10 and higher.
2.12.3. IT admins can block users from transferring files over USB from their device.
2.13. Enterprise security logging
IT admins can gather usage data from devices that can be parsed and programmatically evaluated for malicious or risky behavior. Activities logged include Android Debug Bridge (adb) activity, app opens, and screen unlocks.
2.13.1. IT admins can enable security logging for specific devices, and the EMM's DPC must be able to retrieve both security logs and pre-reboot security logs automatically.
2.13.2. IT admins can review enterprise security logs for a given device and configurable time window, in the EMM's console.
2.13.3. IT admins can export enterprise security logs from the EMM's console.
3. Account and app management
3.1. Enterprise binding
IT admins can bind the EMM to their organization, allowing the EMM to use managed Google Play to distribute apps to devices.
3.1.1. An admin with an existing managed Google domain can bind their domain to the EMM.
3.1.2. The EMM's console must silently provision and set up a unique ESA for each enterprise.
3.1.3. Unenroll an enterprise using the Play EMM API.
3.1.4. The EMM console guides the admin to enter their work email address in the Android signup flow and discourages them from using a Gmail account.
3.1.5. The EMM pre-fills the admin's email address in the Android signup flow.
3.2. Managed Google Play account provisioning
The EMM can silently provision enterprise user accounts, called managed Google Play Accounts. These accounts identify managed users and allow unique, per-user app distribution rules.
3.2.1. The EMM's DPC can silently provision and activate a managed Google Play account according to the defined implementation guidelines. In doing so:
- A managed Google Play Account of type
userAccount
is added to the device. - The managed Google Play Account of type
userAccount
must have a 1-to-1 mapping with actual users in the EMM's console.
3.3. Managed Google Play device account provisioning
The EMM can create and provision managed Google Play device accounts . Device accounts support silently installing apps from the managed Google Play store, and are not tied to a single user. Instead, a device account is used to identify a single device to support per-device app distribution rules in dedicated device scenarios.
3.3.1. The EMM's DPC can silently provision and activate a managed Google Play
account according to the defined implementation guidelines.
In doing so, a managed Google Play account of type deviceAccount
must be added
to the device.
3.4. Managed Google Play account provisioning for legacy devices
The EMM can silently provision enterprise user accounts, called managed Google Play accounts. These accounts identify managed users and allow unique, per-user app distribution rules.
3.4.1. The EMM's DPC can silently provision and activate a managed Google Play account according to the defined implementation guidelines . In doing so:
- A managed Google Play Account of type
userAccount
is added to the device. - The managed Google Play Account of type
userAccount
must have a 1-to-1 mapping with actual users in the EMM's console.
3.5. Silent app distribution
IT admins can silently distribute work apps on users' devices without any user interaction.
3.5.1. The EMMs console must use the Play EMM API to allow IT admins to install work apps on managed devices.
3.5.2. The EMMs console must use the Play EMM API to allow IT admins to update work apps on managed devices.
3.5.3. The EMMs console must use the Play EMM API to allow IT admins to uninstall apps on managed devices.
3.6. Managed configuration management
IT admins can view and silently set managed configurations or any app that supports managed configurations.
3.6.1. The EMM's console must be able to retrieve and display the managed configuration settings of any Play app.
- EMMs can call
Products.getAppRestrictionsSchema
to retrieve an app's managed configurations schema or embed the managed configurations frame in their EMM console.
3.6.2. The EMM's console must allow IT admins to set any configuration type (as defined by the Android framework) for any Play app using th Play EMM API.
3.6.3. The EMM's console must allow IT admins to set wildcards (such as $username$ or %emailAddress%) so that a single configuration for an app such as Gmail can be applied to multiple users. The managed configuration iframe automatically supports this requirement.
3.7. App catalog management
IT admins can import a list of apps approved for their enterprise from managed Google Play (play.google.com/work).
3.7.1. The EMM's console can display a list of apps approve for distribution, including:
- Apps purchased in managed Google Play
- Private apps visible to IT admins
- Programmatically approved apps
3.8. Programmatic app approval
The EMM's console uses the managed Google Play iframe to support Google Play's app discovery and approval capabilities. IT admins can search for apps, approve apps, and approve new app permissions without leaving the EMM's console.
3.8.1. IT admins can search for apps and approve them within the EMM's console using the managed Google Play iframe.
3.9. Basic store layout management
The managed Google Play Store app can be used on devices to install and update work apps. The basic store layout is displayed by default and lists apps approved for the enterprise, which EMMs filter on a pe-users basis according to policy.
3.9.1. IT admins can [manage users' available product sets]/android/work/play/emm-api/samples#grant_a_user_access_to_apps) to allow viewing and installing applications from the managed Google Play store under the section 'Store home'.
3.10. Advanced store layout configuration
IT admins can customize the store layout seen in the managed Google Play store app on devices.
3.10.1. IT admins can perform the following actions in the EMM's console to customize the managed Google Play store layout:
- Create up to 100 store layout pages. Pages can have an arbitrary number of localized page names.
- Create up to 30 clusters for each page. Clusters can have an arbitrary number of localized cluster names.
- Assign up to 100 apps to each cluster.
- Add up to 10 quick links to each page.
- Specify the sort order of apps within a cluster and clusters within a page.
3.11. App license management
IT admins can view and manage app licenses purchased in managed Google Play from the EMM's console.
3.11.1. For paid apps approved for an enterprise, the EMM's console must display:
- The number of licenses purchased.
- The number of licenses consumed and the users consuming the licenses.
- The number of licenses available for distribution.
3.11.2. IT admins can silently assign licenses to users without forcing that app to be installed on any of the users' devices.
3.11.3. IT admins can unassign an app license from a user.
3.12. Google-hosted private app management
IT admins can update Google-hosted private apps through the EMM console instead of through the Google Play Console.
3.12.1. IT admins can upload new versions of apps that are already published privately to the enterprise using:
- The managed Google Play iframe , or
- The Google Play Developer Publishing API .
3.13. Self-hosted private app management
IT admins can set up and publish self-hosted private apps. Unlike Google-hosted private apps, Google Play does not host the APKs. Instead, the EMM helps IT admins host APKs themselves, and helps protect self-hosted apps by ensuring they can only be installed when authorized by managed Google Play.
IT admins can go to Support private apps for details.
3.13.1. The EMM's console must help IT admins host the app APK, by offering both of the following options:
- Hosting the APK on the EMM's server. The server can be on-premise or cloud-based.
- Hosting the APK outside of the EMM's server, at the discretion of the IT admin. The IT admin must specify in the EMM console where the APK is hosted.
3.13.2. The EMM's console must generate an appropriate APK definition file using the provided APK and must guide IT admins through the publishing process.
3.13.3. IT admins can update self-hosted private apps, and the EMM's console can silently publish updated APK definition files using the Google Play Developer Publishing API.
3.13.4. The EMM's server only serves download requests for the self-hosted APK that contains a valid JWT within the request's cookie, as verified by the private app's public key.
- To facilitate this process, the EMM's server must guide IT admins to download the self-hosted app's license public key from the Play Google Play Console, and upload this key to the EMM console.
3.14. EMM pull notifications
Instead of periodically querying Play to identify past events such as an app update that contains new permissions or managed configurations, EMM pull notifications proactively notify EMMs of such events in real time, allowing EMMs to take automated actions and provide custom administrative notifications based on these events.
3.14.1. The EMM must use Play's EMM notifications to pull notification sets.
3.14.2. EMM must automatically notify an IT admin (for example by an automated email) of the following notification events:
newPermissionEvent
: Requires an IT admin to approve new app permissions before the app can be silently installed or updated on users' devices.appRestrictionsSchemaChangeEvent
: May require IT admin to update an app's managed configuration to maintain intended efficiency.appUpdateEvent
: May be of interest to IT admins who want to validate that core workflow performance is unaffected by app update.productAvailabilityChangeEvent
: May impact ability to install the app or take app updates.installFailureEvent
: Play is unable to silently install an app on a device, suggesting there may be something about the device configuration that is preventing the install. EMMs shouldn't immediately try a silent install again after receiving this notification, as Play's own retry logic will have already failed.
3.14.3. EMM automatically takes appropriate actions based on the following notification events:
newDeviceEvent
: During device provisioning, EMMs must wait fornewDeviceEvent
before making subsequent Play EMM API calls for the new device, including silent app installs and setting managed configurations.productApprovalEvent
: upon receiving aproductApprovalEvent
notification, EMM must automatically update the list of approved apps imported into the EMM console for distribution to devices if there's an active IT admin session, or if the list of approved apps is not automatically reloaded at the start of each IT admin session.
3.15. API usage requirements
The EMM implements Google's APIs at scale, avoiding traffic patterns that could negatively impact IT admins' ability to manage apps in production environments.
3.15.1. The EMM must adhere to the Play EMM API usage limits. Not correcting behavior that exceeds these guidelines may result in suspension of API use, at Google's discretion.
3.15.2. The EMM should distribute traffic from different enterprises throughout the day, rather than consolidating enterprise traffic at specific or similar times. Behavior that fits this traffic pattern, such as scheduled batch operations for each device enrolled, may result in suspending API use, at Google's discretion.
3.15.3. The EMM shouldn't make consistent, incomplete, or deliberately incorrect requests that make no attempt to retrieve or manage actual enterprise data. Behavior that fits this traffic pattern may result in suspended API use, at Google's discretion.
3.16. Advanced managed configuration management
3.16.1. The EMM's console must be able to retrieve and display the managed configuration settings (nested up to four levels) of any Play app, using:
- The Managed Google Play iFrame , or
- a custom UI.
3.16.2. The EMM's console must be able to retrieve and display any feedback returned by an app's feedback channel , when set up by an IT admin.
- The EMM's console must allow IT admins to associate a specific feedback item with the device and app it originated from.
- The EMM's console must allow IT admins to subscribe to alerts or reports of specific message types (such as error messages).
3.16.3. The EMM's console must only send values that either have a default value or are manually set by the admin using:
- The managed configurations iframe, or
- A custom UI.
3.17. Web app management
IT admins can create and distribute web apps in the EMM console.
3.17.1. IT admins can use the EMM's console to distribute shortcuts to web apps using:
- The Managed Google Play iframe , or
- the Play EMM API .
3.18. Managed Google Play account lifecycle management
The EMM can create, update, and delete managed Google Play Accounts on behalf of IT admins.
3.18.1. EMMs can manage the lifecycle of a managed Google Play Account according to the implementation guidelines defined in the Play EMM API developer documentation.
3.18.2. EMMs can reauthenticate managed Google Play Accounts without user interaction.
3.19. Application track management
3.19.1. IT admins can pull a list of track IDs set by a developer for a particular app.
3.19.2. IT admins can set devices to use a particular development track for an application.
3.20. Advanced application update management
3.20.1. IT admins can allow apps to use high-priority app updates to be updated when an update is ready.
3.20.2. IT admins can allow apps to have their app updates postponed for 90 days.
3.21. Provisioning methods management
The EMM can generate provisioning configurations and present these to the IT admin in a form ready for distribution to end users (such as QR code, zero-touch configuration, Play Store URL).
4. Device management
4.1. Runtime permission policy management
IT admins can silently set a default response to runtime permission requests made by work apps.
4.1.1. IT admins must be able to choose from the following options when setting a default runtime permission policy for their organization:
- prompt (allows users to choose)
- allow
- deny
The EMM should enforce these settings using the EMM's DPC.
4.2. Runtime permission grant state management
After setting a default runtime permission policy (go to 4.1.), IT admins can silently set responses for specific permissions from any work app built on API 23 or higher.
4.2.1. IT admins must be able to set the grant state (default, grant, or deny) of any permission requested by any work app built on API 23 or higher. The EMM should enforce these settings using the EMM's DPC .
4.3. Wi-Fi configuration management
IT admins can silently provision enterprise Wi-Fi configurations on managed devices, including:
4.3.1. SSID, using the EMM's DPC.
4.3.2. Password, using the EMM's DPC.
4.4. Wi-Fi security management
IT admins can provision enterprise Wi-Fi configurations on managed devices that include the following advanced security features:
4.4.1. Identity, using the EMM's DPC.
4.4.2. Certificate for clients authorization, using the EMM's DPC .
4.4.3. CA certificate(s), using the EMM's DPC.
4.5. Advanced Wi-Fi management
IT admins can lock down Wi-Fi configurations on managed devices, to prevent users from creating configurations or modifying corporate configurations.
4.5.1. IT admins can lock down corporate Wi-Fi configurations in either of the following configurations:
- Users cannot modify any Wi-Fi configurations provisioned by the EMM, but may add and modify their own user-configurable networks (for example personal networks).
- Users cannot add or modify any Wi-Fi network on the device, limiting Wi-Fi connectivity to just those networks provisioned by the EMM.
4.6. Account management
IT admins can ensure that unauthorized corporate accounts can't interact with corporate data, for services such as SaaS storage and productivity apps, or email. Without this feature, personal accounts can be added to those corporate apps that also support consumer accounts, allowing them to share corporate data with those personal accounts.
4.6.1. IT admins can prevent adding or modifying accounts.
- When enforcing this policy on a device, EMMs must set this restriction before provisioning is complete, to ensure you cannot circumvent this policy by adding accounts before the policy is enacted.
4.7. Workspace account management
IT admins can ensure that unauthorized Google Accounts can't interact with corporate data. Without this feature, personal Google Accounts can be added to corporate Google apps (for example Google Docs or Google Drive), allowing them to share corporate data with those personal accounts.
4.7.1. IT admins can specify Google Accounts to activate during provisioning, after the account management lockdown is in place.
4.7.2. The EMM's DPC must prompt to activate the Google account, and ensure that only the specific account can be activated by specifying the account to be added.
- On devices lower than Android 7.0, the DPC must temporarily turn off the account management restriction before prompting the user.
4.8. Certificate management
Allows IT admins to deploy identity certificates and certificate authorities to devices to allow access to corporate resources.
4.8.1. IT admins can install user identity certs generated by their PKI on a per-user basis. The EMM's console must integrate with at least one PKI and distribute certificates generated from that infrastructure.
4.8.2. IT admins can install certificate authorities in the managed keystore.
4.9. Advanced certificate management
Allows IT admins to silently select the certificates that specific managed apps should use. This feature also grants IT admins the ability to remove CAs and identity certs from active devices. This feature prevents users from modifying credentials stored in the managed keystore.
4.9.1. For any app distributed to devices, IT admins can specify a certificate the app will be silently granted access to during runtime.
- Certificate selection must be generic enough to allow a single configuration that applies to all users, each of which may have a user-specific identity certificate.
4.9.2. IT admins can silently remove certificates from the managed keystore.
4.9.3. IT admins can silently uninstall a CA certificate, or all non-system CA certificates.
4.9.4. IT admins can prevent users from configuring credentials in the managed keystore.
4.9.5. IT admins can pre-grant certificates for work apps.
4.10. Delegated certificate management
IT admins can distribute a third-party certificate management app to devices and grant that app privileged access to install certificates into the managed keystore.
4.10.1. IT admins specify a certificate management package to set as the delegated certificate management app by the DPC.
- Console may optionally suggest known certificate management packages, but must allow the IT admin to choose from the list of apps available for install, for applicable users.
4.11. Advanced VPN management
Allows IT admins to specify an Always On VPN to ensure that the data from specified managed apps will always go through a set up VPN.
4.11.1. IT admins can specify an arbitrary VPN package to be set as an Always On VPN.
- The EMM's console may optionally suggest known VPN packages that support Always On VPN, but can't restrict the VPNs available for Always On configuration to any arbitrary list.
4.11.2. IT admins can use managed configurations to specify the VPN settings for an app.
4.12. IME management
IT admins can manage what input methods (IMEs) can be set up for devices. Since the IME is shared across both work and personal profiles, blocking use of IMEs will prevent allowing those IMEs for personal use as well. IT admins may not, however, block system IMEs on work profiles (go to advanced IME management for more details).
4.12.1. IT admins can set up an IME allowlist of arbitrary length (including an empty list, which blocks non-system IMEs), which may contain any arbitrary IME packages.
- The EMM's console may optionally suggest known or recommended IMEs to include in the allowlist, but must allow IT admins to choose from the list of apps available for install, for applicable users.
4.12.2. The EMM must inform IT admins that system IMEs are excluded from management on devices with work profiles.
4.13. Advanced IME management
IT admins can manage what input methods (IMEs) can be set up for devices. Advanced IME management extends the basic feature by allowing IT admins to manage the use of system IMEs as well, which are typically provided by the device manufacturer or carrier of the device.
4.13.1. IT admins can set up an IME allowlist of arbitrary length (excluding an empty list, which blocks all IMEs including system IMEs), which may contain any arbitrary IME packages.
- The EMM's console may optionally suggest known or recommended IMEs to include in the allowlist, but must allow IT admins to choose from the list of apps available for install, for applicable users.
4.13.2. EMMs must prevent IT admins from setting up an empty allowlist, as this setting will block all IMEs including system IMEs from being set up on the device.
4.13.3. EMMs must ensure that if an IME allowlist does not contain system IMEs, the third-party IMEs are silently installed before the allowlist is applied on the device.
4.14. Accessibility services management
IT admins can manage what accessibility services can be allowed on users' devices. While accessibility services are powerful tools for users with disabilities or those that are temporarily unable to fully interact with their device, they may interact with corporate data in ways that are non-compliant with corporate policy. This feature allows IT admins to turn off any non-system accessibility service.
4.14.1. IT admins can set up an accessibility service allowlist of arbitrary length (including an empty list, which blocks non-system accessibility services), which may contain any arbitrary accessibility service package. When applied to a work profile, this affects both the personal profile and the work profile.
- Console may optionally suggest known or recommended accessibility services to include in the allowlist, but must allow IT admins to choose from the list of apps available for install, for applicable users.
4.15. Location Sharing management
IT admins can prevent users from sharing location data with apps in the work profile. Otherwise, the location setting for work profiles is configurable in Settings.
4.15.1. IT admins can disable location services within the work profile.
4.16. Advanced Location Sharing management
IT admins can enforce a given Location Sharing setting on a managed device. This feature can ensure that corporate apps always have access to high accuracy location data. This feature can also ensure that extra battery is not consumed by restricting location settings to battery saving mode.
4.16.1. IT admins can set the device location services to each of the following modes:
- High accuracy.
- Sensors only, for example GPS, but not including network-provided location.
- Battery saving, which limits the update frequency.
- Off.
4.17. Factory reset protection management
Allows IT admins to protect company-owned devices from theft by ensuring unauthorized users can't factory reset devices. If factory reset protection introduces operational complexities when devices are returned to IT, IT admins can also turn off factory reset protection entirely.
4.17.1. IT admins can prevent users from factory resetting their device from Settings.
4.17.2. IT admins can specify corporate unlock accounts authorized to provision devices after a factory reset.
- This account can be tied to an individual, or used by the entire enterprise to unlock devices.
4.17.3. IT admins can disable factory reset protection for specified devices.
4.17.4. IT admins can start a remote device wipe that optionally wipes reset protection data, thus removing factory reset protection on the reset device.
4.18. Advanced app control
IT admins can prevent the user from uninstalling or otherwise modifying managed apps through Settings, for example force closing the app or clearing an app's data cache.
4.18.1. IT admins can block uninstall of any arbitrary managed apps, or all managed apps.
4.18.2. IT admins can prevent users from modifying application data from Settings.
4.19. Screen capture management
IT admins can block users from taking screenshots when using managed apps. This setting includes blocking screen sharing apps and similar apps (such as Google Assistant) that use the system screenshot capabilities.
4.19.1. IT admins can prevent users from capturing screenshots .
4.20. Disable cameras
IT admins can turn off use of device cameras by managed apps.
4.20.1. IT admins can turn off use of device cameras by managed apps.
4.21. Network statistics collection
IT admins can query network usage statistics from a device's work profile. The statistics collected reflect the usage data shared with users in the Data usage section of Settings. The collected statistics are applicable to usage of apps within the work profile.
4.21.1. IT admins can query the network statistics summary for a work profile, for a given device and configurable time window, and view these details in the EMM's console.
4.21.2. IT admins can query a summary of an app in the work profile's network use statistics, for a given device and configurable time window, and view these details organized by UID in the EMM's console.
4.21.3. IT admins can query a work profile's network use historical data, for a given device and configurable time window, and view these details organized by UID in the EMM's console.
4.22. Advanced network statistics collection
IT admins can query network usage statistics for an entire managed device. The statistics collected reflect the use data shared with users in the Data Use section of Settings. The statistics collected are applicable to use of apps on the device.
4.22.1. IT admins can query the network statistics summary for an entire device , for a given device and configurable time window, and view these details in the EMM's console.
4.22.2. IT admins can query a summary of app network use statistics, for a given device and configurable time window, and view these details organized by UID in the EMM's console.
4.22.3. IT admins can query the network use historical data, for a given device and configurable time window, and view these details organized by UID in the EMM's console.
4.23. Reboot device
IT admins can remotely restart managed devices.
4.23.1. IT admins can remotely reboot a managed device.
4.24. System radio management
Allows IT admins granular management over system network radios and associated use policies.
4.24.1. IT admins can disable cell broadcasts sent by service providers (for example, AMBER alerts).
4.24.2. IT admins can prevent users from modifying mobile network settings in Settings .
4.24.3. IT admins can prevent users from resetting network settings in Settings .
4.24.4. IT admins can allow or disallow mobile data while roaming .
4.24.5. IT admins can set up whether the device can make outgoing phone calls , excluding emergency calls.
4.24.6. IT admins can set up whether the device can send and receive text messages .
4.24.7. IT admins can prevent users from using their device as a portable hotspot by tethering .
4.24.8. IT admins can set the Wi-Fi timeout to the default , only while plugged in , or never .
4.24.9. IT admins can prevent users from setting up or modifying existing Bluetooth connections .
4.25. System audio management
IT admins can silently manage device audio features, including muting the device, preventing users from changing volume settings, and preventing users from unmuting the device microphone.
4.25.1. IT admins can silently mute managed devices.
4.25.2. IT admins can prevent users from modifying device volume settings.
4.25.3. IT admins can prevent users from unmuting the device microphone.
4.26. System clock management
IT admins can manage device clock and time zone settings, and prevent users from modifying automatic device settings.
4.26.1. IT admins can enforce system auto time, preventing the user from setting the date and time of the device.
4.26.2. IT admins can silently turn off or on both auto time and auto timezone.
4.27. Advanced dedicated device features
Provides IT admins with the ability to manage more granular dedicated device features to support various kiosk use cases.
4.27.1. IT admins can disable the device keyguard.
4.27.2. IT admins can turn off the device status bar, blocking notifications and Quick Settings.
4.27.3. IT admins can force the device screen to remain on while the device is plugged in.
4.27.4. IT admins can prevent the following system UIs from being displayed:
- Toasts
- Application overlays.
4.27.5. IT admins can allow the system recommendation for apps to skip their user tutorial and other introductory hints on first start-up.
4.28. Delegated scope management
IT admins are able to delegate extra privileges to individual packages.
4.28.1. IT admins can manage the following scopes:
- Certificate installation and management
- Deliberately blank
- Network logging
- Security logging (not supported for work profile on personally-owned device)
4.29. Enrollment-specific ID support
Starting in Android 12, work profiles will no longer have access to hardware-specific identifiers. IT admins can follow the lifecycle of a device with a work profile through the enrollment-specific ID, which will persist through factory resets.
4.29.1. IT admins can set and obtain an enrollment-specific ID
4.29.2. This enrollment-specific ID must persist through a factory reset
5. Device usability
5.1. Managed provisioning customization
IT admins can modify the default setup flow UX to include enterprise-specific features. Optionally, IT admins can display EMM-provided branding during provisioning.
5.1.1. IT admins can customize the provisioning process by specifying the following enterprise-specific details: enterprise color, enterprise logo, enterprise terms of service and other disclaimers.
5.1.2. IT admins can deploy a non-configurable, EMM-specific customization that includes the following details: EMM color, EMM logo, EMM terms of service and other disclaimers.
5.1.3 [primaryColor
] has been deprecated for the enterprise resource on
Android 10 and higher.
- EMMs must include provisioning Terms of Service and other disclaimers for their provisioning flow in the system provisioning disclaimers bundle, even if the EMM-specific customization is not used.
- EMMs may set their non-configurable, EMM-specific customization as the default for all deployments, but must allow IT admins to set up their own customization.
5.2. Enterprise customization
IT admins can customize aspects of the work profile with corporate branding. For example, IT admins can set the user icon in the work profile to the corporate logo. Another example is setting up the background color of the work challenge.
5.2.1. IT admins can set the organization color, to be used as the background color of work challenge.
5.2.2. IT admins can set the display name of work profile .
5.2.3. IT admins can set the user icon of the work profile .
5.2.4. IT admins can prevent the user from modifying the work profile user icon .
5.3. Advanced enterprise customization
IT admins can customize managed devices with corporate branding. For example, IT admins can set the primary user icon to the corporate logo, or set the device wallpaper.
5.3.1. IT admins can set the display name for the managed device .
5.3.2. IT admins can set the user icon of the managed device .
5.3.3. IT admins can prevent the user from modifying the device user icon .
5.3.4. IT admins can set the device wallpaper .
5.3.5. IT admins can prevent the user from modifying the device wallpaper .
5.4. Lock screen messages
IT admins can set a custom message that's always displayed on the device lock screen, and does not require device unlock to be viewed.
5.4.1. IT admins can set a custom lock screen message.
5.5. Policy transparency management
IT admins can customize the help text provided to users when they modify managed settings on their device, or deploy an EMM-supplied generic support message. Both short and long support messages can be customized. These messages are displayed in instances such as attempting to uninstall a managed app for which an IT admin has already blocked uninstallation.
5.5.1. IT admins customize both the short and long support messages.
5.5.2. IT admins can deploy non-configurable, EMM-specific short and long support messages.
- EMM may set their non-configurable, EMM-specific support messages as the default for all deployments, but must allow IT admins to set up their own messages.
5.6. Cross-profile contact management
IT admins can control what contact data can leave the work profile. Both telephony and messaging (SMS) apps must run in the personal profile, and require access to work profile contact data to offer efficiency for work contacts, but admins may choose to disable these features to protect work data.
5.6.1. IT admins can disable cross-profile contact search for personal apps that use the system contacts provider.
5.6.2. IT admins can disable cross-profile caller ID lookup for personal dialer apps that use the system contacts provider.
5.6.3. IT admins can disable bluetooth contact sharing with bluetooth devices that use the system contacts provider, for example hands-free calling in cars or headsets.
5.7. Cross-profile data management
Grants IT admins management over what data can leave the work profile, beyond the default security features of the work profile. With this feature, IT admins can allow select types of cross-profile data sharing to improve usability in key use cases. IT admins can also further protect corporate data with more lockdowns.
5.7.1. IT admins can configure cross-profile intent filters so that personal apps can resolve intent from the work profile such as sharing intents or web links.
- Console may optionally suggest known or recommended intent filters for configuration, but can't restrict intent filters to any arbitrary list.
5.7.2. IT admins can allow managed apps that can display widgets on the homescreen.
- The EMM's console must provide IT admins the ability to choose from the list of apps that are available for install to applicable users.
5.7.3. IT admins can block the use of copy/paste between the work and personal profiles.
5.7.4. IT admins can block users from sharing data from the work profile using NFC beam.
5.7.5. IT admins can permit personal apps to open web links from the work profile.
5.8. System update policy
IT admins can set up and apply over-the-air (OTA) system updates for devices.
5.8.1. The EMM's console allows IT admins to set the following OTA configurations:
- Automatic: Devices install OTA updates when they become available.
- Postpone: IT admins must be able to postpone OTA update for up to 30 days. This policy does not affect security updates (e.g. monthly security patches).
- Windowed: IT admins must be able to schedule OTA updates within a daily maintenance window.
5.8.2. The EMM's DPC applies OTA configurations to devices.
5.9. Lock task mode management
IT admins can lock an app or set of apps to the screen, and ensure that users can't exit the app.
5.9.1. The EMM's console allows IT admins to silently allow an arbitrary set of apps to install and lock to a device. The EMM's DPC allows dedicated device mode.
5.10. Persistent preferred activity management
Allows IT admins to set an app as the default intent handler for intents that match a certain intent filter. For example, allowing IT admins to choose which browser app automatically opens web links, or which launcher app is used when tapping the home button.
5.10.1. IT admins can set any package as the default intent handler for any arbitrary intent filter.
- The EMM's console may optionally suggest known or recommended intents for configuration, but cannot restrict intents to any arbitrary list.
- The EMM's console must allow IT admins to choose from the list of apps that are available to install for applicable users.
5.11. Keyguard feature management
- trust agents
- fingerprint unlock
- unredacted notifications
5.11.2. The EMM's DPC can turn off the following keyguard features in the work profile:
- trust agents
- fingerprint unlock
5.12. Advanced keyguard feature management
- Secure camera
- All notifications
- Unredacted notifications
- Trust agents
- Fingerprint unlock
- All keyguard features
5.13. Remote debugging
IT admins can retrieve debugging resources from devices without requiring extra steps.
5.13.1. IT admins can remotely request bug reports, view bug reports from the EMM's console, and download bug reports from the EMM's console.
5.14. MAC address retrieval
EMMs can silently fetch a device's MAC address. The MAC address can be used to identify devices in other parts of the enterprise infrastructure (for example when identifying devices for network access control).
5.14.1. The EMM can silently retrieve a device's MAC address and can associate it with the device in the EMM's console.
5.15. Advanced lock task mode management
When a device is set up as a dedicated device, IT admins can use the EMM's console to perform the following tasks:
5.15.1. Silently allow a single app to lock to a device using the EMM's DPC.
5.15.2. Turn on or turn off the following System UI features using the EMM's DPC :
- Home button
- Overview
- Global actions
- Notifications
- System info / Status bar
- Keyguard (lock screen)
5.15.3. Turn off System Error dialogs using the EMM's DPC.
5.16. Advanced system update policy
IT admins can block system updates on a device for a specified freeze period.
5.16.1. The EMM's DPC can apply over-the-air (OTA) system updates to devices for a specified freeze period.
5.17. Work profile policy transparency management
IT admins can customize the message displayed to users when removing the work profile from a device.
5.17.1. IT admins can provide custom text to display when a work profile is wiped.
5.18. Connected app support
IT admins can set a list of packages that can communicate across the work profile boundary.
5.19. Manual System Updates
IT admins can manually install a system update by providing a path.
6. Device Admin Deprecation
6.1. Device Admin Deprecation
EMMs are required to post a plan by the end of 2022 ending customer support for Device Admin on GMS devices by the end of Q1 2023.
7. API usage
7.1. Standard policy controller for new bindings
By default devices must be managed using Android Device Policy for any new bindings. EMMs may provide the option to manage devices using a custom DPC in a settings area under a heading 'Advanced' or similar terminology. New customers must not be exposed to an arbitrary choice between technology stacks during any onboarding or setup workflows.
7.2. Standard policy controller for new devices
By default devices must be managed using Android Device Policy for all new device enrollments, for both existing and new bindings. EMMs may provide the option to manage devices using a custom DPC in a settings area under a heading 'Advanced' or similar terminology.