Can supervised user download files?

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.

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

User types

Android device administration uses the following user types.

• Primary. First user added to a device. The primary 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.
• Secondary. Any user added to the device other than the primary user. Secondary users can be removed (either by themselves or by the primary user) and cannot impact other users on a device. These users can run in the background and continue to have network connectivity.
• Guest. 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.

Profile types

Android device administration uses the following profile types.

• Managed. 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 primary user and the corp profile.
• Restricted. Uses accounts based off the primary user, who can control what apps are available on the restricted profile. Available only on tablets and television devices.

Enabling multi-user

As of Android 5.0, 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 :

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

• with a value greater than
• with

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 class to restrict use.

Schools and 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 UserManager API 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.

By default, only the primary user has full access to phone calls and texts. The secondary user may receive inbound calls but cannot send or receive texts. The primary user must enable these functions for others.

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.
• The primary user can remove apps or even the entire workspace established by secondary users.

Android 7.0 includes several enhancements, including:

• Toggle work profile. Users can disable their managed profile (such as when not at work). This functionality is achieved by stopping the user; UserManagerService calls .
• Always-on VPN. VPN applications can now be set to always-on by the user, Device DPC, or Managed Profile DPC (applies only to Managed Profile applications). When enabled, applications cannot access the public network (access to network resources is stopped until the VPN has connected and connections can be routed over it). Devices that report must implement always-on VPN.

For more details on Android 7.0 device administration features, refer to Android for Work.

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

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.

1. To declare the device to be Automotive, add the feature .
2. Set to .
3. Set the value for to (or higher).

For more information, see Multi-User Support in Automotive.