Introduction
In the world of smartphones, iOS has been dominating in the workplace, at least in the United States. The most recent data from Q2 2015 shows that iOS has a 64% of the device activations. However, Android has been and is gaining ground. The introduction of Android for Work by Google demonstrates Google’s commitment to the enterprise market. Whether a company is wanting to save money by deploying less expensive Android devices, allow employees to bring their own phones, or roll out a global program where Android is more dominant than it is in the US, companies need to have a strategy for how to manage Android in the workplace.
The use of personal phones at work is a given. These are often in the form of Bring Your Own Device (BYOD) phones, or corporately-owned, personally-enabled (COPE) devices. In addition, the questions that come from these devices surround topics such as security, data protection, application usage and management. This article will provide some best practices for such deployments.
BYOD and COPE Devices
In early 2015, Google formally introduced its Android for Work program. At Google’s press event on September 29, 2015, Sundar Pichai announced that over 10,000 business have tried or are using Android for Work (AfW), and the number is growing quickly. AfW addresses one of the main concerns with BYOD and COPE devices: the fact that they contain both personal and work data. Neither wants to be compromised. AfW does this by creating separate profiles (also sometimes referred to as “containers”) for applications and data on Android devices. The profiles separate work and personal data, providing better security and data protection.
Android Versions
In Android development circles, the Android “f-word” is “fragmentation”. Fragmentation refers to the number of versions of an operating system that are currently in use, and in some sense, the variety of devices (different screen sizes with different resolutions). For developers these differences can be a challenge. Google has actively worked at reducing fragmentation by adding device compatibility libraries into Google Play Services (aka GMS). Google also restricted the time window for device certification so that more devices are running newer versions of Android. Thus, the fragmentation problem has and is improving.
Some of the past problems of using Android in the enterprise are also disappearing. The ability to deploy Android 4.x or earlier in the Enterprise was difficult with respect to Enterprise Mobility Management (EMM) software. Before Lollipop, each EMM vendor, like SOTI, Airwatch, and MobileIron, had to work directly with the manufacturers (like Samsung) for management support. With Android 5.0, AfW is integrated into the OS, offering complete managed profile support (work and personal).
Best Practice: When deploying Android in the Enterprise, use Android 5.0 or higher for BYOD and COPE environments.
Android 4.0-4.4 does have support for the Android for Work app, but it lacks the fully-integrated managed profiles. In addition, the integrated AfW introduced in 5.0 allows you to use Google Apps for Work as your Enterprise Mobility Manager (EMM), or you can use a Google-approved EMM provider.
Security and Data Protection
While encryption was available in previous Android releases, Android 5.0 “Lollipop” brought fast encryption, which encrypts only used blocks on the data partition. Lollipop also brought hardware-backed storage of the encryption key. Encryption is mandatory for AfW. The encrypted data, along with a lock screen (see below), means that someone cannot access the device data, or plug a stolen device into a desktop computer and extract information that may be stored in flash memory.
Samsung has led the way on Android devices in supporting fingerprint security in their phones. Google standardized this fingerprint security support in Android 6.0 Marshmallow. Their new Nexus 5X and 6P phones provide this support, and it is expected that Samsung will also support the standard Android fingerprint functionality, in addition to their own. The fingerprint support can be used in applications, like banking or VPN software, or be used to securely lock the device when it is not in use. It allows the user to unlock their device with their fingerprint. Maintaining a lock screen (also referred to as the keyguard) is critical for protecting data. If an employee leaves their phone at a restaurant or in a cab, the data may not be accessed.
Best Practice: If possible, choose an Android device with fingerprint security or require users to use a PIN code or password lock screen.
In our next section, I will discuss remote management, including the ability to control applications that are installed on a device. Somewhat related, and for security reasons, ensure that your users do not enable “Unknown sources” in Settings. This will prevent side-loading of applications, or loading apps that are sent by email or on a web server other than Google Play. With AfW, you can prevent users from installing from unknown sources into the work profile. (But, for BYOD, you can’t prevent the primary user from installing from unknown sources outside of the work profile.) For more information on AfW Security see this Google information.
From time to time, you will see articles about security vulnerabilities in Android. Some of this information is inaccurate and misleading, and not unique to Android. Other articles show legitimate vulnerabilities. I do know that Google takes security seriously, as demonstrated in their whitepapers and regular security updates. But, with any OS, security holes are found. The key factor is how quickly they are fixed. According to AndroidVulnerabilities.org, some vendors provide better support for security patches than others.
Best Practice: Reduce delays for security updates by purchasing the brands that have the best security scores. Avoid Carrier-specific phones, if possible, as this generally increases the delay.
In addition to the VPN support available in Android for a long time, Android for Work allows app-specific VPN connections that can be automatically utilized on a per-application basis through EMM software and configuration. The AfW Security link above references a security white paper that mentions this capability.
You can find additional Android security resources here. A key point regarding Android security is that work-managed devices (corporately owned with an AfW primary user) provide greater control to place limitations on the device.
Remote Management
Using Android for Work gives you the ability to remotely manage your organization’s Android devices. Android 6.0 Marshmallow allows you to do silent installs and upgrades. This feature is especially important for COSU devices, which will be discussed in the next section. Software is installed or upgraded through your EMM software. If you’re already a Google Apps for Work (or Education) subscriber, you can use the Admin console to manage the AfW devices. The Apps for Work management console provides the ability to whitelist specific apps in a Google Play for Workstore that is specific to your Google Apps domain. It gives you the ability to purchase bulk licenses of paid software.
Best Practice: Configure your Google Play for Work store for your organization, and whitelist applications for your team.
Your particular environment may require restriction of some device features. For example, you may not want the users to capture photos with any work app. AfW provides the ability to disable certain device features. Full control of the hardware features, however, may be specific to your particular EMM provider. Android and AfW offer many configurable policy APIs, but not every EMM provides a means to control all policies.
For security, if one of your Android devices is lost or stolen, AfW provides the ability to remotely wipe the work container on a device. For BYOD devices, the personal container remains intact (and can be wiped separately by the owner of the phone using Android Device Manager or other software).
COSU Devices
Many companies have need for single-purpose handheld devices, such as those used in a warehouse, transportation, field service or other one-task environments. These company-owned, single-use (COSU) devices often have integrated data collection or sensors: barcode scanning, RFID, CAN bus, etc. Examples of these include the Trimble Juno T41, Arbor Gladius 8, Bluebird BM180, and Zebra TC70. (Note 1/28/19: We no longer sell the BM180, the Gladius 8, or the Juno T41. Please contact us for other options.) Because they have additional hardware support, their Android release version often lags behind the consumer devices. For COSU deployments, Android with a version of 4.x is fine if it works with your environment (EMM provider, or in-house IT staff). Install apps through your IT department or EMM provider software.
In some cases, you may not want to have the Google services installed on the device. This is especially true for Android 4.x devices where AfW is not fully integrated, or for non-connected vertical-market solutions (e.g. medical devices). Devices that do not have Google Play Services, the Play store, Google Maps, or other staple Google apps, are running the Android Open Source Project (AOSP) code.
Best Practice: Ensure that your EMM provider or IT department can manage COSU devices that have an Android version older than 5.0, or any OS version that is based on AOSP.
Devices that run AOSP may or may not have the features that your application or solution provider needs. In this case, be sure to check with with your app provider to make sure that they are not relying on Google Play Services for their app. Also, check with your supplier of the AOSP device and them about the results of the device’s Android Compatibility Test Suite (CTS). Don’t buy a device that has not passed tests that are pertinent to your application. For example, a device may not pass all of the multimedia tests, but if you’re not running a video or streaming application that probably does not matter. It should pass all core tests, or it may not be compatible with your application. Some low-cost device manufacturers may cut too many corners in developing their AOSP device.
I expect that 2016 will bring a range of COSU devices that are running Android 5.0 or higher. That will significantly improve the manageability of COSU devices through Android for Work, and the ability to set the device owner.
Conclusion
The mobile market continues to change rapidly. As a director, VP, CIO or influencer of an enterprise organization, you have many business needs vying for your attention. You should work with a vendor who is following the Android market closely in order to provide the information that you need to make the best decisions for your organization.
Best Practice: Have a trusted advisor.
At SDG Systems, we seek to stay current on the latest developments in Android. Our CEO, Todd Blumer, regularly attends trade shows and Google events, and is an active member of the Enterprise Android Forum, a consortium of enterprise device manufacturers and system developers.