This is the first blog in the series on building a custom MDM solution.

First of all, what are we trying to build?

We are building an instructional platform for K-12 education based on Android tablets. These tablets will be used by teachers and students, primarily in a classroom. The tablet helps the teacher in facilitating a class and provides various tools and applications to interact with the students and help them learn better.

So, what is a MDM and why do we need it?

MDM stands for Mobile Device Management. Given that these tablets will be deployed in various schools, the MDM solution lets us manage them remotely. This includes downloading various learning content, installing educational apps, setting password policy on the tablet, et al, remotely. Because the tablet is used in a school environment, the MDM solution is also responsible for providing a safe and secure container for running the applications. This includes enabling/disabling certain settings on the tablet. The MDM solution also provides a single sign on solution for the tablet user. This allows us to capture the user credentials once and use it for the course of the user’s lifetime. This also gives us the ability to customize the content on the tablet to that specific user.

So, how did we implement it?

The MDM solution has two primary components, first, the MDM agent, that lives on the tablet and second, the MDM server. At a high level, an Admin user interacts with the MDM server to perform an “operation” on a tablet (or a group of tablets) via a web portal. An example of an operation would be “install an application” on a tablet. In order to execute this operation, the MDM server notifies the tablet via GCM, the MDM agent on the tablet receives the notification, requests the MDM server for its operations via HTTP, the MDM server sends the operations and then the MDM agent executes those operations on the tablet and sends the status back to the server. The status is then displayed to the Admin user on the web portal.

Other examples of operations include:

• Blocking the settings on the tablet
• Enabling VPN
• Reset the password on the tablet
• Sending a message
• Unregistering the user on the tablet
• Factory resetting the tablet

and many more.

In order to build some resilience in to the system, we have introduced retry mechanism on the server. If the server does not get a response from the tablet in a configured amount of time, we retry sending the notification to the tablet. We have also built some “pull” in to the tablet, which means, every time the tablet is rebooted, it will request for its operations from the server. The operations are idempotent which means if they are executed multiple times, the end system state is the same.

In the next part, I will talk about the tablet architecture, which requires some cool “hacking” on the Android operating system. Here’s how!