It’s time for another installment in our running series of articles on virtual mobile infrastructure. Brian wrote an introduction to VMI, I wrote about use cases, and Gabe talked about his DIY VMI experiment with BlueStacks. Later this month I’ll do a rundown of all the vendors active in the space.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
For this post I’m going to talk about various technical issues and different ways they can be solved:
- Putting Android in the data center
- App compatibility
- Remote protocols
- Managing Android
- Google Mobile Services
Putting Android in the data center
Like VDI, many of the challenges of VMI come from the fact that we’re taking a client operating system—an OS that expects to be on a local mobile device and have access to lots of sensors—and putting it on a server in a data center.
The first issue is processor architecture. Most Android devices run on ARM, most servers are x86. What do you do?
- Provide some sort of ARM emulation (usually QEMU). However even though you’re emulating ARM, there can still be app compatibility issues.
- Just use x86-compatible versions of Android, and x86-compatible apps. This is fine if you have apps that just use the Android SDK or are intended for x86, but if your apps have native ARM calls, then you’re out of luck.
- Use an ARM server.
- Use binary instruction set translation.
Once you have the processor architecture sorted out, the next issue is how exactly to put multiple Android users on a server (this is kind of like VDI versus RDSH).
- At one end of the spectrum, you can put a full instance of Android (including both the kernel and the user space) on a traditional hypervisor.
- But since Android is Linux, the concept of putting multiple user spaces on a single shared kernel is already well-known, and there are a lot of different ways to do this.
- Another approach is to just concentrate on whatever APIs an app needs to run. This can even mean publishing apps to multiple users from a shared Android user space.
A note on density: since mobile OSes and apps are designed to work with limited power resources and be conservative, this makes them relatively well-behaved when co-existing on a server. Often the bottleneck for VMI server density turns out to be remote protocol encoding.
Which apps will work on a VMI instance? That depends on two things: processor architecture and access to various APIs. Apps that just use the basic Android SDK and only call for basic AOSP APIs should be just fine. But many apps require direct access to ARM hardware, and sometimes emulation doesn’t work. Many apps also need to access APIs and apps provided by Google, collectively known as Google Mobile Services (GMS). GMS isn’t always available (more on this later) which will affect compatibility, too.
Like VDI, VMI virtual machines can be persistent or non-persistent, storing user data and then just restoring it to different VMs. But the big question is how long VMs remain active. VMs can be suspended for better scalability on the host, but there are problems because Android and Android apps expect devices to be powered on and active all the time. You don’t power down your phone every time you put it in your pocket—otherwise how would you get notifications or download content in the background?
There are a number of different ways to solve this:
- You can just let VMs run all the time, and have an agent in the VM that watches for notifications, pulls them out, and sends them them to the VMI client.
- Another option is to have an alternative service (outside of the VM) that can represent itself as the Android instance to the Google Cloud Messaging notification service.
- Lastly, you can just do everything completely independent of the VM and of Google Cloud Messaging and instead collect notifications directly from whatever services you need (for example, Exchange ActiveSync). The problem with this is that you’ll have to figure out every service from scratch.
Remote display protocols
Right now all the VMI remote display protocols are bespoke, but generally they’re based on H.264 or Motion JPEG, often with custom codecs. Today most VMI protocols work fine on Wi-Fi and 4G connections, but 3G connections can be questionable.
Besides remoting the display down to the device and touch events and keyboard input back up to the VM, many other channels are needed. For example, support for the camera, microphone and audio, video, screen orientation, location, client screen resolution, Bluetooth, multi-touch gestures, different keyboard layouts, and more. These
One big question that always come up with VMI is about offline usage. Even though VMI doesn’t work offline, there’s an argument to be made that since many mobile apps don’t work offline anyway, you won’t be missing out on that much.
At the same time, remember that a VMI strategy can still blend local traditional apps with VMI. Some VMI vendors are also working on “seamless” app modes, where instead of viewing an entire remote Android instance, users can have shortcuts from their local device directly to individual apps on a VM.
Managing Android phones and tablets has always been challenging since for many years, Android didn’t have many built-in management capabilities. Device manufactures would add their own customer management APIs to Android, but this resulted in a fragmented management experience. And even now that Android for Work is out, there are still challenges.
Fortunately, VMI insulates us from many of these problems. (In the VM... VMI clients will still have to deal with all the device fragmentation, but that’s a known issue.) VMI vendors, just like phone and tablet manufacturers, can customize Android for their needs. This means the Android used in VMI can have many enterprise-friendly features:
- Controls to provision apps, accounts, and settings
- Granular control over app permissions
- Deep security inspection
- Control over updates and patching
- Everything’s running in your data center, where you have as much control as you want.
Google Mobile Services
We often talk about “Android,” but remember there are really two versions: There’s the Android Open Source Project, and then there’s Android with all of the Google Mobile Services (GMS) which includes things like the Play store, Maps, various apps, and more. When most of us think of the “Android” experience, we’re talking “Android plus GMS.” Many of the apps we need—including apps for work—rely on Google in some way or another.
To use GMS, device manufactures (or in our case, VMI vendors) must be able to meet certain compatibility requirements and gain certification. At the time of writing, this hasn’t happened yet, but a few VMI vendors tell me they are very close. This will be a banner event for VMI when it happens, but in the mean time there are a few alternatives:
- I’ve used and seen VMI product with GMS, but these are for trial and testing purposes only.
- Another option is to use alternative services, or to emulate GMS.
- If you’re building apps specifically for VMI, you could work around the lack of GMS.
- Some companies might want to avoid GMS altogether, for security reasons.
This may seem like an intimidating list of challenges, but remember that there are six different vendors that have been putting a lot of effort into making VMI work. My next installment will give an overview of the field.