The context

A client developed a standalone device, with an interesting UX
This product will be unattended, available for random user interactions in crowded places.
When you have unattended devices, there are some challenges that you need to tackle to guarantee the user flow stays as intended.

For example you need to modulate the access rights of generic users so they can't do thing like change language, disconnect the network, factory reset the device, access internal information, and so on.

You have to effectively lock down the device. You may just pair it down to the bare minimum functionality, at the same time, servicing the device could become difficult in this case. So you effectively need a dynamic way of locking down the device. This is often called kiosk mode.

Additionally imagine releasing an update to the core functionality, how do you distribute this update? Physically visiting all remote devices won't work, so you need a distribution method.

Let's see what are the main challenges in managing a fleet of remote devices.

Challenges

The device is unattended, so it has to be protected and should be able to perform its function without further interventions.

So then:

• how do you update the application?
• how do you prevent undesired interactions?
• how do you ensure consistency and status across multiple remote devices?

These are all valid questions and they require careful planning to be solved within the requirements of the business case.
Often times companies think remote software can be done in house, and they end up draining a vast amount of resources to put it in place and manage it.
We did this at EVBox but the use case was vastly different: tens of thousand of secured embedded Linux devices, able to authenticate with and talk only to the company backend.

‍
The security requirements made it so that it was hard to insert a middleware, so we made our own software update component but that's not for everyone, and surely enough not for small businesses.
So what options do we have?

The solution: Mobile Device Management

One possible solution is to use a device management platform. This is a middleware that inserts in the device, and communicates to the backend of the provider, allowing a number of services.

These MDM tools usually cover Android and Apple portable devices ecosystems, while there are specialized tools for Linux IOT devices.

In this case the client was using Android, and this narrowed the scope and made certain aspects easier.

If you have an Android-powered IOT device, you can use a MDM platform, Mobile Device Management, which will hook automatically into the Android APIs and let you remotely manage the device.

Most of these services offer various services, like:

• fleet management
• policy management
• kiosk mode
• application list management
• remote update
• remote control

Making the choice

Making the choice of which MDM platform to go for is a process, there is no one-solution-fits-all.
Of course the price is going to be an important factor, but the technical aspects are equally if not more important.
After all if you buy a solution and it doesn't work, you're back to square one right?
So let's see some aspects that I evaluated to help my client make the right choice.

One important aspect we'll see in more details is the complexity of the MDM product itself. My client is a small business, it does not want to deal with the complexity of large scale IT departments, so the solution must be easy to use.

Enrolling the devices is another important factor: we're not talking end-user devices with all the bells and whistles, these are bare minimum devices, without most of the services and this can prove challenging for the MDM platform if it is not designed to handle this case.

