Developing A Solution For Mobile Device Management
Mobile device management (or MDM) is an administrative area that deals with deployment, security, monitoring, integration and management of mobile devices in the workplace. The goal of MDM is to optimize functionality and security of mobile devices within enterprise ecosystems and corporate networks.
Mobile device management software allows distribution of applications, data and configuration settings and patches for these devices. Ideally, MDM software allows administrators to oversee mobile devices as easily as desktop computers and provides optimal performance for users. MDM tools generally include application management, file synchronization and sharing, data security tools, and support for either a corporate or personally owned device.
There are mobile device management systems on all popular operating systems, but today we are going to focus on Android as the operating system with the biggest marketshare and open-source nature. What’s more, it’s the only operating system that offers full-fledged customization. And contrary to the widespread myth, Android is not an enemy to security.
Main threats to Android
But before we proceed to ways of boosting security on Android, we’ll start with main threats that must be considered:
• Application based threats include not only malicious software, but also applications that have bugs or defects that lead to unintentional behavior.
• Network exploits take advantage of software flaws in the mobile operating system or other software that operates on local (Bluetooth, Wi-Fi) or cellular (SMS, MMS) networks. Network exploits often do not require any user intervention, making them especially dangerous when they propagate malware automatically.
• Lost or stolen devices can also be considered a threat; not even because of the hardware, but because of sensitive personal and corporate data it may contain.
• Another potential source of threat is fragmentation of Android OS and its customized versions distributed by different vendors and carriers. According to Google Play Market statistics, only a small percentage of devices are currently running the latest Android OS; and only these devices have the most comprehensive set of available features. Another problem is that not all devices are updated in time or even get an update provided by vendors.
This means that developers would not be able to leverage full functionality of device administration tools provided by Android SDK. In case of limited device management it might be enough, but what if it isn’t?
The answer lies in AOSP.
Android Open Source Project (AOSP)
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 custom variants of the Android stack, and port devices and accessories to the Android platform. There are already lots of forked versions of Android that provide users with different features or customization, not available in stock Android devices or providing some of the devices with ability to run Android OS, which is otherwise not available for them. CyanogenMod (a regular customized OS) andBlackPhone (developed by SilenCircle with emphasis on security) are great examples.
This is the solution for businesses that involve mobile device management. It’s possible to create an Android stack that will provide any features and means of device management that they might require.
The best choice for mobile device management
As we said previously, AOSP is the only option for making advanced custom functionality. No other platform can give such opportunities of customization. There is a number of further benefits provided by AOSP:
• It’s an open source solution under active development. 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 lifecycle. 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.
• Changes can be introduced at every level of the Android stack:
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, Android Framework layer provides many higher-level services to applications in the form of Java classes.
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 easy working with them.
Main features of an MDM solution
MDM is a complex solution. However, it consists of modular small parts that after closer look are actually not that hard to implement, as long as an experienced team is involved.
All applications work with data. In our case, we have applications that work with sensitive data. Its types differ from business to business. Companies must tailor their smartphone policies to their specific needs and possible security threats in order to protect themselves.
For example, additional settings can be involved. An MDM solution would require to implement ways to deliver these settings to devices and make sure that the application is notified in case if these settings are changed.
If we are targeting Android 5 (and later), it’s all implemented already. All we need to do is use RestrictionManager and DevicePolicyMnaager.setApplicationRestrictions. Since it is a default implementation, we can also get additional restrictions for third-party apps that defined them. Unfortunately, we cannot be sure that they actually follow them. Default API does not allow to implement custom policies, so they have to be tailored.
We can implement device feature management on the device. What we mean is managing availability of such basic 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 would not be available. In this case, the best thing to do is to extend the existing API by adding methods, managers and services. It is done with certain policies on backend, which would be later pushed to devices. Then, a system service is created as a simple way of sharing these settings across devices.
Now it’s possible to work with WiFi, Bluetooth, NFC, Location tracking and USB file transfer. All of them are available for enabling and disabling in Settings, so it’s necessary to modify the way it works and make it correspond with the backend policies.
There are different ways to determine phone location: GPS, triangulation of position based on cell towers, WiFi networks and even Bluetooth. Most of applications that require user position for their applications to work will use every opportunity to do so. Once again, API customization is required.
No matter how simple each of the abovementioned operations are to developers, the final product will be complex. The amount of configurations and changes, that the product owner might want to add, may grow; the hardest thing is to divide complex features into small, modular and simple parts.
Every time a new idea for new functionality appears, we should carefully analyze it. The project should be started with minimum functionality; it must be done as soon as possible, and then the team will build further upon it until the final goal is achieved. Analyzing and building each feature in this manner will allow to spend less time and money on development of complex features and will allow easier changes in the future.
The expertise of the development team is a key factor in this case. An AOSP project is a huge and complex one; it will require time for any developer to get familiar with it. Every feature that goes beyond standard will take additional time for investigation and decision-making on how to implement it in the optimal way. Regular Android developers might not be familiar with these operations, so it is safer to find people that have experience in this particular area, in order to reduce deadlines and costs, and deliver the product just as planned — or just as the market requires.
Despite all the positive sides of mobile device management, there are always caveats that every product owner should be aware of.
First of all, selected devices must be ‘unlocked’, which may lead to loss of manufacturer warranty. After that, they must be locked with ‘fast oem lock’ to prevent launches of any system or recovery image on devices. The problem is that not all devices have the ability to lock/unlock. This means a limited number of devices to work with.
Second, we lose all Google Play Services — proprietary Google software with a variety of features used by developers. For example, Google Play itself is a system app and can install applications after download without asking for confirmation.
The best way is adding functionality, not customizing the existing API by changing its behavior. If it’s necessary to be able to add Google Play apps in the image, a ‘compatibility suit test’ must be passed successfully. And if it’s passed, it’s possible to apply for license to use Google Play services in this custom OS.
The abovementioned full control over the product is a double-edged sword. On one hand, it’s the power to change the Android OS substantially. On the other hand, the product owner and the development team will be responsible for delivering updates in time and responding to all issues that might arise.
Finally, there is a chance that a feature, that the team has just implemented and rolled out, is added in the next released Android version. Something that might be implemented for a customized Android 5, might appear in Android 6. That’s not a bad thing by itself, and it’s better just to focus on implementing something new and vital for your users.
This is how AOSP works for fulfillment of needs for advanced mobile device management. It brings great flexibility and opportunities to create a unique B2B product. And it only takes an experienced software development team to start doing it right from the very beginning.