Partner Blog
/ Zebra
It feels like it has been eons since Android™ 1.0 was first introduced in October 2003, and it’s still hard to believe that its creators initially intended for it to improve the operating system (OS) of digital cameras! To say that the Android OS has changed the wireless communications landscape would be an understatement, as it is now the most popular smartphone OS in the world, capturing about 86% of the market as reported by IDC.
The Android OS is also powering millions of enterprise-grade handheld mobile computers, tablets, wearables and vehicle computers used by front-line workers around the world to provide essential goods and services to our communities. It’s significance in modern society compounds by the second.
As Android mobility solutions becomes more prolific in the workplace, though, more must be done to ensure that these technologies run optimally at all times. Even the slightest decline in device performance can impact worker – and subsequently, organizational – performance. That is why companies like Zebra, which has offered Android-based, ruggedized devices since Android Jellybean (Android 4.3), are committing a lot of resources to the development and implementation of lifecycle management solutions. We want our Android mobile computers to last as long as possible for customers – through multiple OS version upgrades. Just as noteworthy, we want to make it easy for customers and end users to maintain the devices “in the field.”
That leads us to the topic of the day: device management.
According to Dave Dwyer, Senior Solution Engineer at VMware, a Zebra Independent Software Vendor (ISV), if you’re using a modern Android mobility solution, then you shouldn’t be using a legacy management strategy. The engineering, sales, support and service teams at Zebra agree 100%. Yet many organizations are still using the same Device Administrator tool they used 10 years ago to configure, secure and upgrade new devices. So, we connected with Dave to learn why that’s a problem and understand what new Android device management options are available. Here’s an excerpt from that discussion:
Your Edge Blog Team: Many companies – including Zebra’s customers – have been managing their Android devices using the same tools and methodologies for well over a decade now without issue. Why do they suddenly need to shift their approach?
Dave: Through normal device attrition, cap and grow, rip and replace, and OS upgrades, the majority of Zebra Android devices in the field today are running Android 7.1 (Nougat) or later. To manage application updates, configurations and policies on these Zebra corporate-owned devices, many companies still use a legacy approach to device management called Device Administrator, which dates back to Android 2.2 (Froyo). That’s a problem, for a number of reasons. The biggest reason is that, as of Android 10, Google has announced the removal of Device Administrator application programming interface (API) policies used for legacy Device Management and replaced them with the Device Owner APIs in the modern management platform approach called Android Enterprise. If you don’t migrate your device management process over to Android Enterprise, then you risk being left behind without the functionality needed to manage and secure your fleet.
Of course, that’s not the only reason why you should move away from legacy device management using Device Administrator APIs in favor of Android Enterprise. With legacy device management, you may notice inconsistent results and even poor user experiences when using a mix of vendor devices due to fragmented Device Administration API offerings across device manufacturers. Remember, not all device manufacturers offered the same Device Administrative APIs. Enrollment methods can also differ substantially among device manufacturers and device management solution providers.
Your Edge Blog Team: What do companies stand to gain, then, by moving to Android Enterprise for mobile device management?
Dave: Quite a lot. To start, Android Enterprise provides a common set of Device Owner APIs across manufacturers, leading to more consistent management results and a better user experience. It also offers a basic set of standardized methods for enrollment across device manufacturers and device management solution providers. These methods include QR Code Enrollment, Near Field Communication (NFC) Bump Enrollment, DPC Identifier Provisioning, and Zero Touch Enrollment to go along with mature proprietary solutions like StageNow from Zebra.
In addition, Android Enterprise provides Factory Reset Protection to prevent users from maliciously or unintentionally wiping a device. It gives you the ability to silently install public applications using the Managed Google Play Store without the need to enter Google Play login credentials, as was required with Legacy Device Management. It offers managed configuration for applications, meaning that corporate settings can be deployed along with the applications. This allows for “same day” feature enhancements to be deployed with the applications. And, as I believe you’ve previously spoken with Adam Arruda about on the Your Edge blog, Android Enterprise features OEMConfig, which is a way that device manufacturers can expand upon the standard Android Enterprise Device Owner API set to differentiate them from other vendors.
Your Edge Blog Team: Is there any reason why someone would not want to migrate to Android Enterprise? Or any reason why they shouldn’t migrate?
Dave: Anyone with eligible devices should be migrating to Android Enterprise for device management. The new standards and management methods offered in this environment are simply superior to the legacy Device Administrator toolset, and continuing to use Device Administrator is going to result in the loss of manageability at some point – if you’ve even retained full management capabilities to date. There’s also the complexity of trying to manage your device fleet using a cap and grow strategy: Device Administrator for the legacy (yet to be migrated) devices and then Device Owner in the newer devices that were deployed from day one with Android Enterprise.
That being said, I know some organizations struggled to migrate early on – back when Android Enterprise and Device Owner policies were first offered with the Android Nougat OS version – because a factory reset was required. To ensure the security of a device, Google initially required that any “Device Owner” enrollment in an enterprise mobility management (EMM) platform would have to occur on a factory fresh device. This became a huge burden for our customers who had already deployed devices and were trying to migrate to Android Enterprise as it is very risky to try to reset and re-enroll with devices in the field and just as costly to ship all devices back to a central staging facility to manage that process in a more controlled environment. Plus, there’s always the risk that devices will be lost in transit.
With and Zebra and VMware both highly committed to Android – and to our customers’ success with Android mobility solutions – we immediately started looking for a workaround when we learned of this issue, as this factory reset was a clear barrier to adoption for Android Enterprise.
Zebra took the lead, working first to understand why Google required a factory reset. As it was quickly learned, Google wanted to ensure that any user or customer data on the device was not compromised – the factory reset was a proactive security mechanism. The concern was that a newly installed Device Owner would have increased permission on the device, and if an untrusted Device Owner was installed, it could compromise data.
So, the Zebra team started to explore ways in which customers could directly transition from Device Administrator to Device Owner in a secure manner that met Google’s intent without requiring data to be erased via the factory reset method. Zebra designed and proposed to Google a secure approach that allows Device Administrator to Device Owner porting in a secure manner using unique certificates pushed to each device and Zebra’s mobility extension (MX) framework to validate that the Device Administrator and Device Owner clients were valid and trusted. The Zebra team then reviewed the approach with Google, explaining how important this capability was needed for its EMM partners, such as VMware, and our mutual customers to make the move to Android Enterprise. Google agreed and approved the approach, even changing the Android Compatibility Definition Document (CDD) to allow for it.
Once Google signed off on the proposal, Zebra reached out to its EMM partners, including VMware, to outline the new Android Enterprise migration process as well as the requirements that everyone would have to adhere to in order to make this approach possible. We – VMware and other EMM partners – then had the freedom to build out a more complete migration solution that would work for our customers. We worked closely with the Zebra team to then co-develop the Workspace ONE migration tool offered to VMware customers today.
Your Edge Blog Team: It sounds like there’s now a clear migration path to Android Enterprise for organizations currently using legacy device management methods on corporate-owned rugged devices, such as Zebra mobile computers and tablets.
Dave: There is, and customers actually have two options. The first option, depending on the device management solution being used and the current Android OS version running on the Zebra rugged device, would be to completely unenroll any legacy managed device from the device management solution and then re-enroll it using an approved Android Enterprise enrollment method. But I want to stress that this could be a very expensive and time-consuming task depending on the number of devices being managed and the logistics surrounding this effort within each individual organization. It’s also important to note that only devices running Android 7.1 or newer OS versions are eligible to enroll Android Enterprise. Anyone still using devices that run on older OS versions will either need to upgrade them or continue using legacy device management methods.
That’s why I always recommend the second option for those using VMware Workspace ONE UEM v20.06 or higher with Zebra rugged mobile devices (Android 7 or higher and MXMF 7 or higher), which is the Workspace ONE solution that VMware and Zebra co-developed – the one I just described – to migrate legacy managed devices to Android Enterprise.
Your Edge Blog Team: Can you tell us more about the specific advantages to using the Android Enterprise migration method that VMware and Zebra co-developed?
Dave: One of the biggest advantages is that the migration is done remotely and silently. There is no need for remote logistics support as this is a hands-free approach. That’s right: no scanning and no button clicks. It’s completely hands-free! Plus, devices do not power off, reboot or reset during the migration, ensuring app data remains intact. We also designed it to ensure Wi-Fi connectivity is maintained during the migration and that products which do not contain profiles remain installed. Plus, migration to AOSP/Closed Network mode is fully supported.
We spoke about these benefits as well as the overall benefits of Android Enterprise in a recent VMware-hosted podcast with Zebra’s Adam Arruda. (You can check it out here.)
Your Edge Blog Team: Any final thoughts that you’d like to share with readers?
Dave: Considering the journey from Android 1.0, to where we are today and the direct impact of your Android mobility solutions on your business, you need to deploy the best software solutions you can today in order to be fully prepared for the future. Zebra and VMware have a strong pulse on what you need, mostly because of our collaborative innovation strategies with customers like you. If you’re ready to move forward with Android Enterprise and want to learn more about how the Zebra and VMware migration tool works, please contact us. We want to make your job as easy as possible – and your devices as easy to manage as possible.
###
