Android P Developer Preview One has been released this week. Among many features, there are Enterprise enhancements in both UI/UX as well as under the hood. Seems to be a good time to try some of them out!
Today we will be discussing the BYOD user experience: device enrollment, work/personal separation, compliance etc. Later, I am planning to cover the COBO/COSU (fully Work-Managed device) use case as well as some more advanced features.
Warning, many pictures!
Demo environment setup
The P Developer Preview is available for Pixel2/XL phones. I don’t have any, so I’m using an emulator. Android Studio already has P available, and using the Nexus 5X target one can even get Play Store integration (which we need for BYOD)!
For the EMM console I will be using Google’s own Android Management Experience. I was pleasantly surprised how easy was it to get the AMX up and running, and will probably cover it in a separate blog – it is an excellent tool for quick demos! All you need is a gmail account, essentially, and you can demo all the core Android Enterprise scenarios: Work-Profile, Work-Managed, Compliance, Managed Play Store, Managed Configuration for apps etc.
Here are my emulators and my AMX Console. Let’s kick it off!
AMX Device Enrollment is extremely straightforward, and allows for both BYOD and Work-Managed scenarios. You will also see this screen after first-time setup of AMX.
Once the app is installed, scan the QR code or enter the code manually and the Work Profile will be set up shortly. There are two things I liked about the process:
- Many user-friendly explanations of what’s going in
- Everything happens in the background (profile, mandatory app installation etc)
Here’s my first attempt at animated sequence capturing the process.
After the installation, check out the new launcher experience. Previously the Work and Personal apps were all mixed together, distinguished only by by the briefcase badges. This sometimes created confusion, as there could have been two versions of the same app (say Work Chrome and Personal Chrome) place on different screens.
This time the experience is much cleaner. Also check out the option to disable to Work Profile from the launcher or the notification shade. This feature is also available programmatically, and is called Quiet Mode in the SDK, so you get where this is going… Interestingly, the current “Do not Disturb” mode configuration does not include a Work Profile toggle. Maybe, in a later developer release?
Note that now there are two versions of Android Device Policy App – one Personal (allows to re-enroll the device, and one Work – shows all the interesting data about the device.
Finally, let’s take a look at the device settings. Note the following:
- The prominent place the Google Play Protect takes in the Settings -> Security
- A section clearly named “Work Profile Security“
- Badges on certain Device Administrators, and a second (Work) version of Find my Device
- User-friendly way of removing the Work Profile w/o wiping the entire device.
None of these are actually new in P (as far as I know), but good to remind or demo to the customer.
Now, let’s check out what happens if the device is not compliant. In the AMX console Policies page I have enabled the Screen Lock (which was not previously required).
Here’s the full list of policies, BTW. It’s not much but allows for demonstrating the most important features.
And here’s what happened on the device in about 10 seconds:
- All my enterprise apps expect for the Device Policy itself and the [Managed] Play Store were gone
- There was a notification of policy compliance violation
- There was a meaningful screen showing what is non-compliant, what are the repercussions, and what needs to be done
Tapping on the Set Screen Lock and setting the lock makes the device compliant again. It look another 10 seconds or so for the policy to be reprocessed. Note that I cannot disable the screen lock, but there is an info icon, which shows me why, and how I can get rid of it (removing the Work Profile).
Personal vs Managed Apps – Play Store
Finally, let’s take a look at Personal vs Managed apps.
First, you have two versions of Play Store – Personal, where you can install all you like, and Managed, where you can only see the apps approved by your admin. These apps can be approved via a special Managed Play Store Console, or via any modern EMM that has Managed Play Store integration. Here’s how it looks in the AMX Console and on the device.
Personal vs Managed Apps – Managed Configurations
Have you noticed the cog symbols available next to some apps in the AMX Console? It means that the apps supports Managed Configuration – essentially, this means that you can push certain app parameters via EMM. For instance, GMail allows you to pre-specify the email address, server and certificate parameters etc, while Chrome provides 10 screens of options, including controls for history, search providers, autofill, incognito mode, certificates and much more. These pages are huge, so click the links above to see the details.
The Managed Configuration (previously known as App Restrictions) is a great way to provide both Admin/Security controls AND user convenience. For instance, integrated with proper EMM solution this may give your users a complete out-of-box experience: enroll your device, and your apps come pre-configured and potentially even with single sign on!
It only gets better if you use a Work-Managed device that supports Zero-Touch Enrollment (such as any Android Enterprise Recommended device) – all you need to do is to unbox the device and turn it on. Respect and regards to Apple, who had implemented it years ago! 🙂
Of course, in order for Managed Configurations to work, the app developers have to support them. Fortunately, the majority of enterprise app developers are already familiar with this technique (as is was the only way to configure apps on Apple platform). But if not – point them here and here.
Personal vs Managed Apps – User Experience
Here are some screens of managed Chrome, where I pushed a policy to disable the Incognito mode. Also note the following:
- How Android makes distinction between Personal and Work apps in the Recents Screen, and how “Work” is only sometimes added to the window title.
- How a little briefcase icon shows in the top right corner (next to mobile network and battery indicators) when you are in a work app. I honestly wish there was a better way to determine this, since sometimes it is quite confusing to understand whether you’re in a personal or work instance of the app!
In order to somewhat smoothen the last aspect, Android P introduces a set of APIs for apps to switch between Personal and Work profile right within the app itself. I haven’t yet found any apps in the P Developer Preview that support this option, though. Once I find anything, I’ll post an example.
Other important features
One of the most important concerns, when Personal and Work profiles co-exist on the device, is the data leaks. Android pre-P versions have already taken a great deal to control this:
- First of all, data and app separation, including sandboxing and encryption
- Additionally, admins can control whether Copy-Paste may work between profiles (and this is something you can demo using AMX)
- Admins may control (via EMM) which intents are (or are not) allowed to be sent across the profile border to prevent additional leaks (“Share to” etc).
- Similar feature exists for widgets.
Android P adds a new feature, which prevents sharing data INTO the Work Profile. This may prevent some attacks, where the malicious data or code can be injected into the Work Profile via an Intent. Or just make things cleaner – your choice 🙂
Another common issue is using simple or generic passwords. In Android P there is now a way to provide a custom password blacklist (or more than one). Given that minimal reliable password strength lies somewhere around 20+ chars, one can imagine how the users will accept this “innovation”. Fortunately, Android P also introduces a system-standard Fingerprint Reader Auth implementation, which means there is now no excuse not to support the fingerprint authentication in all the apps. Basically, I would not buy a device without a fingerprint reader for Enterprise anymore. But that’s me, my password is 26+ 🙂
You have now been through a brief demo of how BYOD user experience looks like with Android Enterprise in Android P Developer Preview. It is extremely easy to set up and replicate using a Pixel2/XL (or Android Emulator) and Android Managed Experience, and makes a good customer demo.
Not all the features shown were new for Android P, and not all the Android P features were shown. Some (like profile switching) require a properly written app, others (like lockdown) are not for BYOD. I’ll cover those features separately.
The full list of Android Enterprise changes in P can be found here. I do recommend that you read it in conjunction with Behavior Changes and Security Changes, as there are things there, which will also affect the enterprise use case.
What are your thoughts? And how did you like my animated GIFs? Better make a 15-min YouTube video instead next time? Let me know your thoughts!