A user is a representation of a person using a device, with their own distinct application data and some unique settings. Throughout this document, the word ‘user’ will be used in this technical sense, i.e. for this virtual environment, whereas the word ‘person’ will be used to denote an actual human interacting with the device.
Each user has a separate userId.
Often, there is a 1-to-1 mapping of people who use a device to ‘users’; e.g. there may be two users on a device - the owner and a guest, each with their own separate home screen.
However, Android also supports multiple profiles for a single person, e.g. one for their private life and one for work, both sharing a single home screen. Each profile in a profile group is a distinct user, with a unique userId, and have a different set of apps and accounts, but they share a single UI, single launcher, and single wallpaper. All profiles of a profile group can be active at the same time.
You can list the profiles of a user via UserManager#getEnabledProfiles (you usually don't deal with disabled profiles)
The main user of a profile group, to which the other profiles of the group ‘belong’. This is usually the personal (as opposed to work) profile. Get this via UserManager#getProfileParent (returns null if the user does not have profiles).
A profile of the parent user, i.e. a profile belonging to the same profile group as a parent user, with whom they share a single home screen. Currently, the only type of profile supported in AOSP is a ‘Managed Profile’. The name comes from the fact that these profiles are usually managed by a device policy controller app. You can create a managed profile from within the device policy controller app on your phone.
Note that, as a member of the profile group, the parent user may sometimes also be considered a ‘profile’, but generally speaking, the word ‘profile’ denotes a user that is subordinate to a parent.
Only a single user can be in the foreground. This is the user with whom the person using the device is currently interacting, or, in the case of profiles, the parent profile of this user. All other running users are background users. Some users may not be running at all, neither in the foreground nor the background.
An account of a user with a (usually internet based) service. E.g. aname@gmail.com or aname@yahoo.com. Each user can have multiple accounts. A user does not have to have a account.
The user with userId 0 denotes the system user, which is always required to be running.
On most devices, the system user is also used by the primary person using the device; however, on certain types of devices, the system user may be a stand-alone user, not intended for direct human interaction.
The id of a user. List all users via adb shell dumpsys user. In code, these are sometimes marked as @UserIdInt.
Identity of an app. This is the same as a Linux uid, but in Android there is one uid per package, per user.
It is highly discouraged, but uids can be shared between multiple packages using the android:sharedUserId manifest attribute.
A wrapper for userId. Used esp. in public APIs instead of int userId as it clearly distinguishes from uid.
Multiple packages can share an uid by using android:sharedUserId manifest attribute. If packages share a uid they can run in the same process via android:process manifest attribute. Further file level access is also tracked by uid. Hence any security or privacy mechanism needs to be built on a uid granularity.
On the other hand apps belonging to the same user cannot see each others files. They can only interact via activity launches, broadcasts, providers, and service bindings. All of them can be be protected by permissions. Hence any new general communication mechanism should be access controlled by permissions.
A system service should deal with users being started and stopped by overriding SystemService.onSwitchUser and SystemService.onStopUser.
If a user become inactive the system should stop all apps of this user from interacting with other apps or the system.
Another important lifecycle event is onUnlockUser. Only for an unlocked user can you access all data, e.g. which packages are installed.
You only want to deal with user profiles that