Support multiple users (original) (raw)

Android supports multiple users on a single Android device by separating user accounts and app data. For instance, parents might allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty.

Terminology

Android uses the following terms when describing Android users and accounts.

General

Android device management uses the following general terms:

• User: Each user is intended to be used by a different physical person. Each user has distinct app data and some unique settings, as well as a user interface to explicitly switch between users. A user can run in the background when another user is active; the system manages shutting down users to conserve resources when appropriate. Secondary users can be created either directly via the user interface or from aDevice Administration app.
• Account: Accounts are contained within a user but are not defined by a user, nor is a user defined by or linked to any given account. Users and profiles contain their own unique accounts but are not required to have accounts to be functional. The list of accounts differs by user. For details, refer to theAccount class definition.
• Profile: A profile has separated app data but shares some system-wide settings (for example, Wi-Fi and Bluetooth). A profile is a subset of, and tied to, the existence of a user. A user can have multiple profiles. Profiles are created through aDevice Administration app. A profile always has an immutable association to a parent user, defined by the user that created the profile. Profiles do not exist beyond the lifetime of the creating user.
• App: An app's data exists within each associated user. App data is sandboxed from other apps within the same user. Apps within the same user can interact with each other via IPC. For details, refer to Android for enterprise.

Categories of users

Android device administration uses the following categories of users.

• System user: First user added to a device. The system user cannot be removed except by factory reset and is always running even when other users are in the foreground. This user also has special privileges and settings only it can set.
• Headless system user: First user added to a device if the device is configured to run in headless system user mode (by setting ro.fw.mu.headless_system_user=true). The headless system user always runs in the background, so such devices require additional foreground users to enable user interaction.
• Secondary user: Any user added to the device other than the system user. Secondary users can be removed (either by themselves or by an admin user) and cannot impact other users on a device. These users can run in the background and continue to have network connectivity.
• Guest user: Temporary secondary user. Guest users have an explicit option to quickly delete the guest user when its usefulness is over. There can be only one guest user at a time.
• Admin user: A user who has the permission to create and remove other users, as well as control some general multi-user settings. By default, only the system user is an admin.

Categories of profiles

Android uses the following categories of profiles:

• Managed profile: Created by an app to contain work data and apps. They are managed exclusively by the profile owner (the app that created the corp profile). Launcher, notifications, and recent tasks are shared by the parent user and the corp profile.
• Restricted profile: Uses accounts based off the parent user, who can control what apps are available on the restricted profile. Available only on tablets and television devices.
• Clone profile: Android supports the creation of a separate clone profile user type to enable running two instances of a single app on the device. AOSP doesn't provide end-to-end support for the feature. OEMs need to add customizations to deliver the complete feature to Android users.
• Private profile: It is a sandboxed space separate from rest of the device, that can be locked separately from the main user. A private profile can exist only for the main user. When the private profile is unlocked, the apps become visible in settings, ShareSheet, Photopicker, and DocsUI but the apps are hidden when locked. The private profile can exist on the same device along with work profile and clone profile.

User types

Android 11 has formulated the above classification of users and profiles into well-defined_user types_, representing all the different types of users and profiles allowed by the Android Multi-user feature.

The pre-defined AOSP user types are defined inframeworks/base/core/java/android/os/UserManager.javaand currently include:

• android.os.usertype.full.SYSTEM
• android.os.usertype.full.SECONDARY
• android.os.usertype.full.GUEST
• android.os.usertype.full.DEMO
• android.os.usertype.full.RESTRICTED
• android.os.usertype.profile.MANAGED
• android.os.usertype.system.HEADLESS
• android.os.usertype.profile.CLONE
• android.os.usertype.profile.PRIVATE

OEMs have the ability to configure these user types by overlaying theframeworks/base/core/res/res/xml/config_user_types.xml file. This facilitates changing the default configuration for each user type, including its default restrictions, icons, badges, and the maximum allowed number of users.

In addition to the configurable AOSP user types, OEMs can define new profile types using theframeworks/base/core/res/res/xml/config_user_types.xml file. This allows OEMs to introduce their own non-managed profile types if desired. However, it is the OEM's responsibility to make platform modifications as required to support the changes, including modifying any code that checks for managed profiles to now handle the new profile type if appropriate.

Enable the multi-user feature

The multi-user feature is disabled by default. To enable the feature, device manufacturers must define a resource overlay that replaces the following values in frameworks/base/core/res/res/values/config.xml:

