Mobile Device Management Guide 2022: AOSP for Custom MDM

Mobile Device Management or MDM is an administrative area that deals with security and monitoring of corporate mobile devices. MDM software suggests methods to quickly deploy, integrate, and monitor a network of certain smartphones or tablets.

One of the primary concerns of MDM is security. Since corporate mobile devices can access critical business data, they can threaten enterprise databases. Administrating devices through MDM provides the means to distribute software packages, set permissions, and optimize device functionality. But, ideally, MDM has to provide a way to oversee mobile devices as easily as desktop computers.

There are MDM systems for all mobile operating systems, including cross-platform ones. But today we’ll focus on Android as the only operating system that offers fully-fledged customization in terms of MDM. With the biggest market share and open-source nature, let’s look at how we can approach building mobile device management for Android devices.

Mobile device management features and capabilities

Before analyzing the actual Android solutions, we need to clearly understand what MDM is capable of. Mobile device management systems provide quite similar capabilities across the market. Some of the most common functions are:

• Enrollment — a procedure that entails installing MDM on a mobile device. The majority of MDM software supports bulk enrollment to install software packages on multiple devices at once. An Over-the-air (OTA) enrollment suggests distribution and installation of MDM through a dedicated web page or app.
• Profile management — once we install the MDM package, we can now assign working profiles for the device users.
• Policy management — a policy is a bunch of rules or permissions set for a given device. By providing policies, we may lock or unlock some of the software or hardware functions, denote rules for accessing corporate data, etc.
• Device administration and troubleshooting — further, all the policies can be updated remotely. This part of MDM functionality implements monitoring of the device and troubleshooting.
• Device location tracking – detecting device location via GPS.
• Remote wiping— once we enroll MDM on the device, all the corporate data accessed through it will be stored on a protected profile. This data and the MDM itself can be wiped to factory settings remotely to protect any data leakage from the stolen, lost, or compromised device.
  

MDM is a complex solution. However, it consists of modular small parts that after closer inspection are actually not that hard to implement as long as a skillful team is involved. Generally, these parts can be divided into an admin panel which includes a device policy controller (DPC), and middleware to orchestrate enrolled devices. By middleware we mean an API interface that performs all the policy updates, and transfers data between the MDM server and smartphones.

So, MDM solutions basically provide management of such features as WiFi, Bluetooth, NFC, USB file transfer, location tracking, phone, SMS, or just simply allowing users to access some settings on devices that otherwise wouldn’t be available. If any additional functionality is required, the best thing to do is to extend the existing API by adding methods, managers and services. It is done with certain policies on the backend, which would be later pushed to devices. Then, a system service is created as a simple way of sharing these settings across devices.

Based on our experience, such systems might scale to thousands of devices and require numerous custom policies. The majority of the security requirements are covered by the available MDM solutions on the market. However, some systems may require enhanced security and independence of operating system providers. This will impose a challenge to build a custom Android MDM where any policy can be deployed on the device.

So first, let’s look at the standard solutions for Android MDM, and then talk about the customizable options.

Android Management API: out-of-the-box MDM

Android Management API is a managed solution for building mobile device management systems for Android. Google ships the whole package of MDM software, including backend, based on their Cloud Platform, a device policy controller, and user interface to administrate corporate devices out of the box. All of these components become available after a few steps of registration we’ll describe later.

The Android API itself is required to build your own MDM solution and create custom policies. Currently, the registration for new solutions is open, except for creating a custom DPC. Which means, it is possible to develop an MDM platform based on the Android management API, but you won’t be able to apply custom policies.

To use a managed MDM, you’ll have to create a dedicated Google account to log into Google Workspaces. The account cannot be associated with the existing enterprise account. Google provides device policies for over 80+ types of Android smartphones, except Samsung KNOX. There are three ways we can implement MDM with Android management API:

1. Work profile. A dedicated account on a device that stores and transfers corporate data without affecting personal data. MDM policies are also applied to the profile data only.

2. Managed device, a smartphone or tablet enrolled with MDM.

3. Dedicated device, a separate device used with restricted functionality. For example, this can be a tablet used as a bulletin board.

   
   

The system allows enrolling target devices over-the-air, which means no cables are required. You can use a wireless connection to enroll and manage mobile devices on Android.

The list of available policies includes nearly all of the native functionality for Android devices. While the existing policies are not customizable, the ease of deployment and no need for Android development outweigh this flaw. So now let’s look at how to approach Google MDM.

HOW TO SET UP ANDROID MANAGEMENT API MDM

The registration procedure to Google’s MDM platform imposes several requirements:

• Android device version 6.0 or higher

• Access to Google Cloud Platform

• Enabled Android management API in Google Cloud Platform

  
  

After all the requirements are completed, there are two ways to enroll your devices. The easiest one is a quickstart procedure suggested by Google. This entails a few steps of creating a Google Cloud project, generating a QR code and enrolling the device with a default policy. Note that a device can only have a single policy at a time.

The more advanced way to complete setup is meant for creating your own MDM solution based on Google’s API. For a full setup procedure please check the article PDF, where all the corresponding steps are described.

Now, let’s move on and sum up the strengths and weaknesses of Google’s MDM.

BENEFITS AND LIMITATIONS OF ANDROID MANAGEMENT API

In terms of a mobile device management platform, Google suggests a solid base either for deploying a ready-made ecosystem, or using its API to build your own one. So here we’ll highlight some significant factors in choosing the solution type:

