Understanding Android Management with Intune | Android Enterprise

In this article, I would be talking about the Android Management in general with Intune – how the management has evolved over time and the different management modes that is offered with Android Enterprise. A dive into the evolution of Android Management – the demise of Device Admin API and way forward with Android Enterprise…

I have also tried to give an insight into why Device Admin mode failed leading to it’s deprecation and the way forward to Android Enterprise – how to plan if you still have Android devices in your environment managed via Legacy Device Admin mode.

Subscribe to this blog

Patch My PC
[jetpack_subscription_form show_only_email_and_button=”true” custom_background_button_color=”#abb8c3″ custom_text_button_color=”#ff6900″ submit_button_text=”Subscribe” submit_button_classes=”wp-block-button__link has-text-color has-luminous-vivid-orange-color has-background has-cyan-bluish-gray-background-button-color” show_subscribers_total=”true” ]

Let’s get started.


Android is the undeniable leader (?) in the Mobile OS market and the popularity comes down to the fact that the core source code is an open-source. This has led to many variants of Android we see today in the market.

Though Android continues to lead the market, undeniably iOS has better preferences in the IT Enterprise scenarios due to its security (iOS is Apple proprietary and is closed eco-system) and consistent management capabilities (since its only Apple which manufactures iPhones/iPads).

When we look down at the Android space, there are numerous OEMs in the market and each have Android customized to suit their needs –

  • Xiaomi smartphones run MIUI based on Android
  • Vivo smartphones run FunTouch OS based on Android
  • Oppo smartphones run Color OS based on Android
  • HTC smartphones run Sense UI based on Android
  • Samsung smartphones run One UI (previously TouchWiz) based on Android

There are only a few OEMs which manufactures smartphones running stock Android with bare minimum modifications made to the original source code, like Nokia, Motorola and the Google’s own Pixel devices to name a few.

NB: The phones under Android One program also offers stock Android experience.

When we talk about Enterprise scenario, administrative capability and manageability comes as the top priority for IT admins. We all want to be in control of the devices that are being used in our enterprise landscape, aren’t we?

With the advent of mobile devices sneaking into corporate workspaces and more and more employees using mobile devices to get to the data required to perform their work, is the reason why Mobile Device Management even came into existence.

Android originally introduced the support for management of mobile devices in Android 2.2 (Froyo) with the Device Admin APIs, and it has continued to be the lone way of managing android devices till Android 4.4 (KitKat)

Altaro Office 365 Backup
Advertisement Altaro Office 365 Backup

What led to the demise of Device Admin management mode?

Android 2.2 being launched in 2010 and Android 4.4 in 2013, in this 3 years it was clear enough to understand that Device Admin management mode as provided by Android is inconsistent and falls short in many enterprise use cases, which made iOS devices the 1st choice for Enterprise scenarios.

The Device Admin API falls short when it comes to the below scenarios (as much as I can think off)

  • Separation of work content from personal content in BYOD devices
  • Distribution of business applications through Google Play
  • Setting factory reset protection (FRP) to ensure devices remain managed and can be recovered when employees leave.
  • Secure reset of device passwords on encrypted devices.
  • Prevent removal of the device administrator.
  • Establishment of admin defined passcodes to lock the user out of a device.

Beyond basic security policies and perhaps a simple email/Wi-Fi, etc. configuration then, there’s not a lot administrator can manipulate and control.

When I mentioned about inconsistent behavior in device manageability, you can understand it essentially comes down to the same fact of having numerous variants of Android. The reason being, the Device Admin APIs were not a standard part of the Android Source code but Google provided it as an optional package. As such OEMs (as mentioned above) while creating their own variants (heavily skinned) many a times decided to omit the management APIs as provided by Google and/or instead have their own in-house API integrated.

In such a scenario, it is impossible for any EMM solution to provide a consistent management experience across the wide range of Android devices.

Samsung devices on the other hand have had deep EMM integration via their KNOX standard APIs incorporated into their devices which allowed EMM solutions with abundance of restrictions available, excellent visibility of device posture, integration with back-end corporate solutions and more flexibility in how a device is deployed. In fact, there are currently more restrictions available on a Samsung KNOX device than an equivalent work-managed device, as Google continues to work towards feature parity.

However, Samsung KNOX devices still succumbs to short comings of Device Admin mode, namely

  • Need to enable unknown sources for LOB application deployment from EMM provider,
  • Require device administrator permissions for the DPC,
  • Need for a Google account for application management (there are some APIs for silent application installation, however these are based around in-house applications, not public Play Store apps).

As such the Device Admin management mode has always been the “all or none“.

Device Admin mode has been considered Legacy since the introduction of Android Enterprise Management APIs with Android 5.0 (Lollipop) and was marked deprecated with release of Android 9, many features were taken off in the subsequent release, with full decommission with release of Android 10.

Understanding Android Management - Evolution of Management features and the API levels
Understanding Android Management – Evolution of Management features and the API levels

Android Enterprise – A standard

With Android Enterprise Management APIs, Google did not repeated the mistake of leaving them as optional like in the case of the Device Admin APIs, but instead, made them as a standard package in the Android Source code. The result, an OEM taking the source code now and doing heavy modifications will still have the management APIs intact in the source resulting a consistent management behavior across the device range.

Did anyone asked about the benefits?

  • Consistent manageability irrespective of OEM.
  • Managed Google Play store helps to deploy LOB apps without the need to enable Unknown Sources.
  • Ability to wipe only corporate data leaving personal data intact for Work Profile devices.
  • Various management modes available to suit the different requirements in an Enterprise scenario.

With advancement and evolution over the years, Google with Android Enterprise has been able to position Android as a good-fit for enterprise use.

Still we might see inconsistency in rare cases, which again is due to the changes made by the OEM to the Android source code leading to a bug. Google insists OEMs to use the Android’s inbuilt security feature instead of making changes to the core kernel.

According to Google’s Project Zero security team, several phone makers have tinkered with the software in order to make their devices more secure – however, in the process, have actually ended up making the phones vulnerable to serious security bugs. This includes Samsung, whose tinkering with the Android Linux kernel has resulted in exposing the company’s devices to a range of threats.

Intune and Android Management

Below shows a schematic representations of the different management modes available for Android with Microsoft Intune.

Understanding Android Management - The different type of management supported by Intune - Android Management
Understanding Android Management – The different type of management supported by Intune

Leaving the legacy and now deprecated Device Admin management mode, Android Enterprise management in Intune supports

  • Profile Owner mode (BYOD) which we still often say as Android for Work
  • Device Owner mode (COD)

Device Owner mode again gives you a choice of two types of device management

  • Fully Managed (COBO)
  • Dedicated Device (COSU)

If you check the Google documentation for Android Enterprise, you will see there is one more scenario that Device Owner mode supports – Fully Managed with Work Profile (COPE) however this is not supported in Intune yet.

Understanding Android Management - Different Management modes of Android Enterprise
Understanding Android Management – Different Management modes of Android Enterprise

How to decide the mode of management – Migrating from Device Admin to Android Enterprise

If in your organization, you are still managing Android devices using the Legacy Device Admin method, it’s high time you start the migration to Android Enterprise. Below is a decision flowchart to help plan the mode of AE management required as per environment requirement.

Understanding Android Management - Decide the mode of management - Migrating from Device Admin to Android Enterprise
Understanding Android Management – Decide the mode of management – Migrating from Device Admin to Android Enterprise


Hope this article helps you have a good understanding of the evolution of Android Management and the current supported Android management scenarios with Intune. Once again, if you are still managing Android devices using the legacy Device Admin mode, it’s high time you should start planning about the migration to Android Enterprise.

I will end this today here but follow it up with the internals of AE management sometime later. Till then, keep reading keep learning!


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.