1

false

To apply this overlay and enable guest and secondary users on the device, use the DEVICE_PACKAGE_OVERLAYS feature of the Android build system to replace the values for:

• config_multiuserMaximumUsers with a value greater than 1
• config_enableMultiUserUI with true

Device manufacturers can decide upon the maximum number of users. If device manufacturers or others have modified settings, they must ensure SMS and telephony work as defined in theAndroid Compatibility Definition Document (CDD).

Manage multiple users

Management of users and profiles (with the exception of restricted profiles) is performed by apps that programmatically invoke API in theDevicePolicyManager class to restrict use.

Enterprises can employ users and profiles to manage the lifetime and scope of apps and data on devices, using the types outlined above in conjunction with theDevicePolicyManagerand UserManagerAPIs to build unique solutions tailored to their use cases.

Multi-user system behavior

When users are added to a device, some functionality is curtailed when another user is in the foreground. Since app data is separated by user, the state of those apps differs by user. For example, email destined for an account of a user not currently in focus won't be available until that user and account are active on the device.

Note: To enable or disable the phone and SMS functions for a secondary user, go to Settings > Users, select the user, and switch the Allow phone calls and SMS setting to off.

Some restrictions exist when a secondary user is in background. For instance, the background secondary user cannot display the user interface or make Bluetooth services active. In addition, the system process halt background secondary users if the device needs additional memory for operations in the foreground user.

When employing multiple users on an Android device, keep the following behavior in mind:

• Notifications appear for all accounts of a single user at once.
• Notifications for other users do not appear until active.
• Each user gets a workspace to install and place apps.
• No user has access to the app data of another user.
• Any user can affect the installed apps for all users.
• An admin user can remove apps or even the entire workspace established by secondary users.
• By default, information from a Guest user session doesn't persist when exiting Guest mode. If you want information from a Guest user session to persist, you must create a resource overlay file that sets the config_guestUserAllowEphemeralStateChange tofalse. For further information on creating overlay files, refer toCustomize the build with resource overlays.

Android Automotive multi-user

Android Automotive relies on Android's multi-user implementation to provide a shared device experience.

Automotive user types

In addition to the user types listed above, Automotive builds are notable for these types of users:

• Headless system user. The system user hosts all system services. To support multiple users on Automotive, the system user must also be headless. There is only one headless user. A headless system user:
  • Must always run in the background.
  • Cannot be removed or accessed directly by the user except in the case of Device Provisioning. For example, users cannot switch to this User type to perform tasks such as download apps or add accounts.
  • Can only be cleared by a factory reset.
• Regular users. The same asSecondary Users, described above, except that secondary users:
  • Do not run in the background (after having been switched away from).
  • Can be created directly through the user interface.
  • Have separated app data but share some system-wide settings. For example, Wi-Fi and Bluetooth.

Caveats

The following exceptions apply to headless system user and regular (secondary) Users in Automotive:

• The headless system user does not support work profiles.
• By default, regular (secondary) users have full access to phone calls and texts.
• By default, regular (secondary) users do not run in the background.

Enable the headless system user

As of Android 10, the multi-user feature can be used for automotive use cases. Important distinctions include:

• The system user is headless and runs only in the background.
• Human users do not interact with the system user.

To enable the headless system user, device manufacturers must enable multi-user as described above.

When the headless user is enabled:

1. To declare the device to be Automotive, add the featureandroid.hardware.type.automotive.
2. Set ro.fw.headless_system_user to true.
3. Set the value for config_multiuserMaximumUsers to 2 (or higher).

For more information, seeMulti-User Supportin Automotive.

Android Automotive multi-user on multiple displays

Android 15 allows full secondary users (who are not the current foreground user) to launch activities and get access to the UI on the display to which they are assigned. This feature enables multiple concurrent users in Android Automotive OS to support in-car experiences that provide multiple passengers with a dedicated UI experience in a single Android instance.

To enable this feature, device manufacturers must define a resource overlay to replace the following value inframeworks/base/core/res/res/values/config.xml:

false>

You can experiment with a passenger-only (no driver) experience by enabling the following additional config:

false

In Android 15, you can also enable the in-car experience for multiple passengers as guest users. To enable multiple guest users for development use, device manufacturers must define a resource overlay that configures max allowed number of guest users in frameworks/base/core/res/res/xml/config_user_types.xml, such as in this example: