A closer look at Ephemeral Users – new in Android P
Ephemeral users are a new feature of Android P designed to provide short-term user logins for shared Android enterprise devices owned by organizations, i.e. devices which fit the ‘Device Owner’ model such as warehouse picking, hospitality kiosks, package delivery scanning and many others.
The best documentation available for ephemeral users lists features at the DevicePolicyManager API level.
To see ephemeral users in action, we can use Android’s TestDPC along with either a physical device running the Android P beta or an emulator image. You will see some slight differences when comparing the two, for example the user setup wizard will only appear on a physical device, but for most purposes it is fine to use either.
Install TestDPC on Android P and set it to be the device owner – there are a number of ways to do this but I find the easiest is to use adb:
adb shell dpm set-device-owner "com.afwsamples.testdpc/.DeviceAdminReceiver"
I recommend you download the latest code from github since the version of the app posted to the Play Store does not seem to have been updated for the P beta (at the time of writing).
Creating users and logging in & out
TestDPC has been updated to accommodate ephemeral users – scroll down to the ‘User Management’ section and ensure the ‘Make user ephemeral’ checkbox is ticked when creating the managed user:
The following video shows creating an ephemeral user and switching to them without changing any other settings:
Some things to observe after switching to the ephemeral user:
This is a secondary user with its own profile, the profile is owned by the same application which created it (TestDPC). You can see this by running TestDPC from both the ephemeral user and the owner and observe the reported mode:
The device owner (TestDPC in this case) is controlling all the attributes of both the device and any managed users created on that device. In that respect, ephemeral users are no different from standard secondary users created by the device owner.
What makes ephemeral users unique is that they are short term – they are removed from the device when the user is stopped or logs out, when the user is switched or when the device reboots.
Let’s look at some customization you can give to the created ephemeral user.
All user restrictions which can be applied to secondary users also apply to ephemeral users and are listed in Android’s documentation as constants in the UserManager class. Also notice that there is a ‘Set user restrictions’ option in Test DPC that allows you to test many of these restrictions yourself
Of particular importance to ephemeral users is the ability to prevent user switching, if you do not want your ephemeral user to switch to another user (or back to the primary user / owner) mid shift then you should disallow user switching:
On the subject of logging out the ephemeral user, if the device is being used by shift workers who will log in as an ephemeral user for the duration of their shift, it makes sense to provide that worker with the ability to log out. Conversely, enterprise devices designed for public user sessions such as hospital or library check-in kiosks would probably want to log out automatically. To provide the greatest control an API is available to the device owner to control whether or not the user has the ability to log out.
When logout is enabled, a logout option will be presented to the user on the device’s lock screen titled “End Session”:
The logout setting can of course be controlled by TestDPC. The following video shows that disabling the logout setting will prevent the ‘End Session’ button from being shown on the lock screen but does not prevent the Profile Owner application (Test DPC) from logging the user out.
Note that logging out from the Profile Owner requires affiliation which is covered in more detail in the next section.
Installing packages for an ephemeral user
Obviously, the ephemeral user will need access to at least some applications to get their work done. Android treats system applications and user applications separately:
System applications like the Play Store, Google Drive, Chrome etc can be made available or unavailable to the ephemeral user. There are a couple of ways to do this:
- New to ‘P’, the LEAVE_AL_SYSTEM_APPS_ENABLED flag can be used when the ephemeral user is created. Test DPC exposes this as an option when you create the managed user:
- You can also enable system apps individually from the Profile Owner after the ephemeral user has been created, again TestDPC exposes this capability
- Even if you do not enable any system apps, you may notice that some are enabled by default (such as the phone dialer, contacts and messaging app in the emulator I am using. On my physical device the list is augmented by the Play Store) – this list will have been defined by the OEM at build time
Non-system apps (e.g. Line of business apps)
Non-system applications will be installed into the ephemeral user just like they would be for any other secondary user, for example the Play Store could be used to distribute applications. In enterprise use cases it is more likely that the managed Play Store would be used in conjunction with an EMM to provision applications into the ephemeral user.
Since the managed Play Store requires an EMM it cannot work with TestDPC but I can show the installExistingPackage API in action. There are a couple of pre-requisites:
Firstly, the ephemeral user must be affiliated with the device. This is easy enough to achieve with the TestDPC by assigning the same affiliation ID to both the primary user and ephemeral (secondary) user:
The application being installed to the ephemeral user has to be available to the device owner. Either the application is already installed in the primary user or was previously installed and the setKeepUninstalledPackages method has been invoked to retain uninstalled packages. The video shows installation of a test application into the ephemeral user which is currently installed to the primary user.
Locking down the device
I previously mentioned the user restrictions available which can be applied to an ephemeral user to prevent undesired actions such as taking screenshots, using the camera, preventing a reset or many, many others.
To only allow specific applications to run for the ephemeral user the Profile Owner can put the device into lock task mode. The demo video shows lock task mode being invoked by the Test DPC and allowing only the test application & TestDPC to run. Note that Android P introduced lock task features such as allowing the home button which is also demonstrated in the below video along with how non-whitelisted applications are still prevented from being run:
Note: at 26 seconds into the video the test app is started via adb, this simulates the app being invoked by a kiosk app or by the Profile Owner.
The Lock task features introduced in P are very flexible and address a number of shortcomings with Lock Task mode that were present between M and O. The features themselves probably warrant their own post for a closer look so I won’t go into more detail here.
Separate from lock task mode are the features exposed by DevicePolicyManager aimed at single-use devices. You can disable the status bar or control the keyguard. Controlling the keyguard can have an interesting effect as shown in the video below; disabling the keyguard prevents the logout button being shown to the user so be aware of that. The ‘Start kiosk mode’ option seen at the bottom of Test DPC’s ‘Single-use devices’ section will create a new activity to act as a kiosk for selected, allowed applications but is just an example implementation of lock task mode.
Putting it all together
In conclusion, ephemeral users offer a solution for customers using shared Android devices which are managed by a Device Owner and most typically, this Device Owner would be an EMM. The Device Owner application has full control to create and manage ephemeral users including locking down what that ephemeral user can do on the device, ranging from giving the user full control to only permitting them to access a single application without the status bar or home key.
In a real deployment, an ephemeral user would probably have a specific role. For example a manager would be presented with a different set of applications to a line worker and have elevated privileges on the devices. It is the responsibility of the Device Owner to correctly provision ephemeral users with the required features and applications as well as ensure the user logging into the device is allowed to do so (perhaps by integrating with an identity provider).
Because ephemeral users re-use so much of the existing primary / secondary user infrastructure already available on managed devices it is hoped the feature can be easily incorporated into EMMs supporting managed Android.