Why Your MDM Won’t Work for AR & VR Devices

If you're working on a deployment of AR or VR headsets at your company, and wondering if your existing MDM will work… this article is for you.

December 10, 2021
AR, Hardware, Popular, VR

If you are tasked with managing the deployment of AR/VR devices in your company, this article is for you! While your enterprise likely already uses a mobile device management (MDM) solution such as Ivanti’s MobileIron, VMWare’s WorkspaceONE, or Microsoft’s Intune to manage your fleet of desktop, laptop, tablet, and mobile devices, these solutions do not seamlessly support AR & VR devices.

In this blog post we’re going to explain why traditional MDMs aren’t designed for AR & VR devices by taking a deep dive into the state of MDM software for Android Open Source devices without Google Mobile Services (non-GMS AOSP)––and detail what is needed for a sufficient AR & VR MDM.

Before You Dive In...

Let’s address the elephant acronyms in the room

MDM = Mobile Device Management

AOSP = Android Open Source Project

GMS = Google Mobile Services

DPC = Device Policy Controller

OEM = Original Equipment Manufacturer

BYOD = Bring Your Own Device

COPE = Corporate Owned, Personally Enabled

COBO = Corporate Owned, Business Only

COSU = Corporate Owned, Single Use

The majority of AR/VR devices run on Android Open Source Project (AOSP).
AR/VR devices do not integrate with Google Mobile Services (GMS) because Google does not have an approval path for AR/VR devices to become GMS certified.
Android Enterprise is Google’s latest response to the needs of the enterprise user, but unfortunately it only supports GMS certified devices.
MDM providers cannot extend the full functionality enabled by Android Enterprise to AR/VR devices since these devices cannot integrate GMS.
Android Device Administrator is Google’s legacy and deprecated solution for Android device management and, while limited in functionality & flexibility when compared to Android Enterprise, MDM providers can leverage this solution to offer support for AR/VR devices.
ArborXR, a true AR & VR MDM solution, leverages Android Device Administrator but goes beyond its limitations by building functionalities that are specific to AR & VR devices, such as support for large file sizes and a custom VR launcher. Where possible, the ArborXR team works directly with OEMs to gain access to system APIs and/or custom APIs thereby enabling additional functionality (e.g., management of the OEM’s OS updates).

What Software Do AR/VR Devices Run On?

The majority of AR & VR devices out in the market today run on Android Open Source Project (AOSP). Popular devices running AOSP include the Oculus Quest 2, Pico Neo 3, HTC VIVE Focus 3, Vuzix M400, and the RealWare HMT-1. The one notable exception to this is Microsoft’s Hololens, which runs on Windows Holographic, a special version of Windows 10.

Why is the AR/VR device ecosystem being built on Android?

AR/VR devices use the same architecture and foundation as Android phones & tablets (i.e., the Qualcomm-designed SoCs).
Android provides a great base for an operating system that is open source.
AOSP provides ample documentation and developer tools.
Real-time 3D creation tools like Unity and Unreal Engine support Android.

Unlike the mobile phone and tablet market, AR & VR devices do not integrate Google Mobile Services (GMS), which are a collection of Google’s APIs and apps like the Play Store, Chrome, Gmail, and Messages. This is because GMS is not a part of AOSP and there is no approval path for XR devices to get GMS certification.

What is Android Enterprise?

Android Enterprise is a Google-led initiative to enable the use of Android devices and apps in the workplace. The program offers APIs and other tools for developers to integrate support for Android into their MDM. Android Enterprise comes with its own device policy controller (DPC) app, which is provided by Google and incorporated into all devices running Android 5.0 or higher, so MDM providers no longer need to build and maintain their own DPC app.

Note that a DPC app communicates with the MDM web application to remotely deploy & apply configurations and content to devices, and is a crucial component of a MDM’s offering.

What is Required to Use Android Enterprise?

While Android Enterprise is a very robust solution for various enterprise scenarios, particularly scenarios in which (a) employees brings their own devices (BYOD), or (b) the company provides devices to employees which they then manage themselves (COPE)… the problem is that Android Enterprise is supported only on GMS certified devices.

This leaves the enterprise AR/VR device ecosystem in a tough spot––especially for companies with large fleets of AR & VR devices.

Remember that purpose-built specialty devices, like AR/VR devices:

Use AOSP
Do not ship with GMS integration
Do not have access to Android Enterprise APIs

BYOD

Bring Your Own
Device

COPE

Corporate Owned,
Personally Enabled

COBO

Corporate Owned,
Business Only

COSU

Corporate Owned,
Single Use

While Android Enterprise (released in Android 5.0) is Google’s latest and best solution for the needs of enterprise users, MDM providers that need to support non-GMS AOSP devices like AR/VR devices cannot leverage this solution, and, as such, their only option is to use Google’s legacy solution, Android Device Administrator (released in Android 2.2).

What is Android Device Administrator?

Android Device Administrator is Google’s legacy solution for enterprise users to manage their fleets of Android devices. On a technical level, this is a set of on-device APIs. It requires MDM providers to build and maintain their own device policy controller (DPC) app. Unlike Android Enterprise, which enables all the use cases detailed in the image above (including BYOD and COPE), Android Device Administrator is primarily meant for devices that are fully owned and managed by the enterprise (COBO and COSU).

Another pain point with Android Device Administrator is the lack of a scalable device enrollment solution. Whereas GMS certified (Android Enterprise) devices have flexible enrollment options, enrolling non-GMS AOSP (Android Device Administrator) devices is a manual and time-consuming task––and thus not ideal for companies needing an AR & VR MDM.

Practically this looks like hundreds of hours spent putting on headsets, typing in passwords in VR, etc. It is not a scalable solution for IT Managers with even a few dozen headsets.

MDM providers cannot leverage the robust functionality enabled by Android Enterprise on AR/VR devices because AR/VR devices run on non-GMS AOSP––but these devices can be managed by AR & VR MDM solutions, like ArborXR, that still support Google’s deprecated Android Device Administrator.

How Does ArborXR Overcome the Limitations of Android Device Administrator?

ArborXR offers functionalities that go beyond the scope of Android Device Administrator by building functionalities that are specific to AR & VR devices such as support for large file sizes and a custom VR launcher. And where possible, the ArborXR team works directly with OEMs to gain access to system APIs and/or custom APIs thereby enabling management of the OEM’s OS updates.

View a high-level feature & functionality comparison in the chart below.

	Traditional MDMs	ArborXR
Hardware Inventory
Policy Management
Remote App Deployment (OTA)
Wi-Fi Configuration
Remote Factory Reset
Easy Device Enrollment for AOSP Devices
Management of OS Updates
Content Library for Apps, 360 Videos & Any Other File Type
App Version Management Including Version Rollbacks
No File Size Restrictions
Enabling ISVs to Work with Companies & Share Content
Custom VR Launcher (Kiosk)
App Usage Analytics
Remote Launch VR Apps
Stream Device Output (coming soon)

The majority of AR/VR devices run on Android Open Source Project (AOSP).
AR/VR devices do not integrate with Google Mobile Services (GMS) because Google does not have an approval path for AR/VR devices to become GMS certified.
Android Enterprise is Google’s latest response to the needs of the enterprise user, but unfortunately it only supports GMS certified devices.
MDM providers cannot extend the full functionality enabled by Android Enterprise to AR/VR devices since these devices cannot integrate GMS.
Android Device Administrator is Google’s legacy and deprecated solution for Android device management and, while limited in functionality & flexibility when compared to Android Enterprise, MDM providers can leverage this solution to offer support for AR/VR devices.
ArborXR, a true AR & VR MDM solution, leverages Android Device Administrator but goes beyond its limitations by building functionalities that are specific to AR & VR devices, such as support for large file sizes and a custom VR launcher. Where possible, the ArborXR team works directly with OEMs to gain access to system APIs and/or custom APIs thereby enabling additional functionality (e.g., management of the OEM’s OS updates).

Why is a True AR & VR MDM Needed?

If you work in IT and have been trying to understand why your existing MDM solution does not seamlessly support AR/VR devices, hopefully this blog has provided a helpful explanation.

While MDM providers like Ivanti’s MobileIron, VMWare’s WorkspaceONE, and Microsoft’s Intune all support Android Device Administrator, they require a very manual device enrollment process that involves running ADB commands to sideload the MDM’s DPC app, then logging in within VR using your MDM credentials.

This is why an AR & VR MDM solution, like ArborXR, is critical for your AR/VR deployment. Not only is it a challenge to enroll XR devices to existing MDMs like MobileIron, WorkspaceONE, and Intune, but XR devices call for additional functionality that most traditional MDMs are unlikely to build.

Managing a fleet of headsets should be easy. That’s why we built ArborXR from the ground up to be a true AR & VR MDM.

Enroll devices in bulk without running ADB commands or logging in with your MDM credentials within VR.

Use almost any Android-based AR or VR headset running Android 7.1 or higher.

Build a content library of apps, 360 videos, and other file types––with no file size limitations.

Remotely deploy apps, 360 videos, and any other file types to devices OTA.

Leverage ArborXR’s custom launcher to lock down the device and configure the apps & settings end-users have access to, all while offering a branded experience within VR.

Manage certain OEM’s OS & firmware updates.

Group devices to manage content & settings in bulk.

Use ISV-specific functionality, such as content sharing, that enables ISVs to remotely share content (apk, mp4, etc.) to their enterprise clients in just a few clicks.