What's new for Android in the enterprise

This page provides an overview of the new enterprise APIs, features, and
behavior changes introduced in Android Q.

Work profiles for company-owned devices

Android Q introduces new provisioning and attestation features for company-owned
devices that only require a work profile.

Improved provisioning tools for work profiles

It's now possible to provision work profiles on Android Q and later devices
enrolled using QR code
or Zero touch.
During the provisioning of a company-owned device, a new intent extra allows
device policy controller apps (DPCs) to initiate work profile or fully managed
setup. After a work profile is created or full management is established, DPCs
must launch policy compliance screens to enforce any initial policies.

Important: Existing DPC implementations that only support fully managed
provisioning won't be affected by this feature—they'll continue to work on
Android Q and later devices.

In your DPC’s manifest file, declare a new intent filter for
GET_PROVISIONING_MODE
in an activity and add the BIND_DEVICE_ADMIN
permission to prevent arbitrary apps from starting the activity. For example:

Note: To prevent failed provisioning, don't launch any activities or background
services after returning to setup.

After provisioning is complete, a new Intent is available for DPCs to launch
their compliance screens and enforce initial policy settings. On work profile
devices, compliance screens are displayed in the work profile. Your DPC must
ensure that its compliance screens are shown to users, even if a user escapes
the setup flow.

In your DPC's manifest file, declare a new intent filter for
ADMIN_POLICY_COMPLIANCE
in an activity and add the BIND_DEVICE_ADMIN
permission to prevent arbitrary apps from starting the activity. For example:

Fully managed devices return users to the homescreen. Work profile devices
prompt users to add their personal account before returning them to the home
screen.

Work-profile device-ID attestation

DPCs set as the admin of a work profile provisioned using zero-touch enrollment can now get secure-hardware-attested device IDs, such as an IMEI or manufacturer’s serial number. The device must include secure hardware (such as a trusted execution environment (TEE) or Secure Element (SE)) and support device-ID attestation and zero-touch enrollment.

When work profile calendars aren't available, queries return null. A
work profile calendar isn't available when an IT admin
blocks access or
when the work profile is turned off. A person using the device can also turn off
cross-profile calendars in Settings.

Apps running in the personal profile can show work events and redirect a person looking to edit a work event by navigating them to the same event in the work profile. When your app is installed in both the personal and work profiles, call
startViewCalendarEventInManagedProfile(). Apps that want to support cross-profile calendar events must handle the
ACTION_VIEW_MANAGED_PROFILE_CALENDAR_EVENT
action. Prepare your user interface to show an existing event with data from the following intent
extras:

If this method is not called or if it’s called with an empty set, then no apps
will be able to read work profile calendars. To grant read access to work
profile calendars to all apps, pass null. To ensure that only a specific set
of apps can read work profile calendars, pass the package names of those apps.

Work profile, device-wide unknown sources

Apps downloaded from sources other than Google Play (or other trusted app stores) are called apps from unknown sources. In Android Q, admins of work profiles can now prevent any user or profile from installing apps from unknown sources anywhere on the device by adding the new user restriction
DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY.
After adding this restriction, however, a person using the device can still install apps using
adb.

To prevent users from mistakenly installing apps from unknown sources, we
recommend adding this user restriction because it doesn't require Google Play
services to be installed. If you want to support older Android versions, you can
set a managed configuration value for Google Play.

Limit permitted input devices to work profiles

When admins of work profiles call DevicePolicyManager.setPermittedInputMethods(), users are only restricted to the permitted input methods inside their work profile instead of the entire device, giving users full control over input methods on the personal side of their device.

Silently wipe work profiles

New features for fully managed devices

Android Q introduces new features and APIs for fully managed devices, including
manual system updates, extending QR-code and NFC provisioning to include the
credentials for an EAP Wi-Fi network, and support for DNS over TLS.

Manual system update installation

In Android Q, admins of fully managed devices can install system updates via a
system update file. Manual system updates allow IT admins to do the following:

Test an update on a small number of devices before installing them widely.

Avoid duplicate downloads on bandwidth-limited networks.

Stagger installations, or update devices only when they're not being used.

After the device restarts, your DPC needs to confirm a successful installation
using a version API, such as
Build.FINGERPRINT. If the update
fails, report the failure to an IT admin.

EAP Wi-Fi provisioning

In Android Q, QR codes and NFC data used for device provisioning can now contain
EAP config and credentials—including certificates. When a person scans a QR code
or taps an NFC tag, the device automatically authenticates to a local Wi-Fi
network using EAP and starts the provisioning process without any additional
manual input.

To authenticate Wi-Fi using EAP, add an
EXTRA_PROVISIONING_WIFI_SECURITY_TYPE
extra with the value "EAP". To specify the EAP authentication, you can add the
following provisioning extras to your intent:

Private DNS support

