Android supports multiple users on a single Android device by separating user accounts and application data. For instance, parents may 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.
Android uses the following terms when describing Android users and accounts.
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 application 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 a Device Administration application.
- 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 the Account 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 a Device Administration application. 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 application’s data exists within each associated user. App data is sandboxed from other applications 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 application 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.
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 in
and currently include:
OEMs have the ability to configure these user types by overlaying the
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 the
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.
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
<!-- Maximum number of supported users --> <integer name="config_multiuserMaximumUsers">1</integer> <!-- Whether Multiuser UI should be shown --> <bool name="config_enableMultiUserUI">false</bool>
To apply this overlay and enable guest and secondary users on the device, use
DEVICE_PACKAGE_OVERLAYS feature of the Android build system to replace
the values for:
config_multiuserMaximumUserswith a value greater than
Device manufacturers may 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 the Android Compatibility Definition Document (CDD).
Managing multiple users
Management of users and profiles (with the exception of restricted profiles)
is performed by applications that programmatically invoke API in the
DevicePolicyManager class to restrict use.
Enterprises may employ users and profiles to manage the lifetime and scope of apps and data on devices, using the types outlined above in conjunction with the DevicePolicyManager and UserManager APIs 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 will 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
false. For further information on creating overlay files, refer to Customizing 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 as
Secondary Users, described above, except that secondary
- 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.
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.
Enabling 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:
- To declare the device to be Automotive, add the feature
- Set the value for
For more information, see Multi-User Support in Automotive.
Android Automotive multi-user on multiple displays
A new experimental feature in Android 14 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 for development use, device manufacturers must define a resource overlay
to replace the following value in
<!-- Whether the device allows users to start in background visible on displays. Should be false for all devices in production. Can be enabled only for development use in automotive vehicles with passenger displays. --> <bool name="config_multiuserVisibleBackgroundUsers">false></bool>
You can experiment with a passenger-only (no driver) experience by enabling the following additional config:
<!-- Whether the device allows users to start in background visible on the default display. Should be false for all devices in production. Can be enabled only for development use in passenger-only automotive build (i.e., when Android runs in a separate system in the back seat to manage the passenger displays). When set to true, config_multiuserVisibleBackgroundUsers must also be true. --> <bool name="config_multiuserVisibleBackgroundUsersOnDefaultDisplay">false</bool>
In Android 14, you can 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
frameworks/base/core/res/res/xml/config_user_types.xml, like the
<user-types> <full-type name="android.os.usertype.full.GUEST" max-allowed='4'> <default-restrictions no_factory_reset="true" no_remove_user="true" no_modify_accounts="true" no_install_apps="true" no_install_unknown_sources="true" no_uninstall_apps="true"/> </full-type> </user-types>