I also evaluated the functionality of the tool, how easy it is to bring to final configuration, how automated or manual is the process, how many steps (imagine having to manually configure each device for half an hour, it wouldn't scale!).

Another aspect is managing applications, as that is the core of the product. Application lifecycle management on the MDM must be accurate yet easy, it must be possible to deploy, update, retire an application in seconds.

The last one I want to mention is setting device policies. This is an important one because it allows to have fleets with consistent states. For example you may have a policy for production devices and one for servicing or testing. So when a device is at a client, it is given the production policy and it immediately sets all the parameters for full lockdown and user-facing functionality. While if someone has to be servicing a device, you may give it a more open policy so that working on it is easier, while not touching the rest of the fleet.

So now that we have an overview of the factors, let's dive a bit deeper into the most important ones.

Product Complexity

One complexity of MDM platforms is identifying their target customer. In fact some cater to very large businesses, looking to manage employee devices (like smartphones). In this case their extremely comprehensive and granular customization options will be overwhelming and cumbersome for small businesses and startups looking for something simple, so care must be taken to identify whether the offering is the right one for the need.

Do not underestimate this aspect. Remember the point about updating the application remotely?

I tested this flow on all tools I was able to get working on the devices.

One of the platforms in particular, prompted me for two factor authentication codes twice for each application update!

Once to add a new version of the application, and another to roll it out to the devices.

This clearly indicates this platform is not expecting frequent application updates, which is exactly the contrary of a startup: frequent, easy, immediate application updates.

Device policies were also more complex and detailed on this platform, which is one of the reasons it was eventually discarded in favor of a more simple one.

Device Enrollment

Another aspect is how you'll get your device under the management of the platform.

Most platforms offer an always-on application, sometimes called daemon, to monitor the device and connect it to the management platform. Another option can be to use Google Workspace, with the custom Google APIs. And sometimes some platforms offer a blend of the two, giving you an application and a connector to Google so you can do both. The key aspect is the requirements of each of these options.

A custom application might be available only via Google Play for example, and if your custom device does not have Google Play Services (the marketplace of Android), then you can't install that application.
In this case you have to check whether the MDM platform offers an APK for side-loading. If so, this may work out.

Yet another important aspect of this application is that it requires essentially what amounts to root permissions in order to be able to lock down the devices.

Now this is not immediately doable on commercial end-user devices, in fact rooting of an Apple or Samsung phone is explicitly forbidden by the manufacturer and will void the warranty. On custom IOT devices it's a different story as these are most often not as locked down as their commercial counterparts. In this case you may be able to give all the permissions that the MDM tool needs either from Android itself, or using ADB after enabling Debug mode from within the UI. As always though, the MDM supplier has to allow you do take this route and support it, otherwise it won't work.

In fact, the normal way for end-user devices to achieve this is to perform a special initialization at first boot that will grant the MDM organization special execution rights. This special initialization though relies on specific Google Services that must be available on the device, and are not default on AOSP distributions. Hence, if you're running a custom version of AOSP on your IOT device, this won't work for you.

So I had to go for those MDM platforms that offered a daemon with an APK for side-loading and instructions on how to grant it the necessary permissions. This restricted the choices somewhat.

Once the daemon is installed, it's time to link the device to the organization, this is the proper enrollment. In my experience some of the products I tested, only offered enrollment via QR code, which of course requires a camera on your end device. And if it's an IOT control box without a camera? Then it won't be possible to enroll with that MDM unless they offer an alternative method.

As mentioned before, another way to enroll a device is via Google Services. This sounds standard for Android, but that holds true only for end customer products like commercial smartphones and tablets. A custom device, especially in the early stage, will most probably be running a flavor of AOSP (Android Open Source Project) without a license to Google Services (hence we saw before that you might not have the Play Store), in this case Google Workspace enrollment, or enrollment via multi-tap, or enrollment via sign-in might not work.

The selection process

So now that we have analyzed some of the most complex requirements, let's see how the selection process works by following what I did for my client.

First let's define what kind of device we're working with: my client has a custom device, no camera, some versions are running Android 13 some 14, all of them without Play Services. This excludes platforms that only offer their application  Play Store Also the devices don't have a camera, so the application not only has to be side-loaded, it must also be able to take a code, or some kind of user input that I can provide manually for onboarding to the correct organization. Here are the platforms that entered the pool and their features as advertised

For each of these I registered for a free or trial account, and proceeded to setup a device, deploy the daemon, enroll it, create policies, remotely load the user application, and when having problems I also reached out to their tech support.

Findings

Here's what I found out

Miradore

I was not able to install it, it only allows device enrollment via google services, no additional method available
Discarded
‍

TinyMDM

I was not able to install it, it only allows device enrollment via google services, no additional method available. Their tech support mentioned having a beta to try, but then when I asked to to give it the correct access rights, they did not have a solution for me.
Discarded
‍

Hexnode

It was easy to install, and the daemon automatically installed a VPN module and a RemoteControl one, so far so good. The issues appeared when using the platform to manage the device: extremely granular controls, complex policies, multiple action validation requests requiring 2FA, background execution rights not available.
Eventually discarded for too much complexity
‍

Scalefusion

Easy to install and enroll, easy to manage applications, easy to manage policies and kiosk mode. Where it had issues was in granting it root permissions, the remote control never worked, and the remote app deployment was inconsistent as some apps would not be loaded by the device.
Discarded for inconsistent behavior
‍

AirDroid Business

Instructions for sideloading and ADB permission setting are easily available, policies and kiosk are easy to setup, device groups are a breeze, everything worked immediately, and when we had some doubts their customer support was immediately on it and solved our issues.
Accepted

Here are the findings in table form

Conclusions

Choosing the right Android MDM platform for IOT devices requires careful consideration of device compatibility, cost, and operational requirements. The platforms tested each had pros and cons, and the selection focused on the specific needs of my client's use case.

The key to success lies in matching platform capabilities with your specific technical constraints, in this case it was the enrollment that proved particularly challenging, and update requirements. By following a structured evaluation process and conducting thorough testing, you can confidently select a platform that will reliably manage your Android IoT devices while supporting your business objectives.

If you too are looking for a device management solution and find it difficult to find the right one, I can help. Go to the contact page and let's explore your needs together!

‍

‍