Evolution of Android Management for Enterprise Use | Deep Dive with Joy

Today’s blog post focuses on understanding the Evolution of Android management for Enterprise use.

This blog post will help you build solid background knowledge of Android in enterprise management. With this blog, I am starting the Android series, detailing 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.

Android Enterprise, led by Google, facilitates the integration of Android devices and apps into workplaces by providing developers with APIs and tools for seamless incorporation into enterprise mobility management (EMM) solutions.

Sign up to get the best of How To Manage Devices straight to your inbox!

• Android Management With Intune | Android Enterprise
• Intune End Of Support For Android Device Administrator
• Enrolment Guide For Enrolling Android Devices To Corporate Owned Business Only In Intune

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. As of 2020, mobile device use in the enterprise landscape has changed dramatically.

Work is more mobile than ever, and mobile devices are used more often to access organization data and do the job on the go. The same device is often used for personal and work purposes.

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

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

In 2014, Google introduced a new modern device management API 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 forward 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 the complete deprecation of the Device Admin (DA) API with the release of Android 10 in September 2019. [Check this link to know more]

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

Evolution of Android Management for Enterprise Use – Dive into the Details

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

Google commercially sponsors the Android Open Source Project (AOSP), primarily licensed under the Apache License. The project enables OEMs to customize the Android source code further to create their mobile OS based on Android.

They add their apps, device drivers, a compactable UI, some custom features, and APIs (and yes, also some bloatware) to the stock Android image and create an entirely new flavour of Android (ROM build) that they push in the chassis (device).

OEMs mostly do this to curate the end-user experience. This is why, even though devices from different OEMs might run the same Android version, the look and feel (and some features) vary, and thus, we get Androids of various flavours 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. However, the same reason inadvertently became Google’s Achilles heel when using Android in enterprise 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 this in the initial days with the Device Admin (DA) API; however, it was quickly understood that its limited functionality was no match for the evolving requirements of the modern mobile workforce.

The Device Admin (DA) API set had many shortcomings regarding usability and security, the most pronounced of which are listed below.

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

Additionally, 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 altogether in favour of their custom APIs, which they developed to form their enterprise capabilities.

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

Considering the number of OEMs producing Android devices, any EMM solution must exert a lot of effort to partner with all the OEMs and integrate all their custom APIs natively.

This is neither viable nor possible, as it would require the EMM solutions to maintain and manage every version of the APIs 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 unavailable.

The reasons an EMM may opt out of implementing APIs vary, including resource availability, budget or time constraints, the absence of an OEM/EMM partnership, or other reasons.

In the real world, though, it was 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 the Device Admin API, which resulted in inconsistent manageability and, thus, poor trust from the IT Admins.

How did Google Solve the Problem?

The straight answer would be to introduce 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.

As we know it today, Android Enterprise originally debuted as Android for Work with Android Lollipop (5. x). But at 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, they would still offer the same manageability and end-user experience if all the devices were GMS certified.

Getting to Know Android Enterprise

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

Android Enterprise is a modern management API that suffices for enterprise use cases. All OEMs incorporate it 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 consistent manageability across OEMs.

Multiple use cases to support every enterprise’s requirements

Android Enterprise supports numerous 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-cases 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 allows you to choose from various 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 following additional benefits:

Easy and Secure App Deployment

Managed Google Play allows IT admins to standard and securely allowlist apps for easy deployment, distribute private apps, and perform silent app installs without requiring the need to enable app installation 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 for security updates as and when OEMs make them available. 

With the introduction of the Android Enterprise Recommended program, devices covered under the program are mandated to receive updates within 90 days of Google’s release. The Android One program complements this 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, you need to understand that it is officially supported only on GMS-certified devices.

What is GMS?

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

The bundle varies from region to region but typically includes the following.

• 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 includes all-important access to 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 mainly 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 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 Google’s proprietary apps and services on its devices. Still, this does not necessarily mean that every device model it produces or will produce is GMS-certified.

To get GMS certified, the device needs to undergo several compatibility tests and processes designed by Google to ensure that it meets Google’s performance requirements and can adequately run and use Google apps and services.

What About Devices that are not GMS Certified?

Unfortunately, non-GMS-certified devices must be managed using the legacy and deprecated Device Admin API, provided they run a supported Android version (up to Android Oreo).

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

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 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) does not support 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 developed the Android Enterprise Recommended (AER) program in 2018.

To be listed as an Android Enterprise Recommended (AER) device, it must undergo additional thorough testing against the best practices, standard requirements laid down by Google, and the GMS certification requirements.

Below are some essential requirements for the device 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 devices 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 three years. However, with Android 11, Google lifted this requirement by mandating that OEMs publish security update information on their websites and stating the period through which a device is guaranteed security updates.  

In line with the above, Google’s Android Enterprise Recommended website 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 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 that will continue to develop and add over the years as the OS continues to mature and to address the upcoming new needs.

This gives OEMs an option to add further value to their devices by creating their APIs to address and manage certain new functionalities in addition to Android Enterprise.

But then, doesn’t this bring us back to square one? The EMM solutions would again need to partner with and work with the OEMs to incorporate these OEM-specific custom APIs to utilize the capabilities.

No. And this is where OEMConfig comes in.

OEMConfig is a standard defined by Google that 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 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. Thus, an EMM solution is not required to do anything to support this.

The OEMs have the onus to develop their OEMConfig app, make it available, and provide configuration reference documents for the IT admins to create app configuration profiles from the EMM solution.

Here is a list of OEMs whose OEMConfig apps are in the Google Play store and can be onboarded to Intune.

OEMConfig is a compelling solution that allows an IT Admin to manage new device features from day zero (again, it depends on the OEM whether they have updated their OEMConfig app in tandem with the latest release) without requiring any complex development from the EMM side.

To be Contd.

Well, that was all for today.

I hope this helps you understand the complete backstory of Android management. As I said in the beginning, this post marks the start of a series, so 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 be notified of new posts and join 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 blog site. You will find my latest posts here at joymalyabasuroy.com

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Joymalya Basu Roy is an experienced IT service professional with almost five years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect at Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021.