Evolution of Android management for Enterprise use | Deep Dive with Joy

Today’s blog post focuses to understand the Evolution of Android management for Enterprise use.

This blog post is intended to help you build solid background knowledge of 
Android in terms of enterprise management. With this blog, I am starting off 
the Android series that will cover in detail, the different Android management
scenarios available with Microsoft Intune.

Grab a cup of coffee to sip through while learning the developments of Android management over time.

Evolution of Android management for Enterprise use – Overview

Google introduced mobile device management capabilities for Android with Android 2.2 back in 2010 with the Android Device Administrator (DA) API set.

Standing in 2020, we see that the way mobile devices are used in the enterprise landscape has changed dramatically over the period.

Work is more mobile than ever and mobile devices are used to access organization data and get the work done on the go more than before, and quite often, the same device is used for both personal and work purposes.

The Device Administrator (DA) API set failed to keep up with the requirements of this new mobile workforce which has emerged. As such, Google had to come up with a solution in order to keep Android relevant in the enterprise use-cases.

The result, as we all know it today is Android Enterprise.

In 2014, Google introduced a new set of modern device management APIs with Android Lollipop (5.x). We saw the introduction of two new management modes

• Fully managed (device owner), and
• Work profile (profile owner).

Android Enterprise, as it was introduced back then was known as Android for Work and it marked the Device Administrator (DA) API as a legacy.

In 2017, Google officially announced its plan to move ahead with only Android Enterprise discontinuing the support for Device Admin API in the future.

With the release of Android Pie (9) in August 2018, several functionalities of the Device Admin (DA) API were marked deprecated by Google, with complete deprecation of the Device Admin (DA) API with the release of Android 10 in September 2019. [Check this link to know more]

Though it is recommended to move to Android Enterprise. it is important to note that devices running Android versions till Oreo (Android 8) and currently managed via the legacy Device Administrator mode will continue to be managed and not be impacted.

Evolution of Android management for Enterprise use – Dive into the details

Android, from the beginning, has been an open-source platform, which is one of the primary reasons for Android being the choice of platform for OEMs producing mobile devices for the mass market.

Commercially sponsored by Google, the Android Open Source Project (AOSP) primarily licensed under the Apache License enables an OEM to take the Android source code and customize it further to create their own mobile OS based on Android.

They add their own apps, device drivers, a compactable UI, some custom features, and APIs (and yes, also some bloatware) on top of the stock Android image and create a completely new flavor of Android (ROM build) that they push in the chassis (device).

The OEMs mostly do this to curate the end-user experience. This is why, even though the devices from different OEMs might run the same Android version, the look and feel (and some features) vary and thus we get Androids of different flavors in the market.

Quick examples: Samsung devices run One UI, OnePlus devices run Oxygen OS,
Oppo devices run Color OS, Vivo devices run FunTouch OS, and so on.

The fact that Android is an open-source platform helped Google gain a substantial share of the mobile OS market, the same reason inadvertently became the Achilles Hill for Google when it came to using Android in enterprise use-cases.

Understanding the problem with Device Admin API

Any EMM (Enterprise Mobility Management) platform relies on APIs to communicate with and control managed devices.

Android facilitated the same in the initial days with the Device Admin (DA) API however quickly it was well understood that its limited functionality was of no match to the evolving requirements of the modern mobile workforce.

The Device Admin (DA) API set had a lot of shortcomings in terms of both usability as well as security, the most pronounced of them are listed below.

• Separation of work content from personal content in BYOD devices
• Secure app distribution
• Setting factory reset protection (FRP) to ensure devices remain managed and can be recovered when employees leave.
• Prevent removal of the device administrator.
• Consistent manageability across multiple devices from various OEMs.

Add to that, the now deprecated Device Admin API was never a standard part of the original Android source code and was very limited in its capabilities.

Thus the OEMs while preparing their mobile OS by taking Android source code from AOSP and customizing it, had the option to either incorporate the Device Admin APIs or omit them all together in favor of their own custom APIs which they developed to form their own enterprise capabilities.

Example: Samsung with their KNOX, Zebra with their Mx platform configurations.

Considering the sheer number of OEMs producing Android devices, it takes a lot of effort from any EMM solution to partner with all the OEMs to get all their custom APIs incorporated natively.

This is neither viable nor possible, as it would require the EMM solutions to maintain and manage every version of the APIs as developed by OEMs to maintain backward compatibility. On the other hand, if an EMM chooses not to implement the OEM APIs, then support for managing enterprise capabilities of devices from that OEM is understandably not available.

Why an EMM may opt-out of implementing APIs varies from resource availability, budget or time constraints, absence of an OEM/EMM partnership, or other reasons.

In the real world though, it was actually found that devices from different OEMs, and sometimes different device models of the same OEM, exhibited different results (if at all) when trying to manage a particular feature from an EMM solution.

This caused the infamous “all or none” management approach with Device Admin API resulting in inconsistent manageability and thus poor trust from the IT Admins.