Organizations can use DNS over TLS
(called Private DNS on Android devices) to avoid leaking DNS queries,
including those of internal hostnames. Admin components of fully managed devices
can control the Private DNS settings of the device. To set the Private DNS mode,
call:

VPN lockdown mode exemption

VPN lockdown mode allows a DPC to block any network
traffic that doesn't use
the VPN. Admins of fully
managed devices and work profiles can now exempt apps from lockdown mode.
Exempted apps use a VPN by default, but automatically connect to other
networks if the VPN isn't available. Exempted apps that are also explicitly
denied access the
VPN
will only use other networks.

To exempt an app from lockdown mode, call the new
DevicePolicyManager method
setAlwaysOnVpnPackage()
that now accepts a list of exempted app packages. Any app packages the DPC adds
must be installed on the device when the method is called. If an app is
uninstalled and reinstalled, the app must be exempted again. To get the apps
previously exempted from lockdown mode, call
getAlwaysOnVpnLockdownWhitelist().

New delegation scopes

Android Q extends the list of functions that a DPC can delegate to other, more
specialized apps. Android groups the API methods needed for a task into
scopes. To delegate a scope, call
setDelegatedScopes()
and pass one or more of the following scopes:

Android Q introduces the new class
DelegatedAdminReceiver
for delegate apps. The system uses this broadcast receiver to send DPC-like
callbacks to delegate apps. Apps that have been delegated network activity
logging and certificate selection should implement this class. To add this
component to a delegate app, follow these steps:

To avoid losing logs, DPC's shouldn't enable network logging
if planning to delegate to another app. The delegate app should enable and
collect network logs. After a DPC delegates network logging, it won't receive
any further onNetworkLogsAvailable()
callbacks.

To learn how to report network activity logging from a delegate app, read the
developer's guide Network activity logging.

Certificate selection

In Android Q, admins of
fully managed devices, work profiles, and secondary users can delegate
certificate selection to a specialized app.

To select a certificate alias, delegate apps should first subclass
DelegatedAdminReceiver
(described previously). In your subclass, implement the
onChoosePrivateKeyAlias() callback and return an alias for a preferred certificate or,
to prompt the user to select a certificate, return null.

Deprecation of device admin policies

Android Q prevents DPCs from applying legacy device
admin policies. We recommend customers
and partners transition to fully managed devices or work profiles. The following
policies throw a SecurityException
when invoked by a device admin targeting Android Q:

New features for apps

Apps targeting Android Q can query the screen lock complexity set on a device
before displaying confidential data or launching critical features. Apps calling
the KeyChain API benefit from
behavior improvements, while new features are also available for VPN apps.

Screen lock quality check

Starting in Android Q, apps with critical features that require a screen lock
can query a device or work profile’s screen lock complexity. Apps needing a
stronger screen lock can direct the user to the system screen lock settings,
allowing them to update their security settings.

To check screen lock quality:

Add the new REQUEST_PASSWORD_COMPLEXITY permission to your
app's manifest.

To launch system screen lock settings, use
ACTION_SET_NEW_PASSWORD
with extra EXTRA_PASSWORD_COMPLEXITY—options that don't
meet the complexity specified in the intent extra are grayed out. Users can
choose from the available screen lock options or exit the screen.

Best practice: Display a message in your app before launching the system
screen lock page. When your app resumes, call
DevicePolicyManager.getPasswordComplexity()
again. If a stronger screen lock is still required, restrict access rather than
repeatedly prompting users to update their security settings.

HTTP proxy support in VPN apps

In Android Q, VPN apps can set an HTTP proxy
for their VPN connection. To add an HTTP proxy, a VPN app must configure a
ProxyInfo instance with a host and port,
before calling
VpnService.Builder.setHttpProxy().
The system and many networking libraries use this
proxy setting but the system doesn't force apps to proxy HTTP requests.

For sample code that shows how to set an HTTP proxy, see the
ToyVPN
sample app.

VPN service modes

VPN apps can now discover if the service is running because of always-on
Vpn and if lockdown
mode is active. New methods
added in Android Q can help you adjust your user interface. For example, you
might disable your disconnect button when always-on VPN controls the lifecycle
of your service.

The always-on status remains the same while your service is running but the
lockdown-mode status might change.

Keychain improvements

Android Q introduces several improvements related to the
KeyChain API.

When an app calls KeyChain.choosePrivateKeyAlias(), devices now
filter the list of certificates a user can choose from based on the issuers and
key algorithms specified in the call.

For example, when a TLS server sends a Certificate Request
message as part of a TLS handshake and the browser calls
KeyChain.choosePrivateKeyAlias(), the certificate selection prompt now only
includes options that match the issuers parameter. If no matching options are
available or there are no certificates installed on the device, then the
selection prompt won’t be displayed to the user.

Additionally, KeyChain no longer
requires a device to have a screen lock before keys or CA certificates can be
imported.

Learn more

To learn about other changes that might affect your app, read the
Android Q behavior changes pages (for
apps targeting Q and for
all apps).

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.