This page provides an overview of the new enterprise APIs, features, and behavior changes that are available in the Android P developer preview.
Work profile user interface
Android P includes user interface changes in the default launcher to help users separate personal and work apps. Device manufacturers supporting this can now present users' apps in separate work and personal tabs. We've also made it easier for device users to turn the work profile on and off by including a switch in the launcher's work tab.
When provisioning work profiles and managed devices, Android P includes new animated illustrations to help device users understand these features.
Switch apps across profiles
Android P includes new APIs to launch another instance of an app in a different
profile to help users switch between accounts. For example, an email app can
provide a UI that lets the user switch between the personal profile and the work
profile to access two email accounts. All apps can call these APIs to launch the
main activity of the same app if it's already installed in the other profile. To
add cross-profile account switching to your app, follow the steps below calling
methods of the new
getTargetUserProfiles()to get a list of profiles you can launch another instance of the app in. This method checks that the app is installed in the profiles.
getProfileSwitchingIconDrawable()to get an icon that you can use to represent another profile.
getProfileSwitchingLabel()to get localized text that prompts the user to switch profiles.
startMainActivity()to launch an instance of your app in another profile.
Programmatically turn work profiles on or off
The default launcher (or apps that have the permission
MODIFY_QUIET_MODE) can now turn the work profile on or off by calling
UserManager.requestQuietModeEnabled(). You can
inspect the return value to know if the user needs to confirm their
credentials before the state changes. Because the change might not happen
instantly, listen for the
broadcast to know when to update the user interface.
Your app can check the status of the work profile by calling
Lock down any app to a device
Starting in Android P, device owners and profile owners can lock any app to a device’s screen by putting the app into lock task mode. Previously, app developers had to add support for lock task mode in their apps. Android P also extends the lock task APIs to profile owners of affiliated and non-affiliated users. Follow the steps below to lock an app to the screen:
DevicePolicyManager.setLockTaskPackages()to whitelist apps for lock task mode.
ActivityOptions.setLockTaskEnabled()to launch a whitelisted app into lock task mode.
To stop an app in lock task mode, remove the app from the lock task mode
Enable system UI features
When lock task mode is enabled, device owners can enable certain system UI
features on the device by calling
DevicePolicyManager.setLockTaskFeatures() and passing a
bit field of the following feature flags:
You can call
to get the list of features available on a device when lock task mode is
enabled. When a device exits lock task mode, it returns to the state mandated by
other device policies.
Suppress error dialogs
In some environments, such as retail demonstrations or public information
displays, you might not want to show error dialogs to users. A device policy
controller (DPC) can suppress system error dialogs for crashed or unresponsive
apps by adding the
restriction. This restriction affects all dialogs when applied by a device owner
but only the error dialogs shown in the work profile are suppressed when the
restriction is applied by profile owners.
Support multiple users on dedicated devices
Android P introduces the concept of an ephemeral user for dedicated devices (also called COSU devices). Ephemeral users are short-term users intended for cases where multiple users share a single dedicated device. This includes public user sessions on devices such as library or hospitality check-in kiosks, as well as persistent sessions between a fixed set of users on devices, for example, shift workers.
Ephemeral users should be created in the background. They are created as secondary users on a device and are removed (along with associated apps and data) when they are stopped, switched, or the device reboots. To create an ephemeral user, device owners can:
- Set the
MAKE_USER_EPHEMERALflag when calling
DevicePolicyManager.startUserInBackground()to start the ephemeral user in the background.
Receive event notifications
DeviceAdminReceiver now receives notifications for
the following events:
onUserStarted(): Called when a user starts.
onUserSwitched(): Called when a user switch is completed.
onUserStopped(): Called along with
onUserRemoved()when a user stops or logs out.
Display event messages to users
Device owners can configure the messages that are displayed to users when they start and end their sessions:
DevicePolicyManager.setStartUserSessionMessage()to set the message that's displayed to a user when the user's session begins. To retrieve the message, call
DevicePolicyManager.setEndUserSessionMessage()to set the message that's displayed to the user when the user's session ends. To retrieve the message, call
Log out and stop users
Profile owners of secondary users can call
DevicePolicyManager.logoutUser() to stop the secondary user and
switch back to the primary user.
Device owners can use
DevicePolicyManager.stopUser() to stop a
specified secondary user.
To streamline user provisioning on shared devices with a fixed set of users, such as devices for shift workers, it's now possible to cache packages that are needed for multi-user sessions:
Additional methods and constants
Android P also includes the following new methods and constants to further support user sessions on shared devices:
DevicePolicyManager.getSecondaryUsers()gets a list of all secondary users on a device.
DISALLOW_USER_SWITCHis a new user restriction you can enable by calling
DevicePolicyManager.addUserRestriction()to block user switching.
LEAVE_ALL_SYSTEM_APPS_ENABLEDis a new flag available for
DevicePolicyManager.createAndManageUser(). When set, system apps aren't disabled during user provisioning.
Clear package data and remove accounts
Device owners and profile owners can call
clearApplicationUserData() to clear the user data
for a given package. To remove an account from the
AccountManager, device and profile owners can now call
New user restrictions and increased control over settings
Android P introduces a new set of user restrictions for DPCs, as well as the ability to configure APNs, time and timezone, and system settings on a device.
Device owners can use the following new methods in the
DevicePolicyManager class to configure APNs on a
Configure time and timezone
Device owners can use the following new methods in the
DevicePolicyManager class to set the time and timezone
on a device:
Enforce user restrictions on important settings
Profile owners and device owners can prevent or disable important settings with
the following new
UserManager fields with
DISALLOW_CONFIG_SCREEN_TIMEOUT are enforced
on a device, device owners can still set the screen
brightness, screen brightness
mode, and screen timeout settings
on the device using the new API
Device owners and profile owners can prevent apps from using a device's
metered-data networks. A network is considered metered when when the user is
sensitive to heavy data usage because of cost, data limits, or battery and
performance issues. To prevent apps from using metered networks, call
a list of package names. To retrieve the currently restricted apps, call
To learn more about metered data in Android, read Optimizing Network Data Usage.
Device policy controllers (DPCs) can transfer their ownership of a device or work profile to another DPC. You might transfer ownership to move some features to the Android Management API, to migrate devices from your legacy DPC, or to help IT admins migrate to your EMM. Because you're just changing the DPC ownership, you can't use this feature to change the type of management, for example, migrating from a managed device to a work profile or vice-versa.
You can use the app manifest file to indicate that the version of your DPC
supports migration. A target DPC indicates it can receive ownership by including
a metadata element named
android.app.support_transfer_ownership (the raw value
and a value of
true. The example below shows how you might do this in your
DPC's app manifest file:
<receiver name="..." android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/..." /> <meta-data android:name="android.app.support_transfer_ownership" android:value="true" /> </receiver>
Android maintains the source DPC's system and user policies through an ownership
transfer—DPCs don't need to migrate these. A source DPC can pass custom data to
the target DPC using key-value pairs in a
PersistableBundle. After a
successful transfer, the target DPC can retrieve this data by calling
The steps to transfer ownership of a managed device or a work profile are the same:
- The source DPC calls
transferOwnership()to start the transfer.
- The system makes the target DPC the active admin and sets it as the owner of the managed device or work profile.
- The target DPC receives the callback
onTransferOwnershipComplete()and can configure itself using values from the
- If something goes wrong with the transfer, the system reverts ownership to
the source DPC. If your source DPC needs to confirm that the ownership transfer
isAdminActive()to check that the source DPC is no longer the active admin.
All apps running in the work profile receive the
ACTION_PROFILE_OWNER_CHANGED broadcast when
the profile owner changes. Apps running on a managed device receive the
ACTION_DEVICE_OWNER_CHANGED broadcast when the
device owner changes.
Work profiles on fully managed devices
Transferring two instances of a DPC running as device owner and profile owner happens in two stages. When the personal profile and work profile are affiliated, complete the transfer in the following order:
- First, transfer ownership of the work profile.
- Wait for the
onTransferAffiliatedProfileOwnershipComplete()to confirm that the work profile was transferred to the target DPC.
- Finally, transfer ownership of the managed device to the target DPC.
Postpone Over-the-air (OTA) updates
Device owners can postpone OTA system updates to devices for up to 90 days to freeze the OS version running on these devices over critical periods (such as holidays). The system enforces a mandatory 60-day buffer after any defined freeze period to prevent freezing the device indefinitely.
During a freeze period:
- Devices don't receive any notifications about pending OTA updates.
- Devices don't install any OTA updates to the OS.
- Device users aren't able to manually check for OTA updates in Settings.
To set a freeze period, call
SystemUpdatePolicy.setFreezePeriods(). Because the freeze
period repeats annually, the start and end dates of the period are represented
by integers counting the number of days since year start. The start day must
begin at least 60 days after the end of any previous freeze period. Device
owners can call
get a list of freeze periods previously set on the system update policy object.
DevicePolicyManager.getSystemUpdatePolicy() has been
updated to return any freeze periods set by the device owner.
Restrict sharing into a work profile
Profile owners can prevent users from sharing personal data into a work profile
on the device by adding the user restriction
This restriction prevents the following intent handling and sharing:
- Personal profile apps sharing data and files with work profile apps.
- Work profile apps picking items from the personal profile—for example, pictures or files.
After setting this restriction, your DPC can still permit cross-profile Activity
intents by calling
Hardware-secured keys and machine certificates
Android P adds new APIs to help you work with keys and certificates that you can combine to securely identify devices. A DPC running in profile owner or device owner modes, or a delegated certificate installer, can now complete the following tasks:
- Generate keys and certificates in the secure hardware (such as a trusted
execution environment (TEE) or Secure Element (SE)) of the Android device. The
generated keys never leave the secure hardware and can be used from the Android
DevicePolicyManager.generateKeyPair()supplying the algorithm (see
KeyPairGenerator) and any hardware IDs you want attested, such as the serial number or IMEI. To learn more about secure hardware changes, read Security updates.
- Associate a certificate with an existing device-generated key. Call
DevicePolicyManager.setKeyPairCertificate()supplying the alias of the existing key and the certificate chain—starting with the leaf certificate and including the chain of trust in order.
- Confirm that the secure hardware protects the key before using it. To check which mechanisms protect the key, follow the steps in Key Attestation.
- Device owners and delegated certificate installers can receive a signed
statement of the devices' hardware IDs with Android system versions. Call
DevicePolicyManager.generateKeyPair()passing one or more of
idAttestationFlagsargument. The returned certificate includes the hardware IDs in the attestation record. If you don't want the hardware IDs included, pass
0. Profile owners can only receive manufacturer information (by passing
- Prevent device users from mis-using enterprise keys by calling
isUserSelectableargument. The system doesn't include unselectable certificates in the picker panel. In your
DeviceAdminReceiver.onChoosePrivateKeyAlias()callback method, return the alias to your enterprise key so that the system automatically selects the certificate on behalf of the user.
By combining these new APIs, enterprises can securely identify devices and confirm their integrity before providing access:
- The Android device generates a new private key in the secure hardware. Because the private key never leaves the secure hardware, it remains secret.
- The device uses the key to create and send a certificate signing request (CSR) to the server. The CSR includes the attestation record containing the device IDs.
- The server validates the certificate chain (rooted to a Google certificate) and extracts the device metadata from the attestation record.
- The server confirms that the secure hardware protects the private key and that the device IDs match the enterprise's records. The server can also check that the Android system and patch versions meet any requirements.
- The server generates a certificate from the CSR and sends the certificate to the device.
- The device pairs the certificate with the private key (that's remained in the secure hardware) enabling apps to connect to enterprise services.
DPCs, running in device owner or profile owner modes, can block device users from setting trivial or commonly used passwords and PINs. Users who try to set a blocked password see a message that their IT admin has blocked common passwords and the system prompts the user to try a different password.
The DPC calls
DevicePolicyManager.setPasswordBlacklist() to set a
blacklist of disallowed passwords. A password blacklist is case insensitive and
can include up to 128k characters. Each list has a descriptive name to help
identify updated versions of the blacklist. Your DPC can check the name of the
current, active list by calling
To remove the password blacklist, pass
More security APIs, features, and changes
IDs for security logs and network logs
Android P now includes IDs in security and network activity logs. The numeric ID monotonically increases for each event, making it easier for IT admins to spot gaps in their logs. Because security logs and network logs are separate collections, the system maintains separate ID values.
ConnectEvent.getId() to get the ID value. The system
resets the ID whenever a DPC enables logging or when the device restarts.
Security logs fetched by calling
don't include these IDs.
Security logging now assigns each
SecurityEvent a log level. To get the log
getLogLevel(). This method returns a log level
value that can be one of:
||An attempt to install a new root certificate into the system's credential storage.|
||An attempt to remove a root certificate from the system's credential storage.|
||The system completed the cryptographic self test.|
||An admin app disabled features of a device or work profile lock screen.|
||An attempt to delete a cryptographic key.|
||An attempt to generate a new cryptographic key.|
||An attempt to import a new cryptographic key.|
||Security logging started recording.|
||Security logging stopped recording.|
||The security log buffer reached 90% of its capacity.|
||An admin app set the number of allowed incorrect-password attempts.|
||An admin app set a maximum screen-lock timeout.|
||The device mounted removable storage media.|
||The device unmounted removable storage media.|
||The Android system shut down.|
||The Android system started up.|
||An admin app set password complexity requirements.|
||An admin app set a password expiry duration.|
||An admin app set a password history length, preventing users from reusing old passwords.|
||An admin app locked the device or work profile.|
||An admin app set a user restriction.|
||An admin app removed a user restriction.|
||An attempt to wipe a device or work profile failed.|
Work profile lock screen challenge
Beginning in Android P, profile owners can require users to set a separate lock
screen challenge for their work profile using the
DISALLOW_UNIFIED_PASSWORD user restriction. To
check whether a user has the same lock screen challenge set for their device and
work profile, call
If a device has a separate work profile lock screen,
DevicePolicyManager.setMaximumTimeToLock() now only
sets a lock screen timeout for the work profile instead of for the entire
Developer tools access
To help keep work data in the work profile, the Android Debug Bridge (adb) tool can’t access directories and files in the work profile.
Deprecation of device admin policies
Android P marks the policies listed below as deprecated for DPCs using device admin. The policies continue to function in Android P as they have done previously. Starting with the Android Q release, the same policies will throw a SecurityException when invoked by a device admin.
Some applications use device admin for consumer device administration. For example, locking and wiping a lost device. The following policies will continue to be available to enable this:
For more information about these changes, read Device admin deprecation.
Streamlined QR-code enrollment
Built-in QR library
Android P comes bundled with a QR library to streamline QR-code device provisioning. IT admins no longer have to manually enter Wi-Fi details to set up a device. Instead, with Android P it's possible to include these Wi-Fi details within a QR code. When an IT admin scans the QR code with a company-owned device, the device automatically connects to Wi-Fi and enters the provisioning process without any additional manual input.
The QR-code provisioning method now supports the following provisioning extras to specify Wi-Fi details:
Set date and timezone using provisioning extras
The QR-code provisioning method now supports provisioning extras to set the time and timezone on a device:
Explanation for user removal
Device admins can show a personalized message to users when removing a work
profile or secondary user. The message helps device users understand that their
IT admin removed the work profile or secondary user. Call
wipeData(int, CharSequence) and supply a short explanatory
message. When called by the primary user or device owner, the system doesn't
show a message and begins a factory reset of the device.
New methods for affiliated profile owners
The following methods are now available to affiliated profile owners:
To learn about other changes that might affect your app, read Android P Behavior Changes.