Android enterprise includes many new features and APIs, as well as some behavior changes, that apply to devices running Android O.
New APIs and features
We've made the profile owner and device owner management modes more powerful, productive, and easier to provision than ever before. We've also enabled a whole new deployment scenario. These and other features are described in the following sections.
Work profiles on fully managed devices
In Android O, fully managed devices can also have work profiles. This gives enterprises the ability to separate apps and policies while maintaining control and visibility across both profiles. The existing device owner, or a different device policy controller (DPC), can create the managed profile.
During provisioning, a device owner's DPC can use
to copy an account from a personal profile to a work profile without removing
the account from the personal profile. Device owners can create a managed
profile without user interaction by calling
Device owners can prevent other DPCs from creating managed profiles using
DISALLOW_ADD_MANAGED_PROFILE. This setting is the
default in Android O for device owners on newly provisioned devices or devices
upgraded to Android O. Device owners can also prevent users from removing
existing managed profiles using
Device owners and profile owners can communicate with each other if they're from
the same APK and the owners are affiliated (see User
affiliation below). Before a device owner or a profile owner
can communicate with each other, they first need to bind to the target service
as a target user. To call services across profile boundaries, bind using
Note: Device owners and profile owners can use
to retrieve a list of users that they can bind to.
When a device owner and a profile owner represent the same organization:
- The device and profile owners can communicate with each other within the same APK—they might want to share policies or status (see Work profiles on fully managed devices above).
- Device-wide features, such as logging or whitelisting lock task mode, can apply to affiliated users.
Affiliation IDs, attached to a profile or user, identify organizations. When
affiliation IDs match, the users become affiliated. Device owners and profile
to set their affiliation IDs. Organizations should choose long, difficult to
guess, strings as IDs.
New access for affiliated users
If all the secondary users and profiles on a device are affiliated with the device owner then the following features are now available:
- Security logging using
- Network activity logging using
- Bug reporting using
Security logging and bug reporting were previously only available to single-user devices, or devices with only one profile and one user.
Lock task mode is available to secondary users and managed profiles when
affiliated with the device owner. For more information on using this mode, see
the reference documentation for
Customized provisioning disclaimers
DPCs can now show their own disclaimers to users during provisioning. Use
to supply styled text disclaimers. A DPC's custom disclaimers appear in the
collapsible Terms list.
Profile owners and device owners can use
to configure a timeout period for unlocking a device or a profile with a
secondary authentication method, such as fingerprints or trust agents. After the
timeout period expires, the user must unlock the device or profile using a
strong authentication method, such as a password, PIN, or pattern.
Device owners and profile owners can securely reset device and work profile
For devices that support
this API is available before a user unlocks their device or profile, provided
the DPC is encryption-aware.
When locking a work profile on a device that supports file-based encryption,
optionally evict the work profile's master encryption keys using the
flag. The encryption keys are also evicted if the user turns their work profile
Also, device owners can use
to turn on network logging of DNS queries and TCP connections initiated from
corporate-owned devices. When network logging is enabled, the DPC receives
batched network events from
To retrieve the logs, the DPC should call
Finally, profile owners and device owners can retrieve information about the
pending system updates that are available on a device using
App management API delegation
API delegation enables device owners and profile owners to fully offload app
management to other applications. The
DevicePolicyManager class provides methods to manage
the delegation scopes that device and profile owners can grant to a package:
setDelegatedScopes()method allows device owners and profile owners to grant access to privileged APIs to other apps.
getDelegatedScopes()method returns the scopes granted to a package.
getDelegatePackages()returns the packages that have a scope.
The following table shows how various methods in
DevicePolicyManager are organized into the different
Long-running background services
Device and profile owners can subclass
DeviceAdminService to create background services. The
Android system attempts to keep the service running while the user is running.
If you want to run periodic tasks, consider using
JobScheduler before creating a background service.
Controlling the backup service
Device owners can toggle the Android Backup Service
using new methods in
DevicePolicyManager. Enable and
disable the backup service using
Check the backup service status using
Wi-Fi proxy configuration
Device owners and profile owners can configure HTTP proxy servers for Wi-Fi
networks. Use a PAC file or manual settings to configure a proxy server for each
Wi-Fi network. To set or remove the proxy for a
WifiConfiguration, call its
method. To get the proxy settings call
Explanation dialogs for admin-disabled features
Your app should show a useful explanation to users trying to use an
admin-disabled feature. All apps can now use
to create an intent that displays an explanation dialog when passed to
Intents include customized, localized explanations for disabled cameras,
disabled screen captures, and all the
Device owners can disable Bluetooth—affecting all users and profiles on the
device. To turn off Bluetooth, add the user restriction
If you're building apps for businesses, including DPCs, you should review the following behavior changes in Android O and modify your app accordingly.
The following changes have taken effect in the
lockNow()method only locks the work profile if a separate work challenge is active.
resetPassword()method is no longer available to DPCs that act as device owners or profile owners and target Android O. If called, a security exception is thrown. Instead, DPCs should use
Note: DPCs targeting Android 7.1.1 (API level 25) or lower, as well as DPCs with only device admin privileges, aren't affected by this change.
- For devices that support file-based encryption,
isActivePasswordSufficient()isn't available before the user unlocks the device for the first time after a reboot. If called before the user unlocks the device, an exception is thrown.
Data from locked work profiles
Android O includes user interface changes to separate data from a locked work profile.
- Notifications for apps in the work profile might now hide their content. Previously, the notification drawer showed the content for work apps from a locked work profile.
- The Recents screen now shows a plain panel for running apps from a locked work profile. The plain, color-keyed panel contains an app's icon and name. Previously, activities or tasks from a locked work profile showed a preview in the Recents screen.
ENSURE_VERIFY_APPSflag is now a global user restriction. If any user on the device has this restriction, app verification is enforced across all users on the device. For example, if a profile owner sets the restriction on the work profile, app verification will also be enforced on the user's personal profile.
onSystemUpdatePending()method is now invoked for profile owners in addition to device owners.
- When using the
SystemUpdatePolicyclass, the postpone policy no longer applies to security patches, so security patches can no longer be postponed. The behavior of other policy types, such as automatic and windowed, aren't affected, however.
- Device owners can trigger a factory reset using
wipeData(), even if
Android O includes user interface changes to help users understand the status of always-on VPN connections:
- When always-on VPN connections disconnect or can't connect, users see a non-dismissible notification. Tapping the notification shows the VPN configuration settings. The notification disappears when the VPN reconnects or the user turns off the always-on VPN option.
- Before users enable always-on VPN, Settings now warns the user that they won't have an Internet connection until the VPN connects. Settings prompts the user to continue or cancel.
VpnService of VPN apps must now call its
method after launch. Because the Android system starts a VPN app's service
directly, transitioning to the foreground is the app's responsibility. Android O
shuts down VPN apps that don't transition the VPN service to the foreground.
The password change callbacks of
now include a
user parameter to identify the user or profile the password
belongs to. The new method signatures are:
onPasswordChanged(Context, Intent, UserHandle)
onPasswordExpiring(Context, Intent, UserHandle)
onPasswordFailed(Context, Intent, UserHandle)
onPasswordSucceeded(Context, Intent, UserHandle)
The default implementation of each new method calls the previous version—dropping the user argument. Android O deprecates the previous methods.
App management API delegation
The following methods in the
are now deprecated:
Also, it's now possible to delegate a single scope to multiple packages. In other words, device owners and profile owners can grant two different packages access to the same set of APIs simultaneously.