What’s in Android 9 for enterprise apps

This page provides an overview of the enterprise APIs, features, and behavior
changes that are available in the Android 9.

Work profile user interface

Android 9 (API level 28) includes user interface changes in the default
launcher to help users separate personal and work apps. Device manufacturers
supporting this can 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.

Figure 1. The default launcher's personal tab and work tab
with work profile switch

When provisioning work profiles and managed devices, Android 9 includes
animated illustrations to help device users understand these features.

Switch apps across profiles

Android 9 includes 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
CrossProfileApps class:

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

Lock down any app to a device

Starting in Android 9, device owners and profile owners (of secondary users)
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 9 also extends the lock task
APIs to profile owners of non-affiliated secondary users. Follow the steps below
to lock an app to the screen:

Enable system UI features

When lock task mode is enabled, device owners and profile 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 DevicePolicyManager.getLockTaskFeatures()
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
DISALLOW_SYSTEM_ERROR_DIALOGS user
restriction. This restriction affects all dialogs when applied by a device owner
but only the error dialogs shown in the primary or secondary user are suppressed
when the restriction is applied by profile owners. This restriction doesn't
affect work profiles.

In Android 9, apps running in immersive full-screen
mode don't show the reminder bubble when in
lock task mode. The reminder bubble is a panel shown to users (on first launch)
that explains how to exit the immersive mode.

Support multiple users on dedicated devices

Android 9 introduces the concept of an ephemeral user for dedicated
devices (previously 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:

Migrate DPCs

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 device admin policies XML resource to
indicate that this version of your DPC supports migration. A target DPC
indicates it can receive ownership by including a element named
<support-transfer-ownership>. The example below shows how you might do this in
your DPC's device admin XML file:

DPCs that want to migrate ownership to new DPC app can check if a target DPC's
version supports migration by calling the DeviceAdminInfo method
supportsTransferOwnership(). Before transferring
ownership, it's the source DPC's responsibility to verify the target DPC by
comparing app signatures. The PackageManager class includes
methods to work with code-sign signatures.

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
DevicePolicyManager.getTransferOwnershipBundle().

The steps to transfer ownership of a managed device or a work profile are the
same:

The source DPC checks that the target DPC's version supports migration and
confirms that the target DPC's app signature matches an expected value.

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
succeeded, call isAdminActive() to check that the source DPC
is no longer the active admin.

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:

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.

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

Hardware-secured keys and machine certificates

Android 9 adds 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
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
KeyChain. Call
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.

Prevent device users from misusing enterprise keys (in non-enterprise tasks)
by making the key certificates unselectable. 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. To make a key
unselectable, call the following DevicePolicyManager methods:

By combining these 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.

More security APIs, features, and changes

IDs for security logs and network logs

Android 9 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.

Deprecation of device admin policies

Android 9 marks the policies listed below as deprecated for DPCs using device
admin. The policies continue to function
in Android 9 as they have done previously. Starting with the Android Q release,
the same policies will throw a SecurityException when invoked by a device admin.

Streamlined QR-code enrollment

Built-in QR library

Android 9 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 9 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 supports the following provisioning extras to
specify Wi-Fi details:

Set date and timezone using provisioning extras

Wiping data options

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.

To remove subscription data from an embedded eUICC SIM, call
wipeData() and include WIPE_EUICC in the flags
argument.