Out-of-the-box solution. Google’s MDM requires just a few steps to enroll your first devices. After that, the full range of capabilities for device management becomes available for the users. It doesn’t require any additional Android development, so we can say it’s a low-code solution. Since minimal manipulations on the server side are required.

Large list of supported devices. Usually, different types of Android devices can be used in the organization. Integrating different devices and writing custom enrollment methods might be a serious pain, unless your company uses a single type of Android device. Android management API solves this problem by providing support for over 80 Android devices by default.

DPC is updated with Android. A device policy controller is a module that sits on your target device and implements policies sent from a server. This bit of software is operating system dependent, meaning the updates in the OS will require DPC to be rewritten.

Default DPC from Google is updated with the Android version, since it’s a managed solution. So the only possible flaw here is that Google will abandon some of the older Android versions in the future.

This becomes beneficial if you lack flexibility within Google’s solution or want another set of policies. Or, you can use Android management API as a groundwork for your own solution. All of the developed solutions using Google’s DPC have to be registered and certified by Google. So here, you’ll need an experienced engineering team that has expertise in mobile application development and mobile device management systems specifically.

Besides these advantages, there are also two important factors you want to keep in mind.

No customization options. In terms of Google’s managed platform, there is no way you can customize the existing software. Building your own solution based on Android management API allows you to customize the backend part, but the set of policies remains unchanged.

Vendor lock-in. Another problem is security. Since the backend part of a system runs on Google Cloud servers, all of your corporate data will pass through it. This doesn’t necessarily mean your sensitive data is compromised. However, some organizations want to protect their information and keep it in house.

To overcome these limitations, another option for Android mobile device management can be approached.

Android Open Source Project (AOSP): custom mobile device management

Android Open Source Project or AOSP is an open source software stack for a wide range of mobile devices and a corresponding open source project led by Google. It can be used to create your own custom variants of the Android OC and mobile applications, and connect it with your custom back-end device management platform. AOSP provides a number of benefits for custom Android development:

Active open-source solution. Some features that might be necessary are either already implemented, some might be available in the nearest future. As soon as a security patch is committed to AOSP, it can be applied and pushed to users.

Full control over product life cycle. The product owner decides when to deliver a new feature or security update. Product needs can be prioritized, instead of waiting for something that might never be rolled out by vendors, who naturally prioritize their own needs.

Customization at any level. Linux kernel contains all the essential hardware drivers like camera, keypad, display, and others. Above it, there is a set of libraries, including an open-source Web browser engine WebKit, libc library, SQLite database, which is a useful repository for storage and sharing of application data, libraries to play and record audio and video, SSL libraries responsible for Internet security, and others.

Then, the Android Framework layer provides many higher-level services to applications in the form of Java classes.

The application level is where Android developers usually work. Android applications extend the core Android operating system. There are two primary sources for applications:

• Pre-Installed Applications: Android has a set of pre-installed applications, including phone, email, calendar, web browser, and contacts. These function as user applications as well as providers of key device capabilities that can be accessed by other applications. Pre-installed applications may be a part of the open source Android platform, or they may be developed by an OEM for a specific device.

• User-Installed Applications: Android provides an open development environment supporting any third-party applications. Our device administration app would fall into this category, and our main work will be done primarily at the framework and application levels. Applications at these layers are written with Java, so a regular Android team will feel comfortable working with them.

  
  

As a solution for businesses that use mobile device management, AOSP helps to resolve concerns for security of functionality limitations and ownership over the product. As it’s possible to create an Android stack that will provide any features and means of device management that they might require. So let’s quickly enlist the pros and cons of this approach.

BENEFITS AND LIMITATIONS OF CUSTOM MDM

Flexibility. As we mentioned, custom development allows you to choose any architecture and solution type you want for mobile device management. This means you can deploy a custom backend with policies of your choice. You can provide any enrollment methods, security management, and reporting.

Independence of data collection. While AOSP is an open-source project led by Google, the solution based on it doesn’t depend on their infrastructure. This means, your mobile device management system will be secured from data collection by third-party organizations.

Operating system customization. Additionally, the operating system itself can be customized to bring extra functionality and enhance security of the system. The only limitation here is hardware capabilities of the target device.

Complexity. The approach of customizing the OS, creating your own applications and back-end management platform is a complex and time-consuming project. Moreover, customizing Android OC core requires not only an experienced and skilled development team, but extensive quality assurance as well.

How to choose the best solution?

Given the described options, how do you choose? Here is a quick run through the key points:

Google mobile device management platform is capable of closing the majority of needs for mobile device management systems. The only tangible limitation here is the closed registration for developing custom device policy controllers, so no custom policies can be implemented. Another solution is using Google Cloud platform as your backend, which can be a security, or architectural concern for some organizations.

Using Android management API as a basis for your system allows some customization, but still relies on Google’s infrastructure. So approaching AOSP-based MDM might be the best choice if you require a high degree of customization. Based on our experience, working with AOSP might be a time-consuming task. But at the end of the day, it fulfills project objectives at the same level as native Android MDM solutions.

Mobile Device Management solutions for iOS

It’s a rare case for the enterprise to use devices only on Android. So the first thing that pops up is the question, what about iOS? Apple devices have a built-in framework for enrolling and managing iOS smartphones and tablets. The capabilities are similar to Android management API, including enrollment options, and management flexibility. Because it’s a huge topic, we’re going to describe MDM for iOS in a dedicated article. Please stay tuned to learn about the implementation of the iOS framework in future material or contact us if you’ve got interested in Android MDM solution.

Written by Anton Logvinenko, Web Team Leader at MobiDev.

The full article was originally published here and is based on MobiDev technology research.