How did Google actually solve the problem?

The straight answer would be by introducing Android Enterprise.

Android Enterprise is Google’s modern Android device management framework introduced to help overcome the shortcomings of the Device Admin API and make Android a suitable platform for enterprise use-cases.

Android Enterprise as we know it today, originally debuted with the name Android for Work with Android Lollipop (5.x). But at the time of its release, it was still an optional solution made available to OEMs to include in their devices.

However, this changed soon.

With Android Marshmallow (6.0), Google made Android Enterprise a mandatory component for all GMS-certified devices.

This ensured that even if your lineup of android devices consists of devices from different OEMs if all the devices are GMS certified, they would still offer the same manageability and end-user experience.

Getting to know Android Enterprise

Android Enterprise is a set of robust management APIs that enables EMM solutions to confidently deploy and manage Android devices for enterprise use.

Android Enterprise is a set of modern management APIs that suffices the enterprise use-cases, to be incorporated by all OEMs in their Android builds, thus becoming the sole set of APIs that an EMM Solution needs to implement for effective and efficient Android management irrespective of the device OEM, achieving the consistent manageability across OEMs.

Multiple use-cases to support every enterprise’s requirements

Android Enterprise supports multiple use-cases as shown below

• Containerized managed work profile to separate work/personal space on BYOD devices
• A fully managed device with no personal profile for complete corporate ownership (previously known as COBO)
• Fully managed devices further locked down to specific use-case like Kiosk referred to as dedicated devices (previously known as COSU)
• Work profile on a fully managed device to enable the corporate device for personal use (also known as COPE)

Flexible provisioning

Android Enterprise gives you the flexibility to choose from a variety of deployment methods for device provisioning as below.

• Manual IT Admin or user-driven deployments
  • QR code or Enrollment Token
  • NFC bump
  • DPC Identifier

• Fully automatic deployment
  • Zero Touch

In addition, Android Enterprise gives you the below additional benefits.

Easy and secure app deployment

Managed Google Play allows for a standard and secure way for IT admins to whitelist apps for easy deployment, distribute private apps and perform silent app installs without requiring the need to enable app install from unknown sources.

Google’s Play Protect suite of solutions helps protect devices from any Potentially Harmful Application (PHA)

Guaranteed security updates

Google releases monthly security updates to patch vulnerabilities and exploits in Android. However, except for Pixel devices, almost all other android devices have to wait to get the security updates as and when made available by OEMs. 

With the introduction of the Android Enterprise Recommended program, devices covered under the program are mandated to receive the updates within 90 days of Google’s release. The Android One program compliments further by mandating security updates within 30 days of Google’s release.

Though Android Enterprise is now the only recommended and modern way of managing Android devices in your enterprise landscape, however, you need to understand that Android Enterprise is officially supported on GMS certified devices only.

What is GMS?

While Android itself is an open-source project, the mobile device that ends up in users’ hands has some proprietary bits mixed in, particularly apps and services bundle from Google which is collectively known as the Google Mobile Services (GMS).

The bundle varies from region to region, but typically includes the below.

• Google Chrome
• Google Search
• YouTube
• Google PlayStore
• Gmail
• Google Drive
• Google Duo
• Google Maps
• Google Photos
• Google Play Music
• Google Play Speech

In addition to the above proprietary Google apps, GMS also includes the all-important access to use Google Play services and the corresponding Google APIs (SafetyNet, Play Protect, Play EMM, etc.)

Google has built GMS on top of the Android Open Source Project (AOSP) in a way that

• the Android Open Source Project (AOSP) corresponds to the core Android OS and
• the Google Mobile Services (GMS) which runs as an add-on and gives access to the Google-branded apps and services.

Where the former is free and enables anyone to take the Android Source code and use it to build their own custom ROM to run on a device (facilitated mostly by the Apache license), the latter requires an OEM to obtain a GMS license, a.k.a the Mobile Application Distribution Agreement (MADA) from Google in order to pre-install Google apps and services on their devices.

Understanding the difference between a GMS license and a GMS certification

A MADA license entitles an OEM to include and use the Google proprietary apps and services on its devices, but it does not necessarily mean that every device model it produces/will produce is/will be GMS certified.

To get GMS certified, the device needs to go through several compatibility tests and processes as designed by Google to ensure that it meets the performance requirements of Google and can properly run and use Google apps and services.

What about devices that are not GMS certified?

Non-GMS-certified devices, unfortunately, needs to be managed using the legacy and deprecated Device Admin API, provided they are running a supported Android version (up to Android Oreo).

For non-GMS-certified devices running AOSP builds for android version 10 or higher, since the core Android OS on these versions does not have the Device Admin API, they, unfortunately, can’t be managed the legacy way using Device Admin.

A more recent example that you all may relate to would be the case of Huawei.

Following an order by the United States (US) government, Google withdrew
the Chinese telecom giant Huawei’s MADA license. The result - all present 
Huawei devices in the market denied receiving any further Android security
updates from Google, and all upcoming devices from Huawei denied using 
Google's proprietary apps and services.

Since Huawei as an OEM would not be able to get its devices GMS certified 
any more, this eventually makes all upcoming Huawei devices unfit to be 
deployed and used in enterprise scenarios since the devices will not officially
support Android Enterprise management.

And if the Huawei decides to build Android OS (its own EMUI based on Android)
based on the current versions of Android (10, 11) using AOSP, such devices won't
be manageable using legacy Device Admin since the Device Admin APIs have been
deprecated with Android 10..

Unofficially, non-GMS-certified modern Android devices do allow for a limited Android Enterprise management experience with an EMM that supports closed network or non-GMS management like VMWare Workspace One.

Microsoft Intune (aka Microsoft Endpoint Manager) has no support for Closed Network AOSP Android management.

Before we end for today…

Recommending an Android device for enterprise use-case was a tough job a few years back, however, the scenarios have changed now for the better with Android Enterprise which guarantees reliable consistent manageability and user experience across OEMs.

Further, Google has tried to help enterprise customers by launching programs like Android Enterprise Recommend (AER).

What is Android Enterprise Recommended? How does it benefit enterprise customers?

To help enterprise buyers confidently choose android devices for their use-cases, which can be

• easily deployed for enterprise use,
• offer consistent end-user experience and excellent manageability
• have a guaranteed period of OEM patch support

Google came up with the Android Enterprise Recommended (AER) program back in 2018.

To be listed as an Android Enterprise Recommended (AER) device, a device has to go through an additional series of thorough testing against the best practices and common requirements as laid down by Google, over and above the GMS certification requirements.

Below listed are some of the essential requirements that the device needs to satisfy in order to be listed as an AER device.

• Hardware specification to support at least Android 7.0
• Support for Zero-Touch enrollment
• Must adhere to standard provisioning screen flows
• Must comply with the defined work profile experience
• Support current release + one major OS upgrade
• Unlocked device must be available directly from the manufacturer or reseller

Previously till Android 10, Google required an AER device to guarantee security patches within 90 days of Google’s release for a period of 3 years. However, with Android 11, Google has lifted off this requirement by instead mandating the OEM to publish security update information on its website and the period through which a device is guaranteed to receive security updates.  

In line with the above, Google’s Android Enterprise Recommended website now shows how long the manufacturer intends to support the device. Check the announcement below.

When an enterprise decides to buy Android Enterprise Recommended devices, they can be assured that the devices have been tested to meet Google’s enterprise criteria and as such will exhibit seamless and consistent experience and manageability across OEMs, along with the peace of mind that the devices will be supported and patched by the OEM for the specified period of time thereby addressing the concerns of security, throughout the device lifecycle.

Further improvements in Android management with OEMConfig

Google has always clarified that Android Enterprise is only a base set of APIs which it will continue to develop and add new APIs over the year, as the OS continues to mature and to address the further upcoming new needs.

This gives the OEMs an option to add further value to their devices by creating their own APIs to address and manage certain new functionalities, over and above Android Enterprise.

But then, does not this brings us back to square one? The EMM solutions would again need to partner and work with the OEMs to incorporate these OEM-specific custom APIs to be able to utilize the capabilities.

No. And this is where OEMConfig comes in.

OEMConfig is a standard defined by Google which enables an EMM solution to manage OEM specific APIs built over and above Android Enterprise, without the need to incorporate these OEM specific APIs natively within the EMM, but still be able to manage these OEM specific features from your EMM by virtue of using configurations similar to app configuration profiles to configure and deliver device settings to an OEM developed application present on the device (pushed from EMM solution using Managed Play) which acts as the interface between the EMM and the OEM specific APIs and applies/enforces the delivered settings on the device.

Each OEM has its own OEMConfig app which is available in the Google Play Store and acts as the interface between the EMM solution and the OEM-specific APIs on the device, and thus does not requires an EMM solution to do anything to support this.

The onus is on the OEMs who need to develop their OEMConfig app and make it available and have configuration reference documents for the IT admins to be able to create app configuration profiles from the EMM solution.

Here is a list of OEMs who have their OEMConfig apps in the Google Play store and can be onboarded to Intune to be used.

OEMConfig is an incredibly powerful solution that makes an IT Admin able to manage new device features from day zero (again depends on OEM if they have updated their OEMConfig app in tandem with the new release), without requiring any complex development from the EMM side.

To be Contd.

Well, that was all for today.

I hope this helps you in understanding the complete back story of Android management. As I said in the starting, this post marks the beginning of a series and as such there will be further upcoming posts.

Do check out my other blogs on different Intune topics here.

Stay tuned to this blog site. Subscribe to get notified of new posts and be a member of the How To Managed Devices (HTMD) community.

Use the HTMD Forum to post your queries related to Intune/SCCM and get expert advice and answers from the HTMD community.

Starting 1st Jan 2021, I have started my own blog site. You will find my latest posts here at joymalyabasuroy.com