Many have tried to find viable paths for the Android platform on traditional x86 architectures. Still, consumer and business use cases have remained limited to form factors like televisions and cars to date. In 2022, though, Android’s x86 “moment” feels poised to arrive – and probably not in the way you suspect.

Running Android applications in a virtual environment on Windows using the Hyper-V platform is likely where your mind first goes. Microsoft announced the availability of its Windows Subsystem for Android recently. Similarly, Google announced Android’s Google Play Games platform for Windows to play mobile Android games directly from a Windows device, also using virtualization tech. Both are breaking new ground in their own right, and I’m excited to see what comes next for Android on other operating systems. But gaming is just one chapter of the Android on x86 story.

Android on x86 is undergoing a much quieter (and arguably, more significant) revolution in the background of these high-profile consumer innovations. Businesses are paying close attention to the possibility of running Android, or an AOSP-based (Android Open Source Project) solution like Esper’s, on their existing x86 device fleets. And I have a secret: They can do it.

Android is reshaping digital transformation. On Feb. 24th, Esper and 451 Research will present data on how top brands in retail, hospitality, restaurant, and medical are leveraging Android for their fleet strategies. Register for our webinar here.

Flipping the Android x86 switch

The beauty of Android as a platform is its open nature. Much of what makes Android great makes AOSP great, minus all those Google applications and Google services (at a very high level, this is most of what distinguishes Android from AOSP). But running Android on an x86 device presents challenges, as nearly none of those systems or their respective chips have been targeted by the platform in recent memory. How, then, do you get Android on them?

Using AOSP it’s not as hard as you might think. However, you need lots of bits and pieces to get things humming, and you still don’t have anything resembling a commercial OS, given the limited partner infrastructure around Android x86. Someone has to construct all that. And there are no major device manufacturers out there building new Android products on x86 hardware aside from a few edge cases such as Android Automotive, meaning there’s effectively no official support for businesses using Android on x86 devices. (It’s worth noting, of course, that projects like Intel’s Celadon are trying to change that.)

With that lack of infrastructure from Google on the partner side, there’s little incentive for device manufacturers to experiment – after all, what good is building AOSP for x86 if Google is plainly all in on ARM64? The existing chip vendors have made Android on ARM a near turnkey solution with cooperation from Google, and the overwhelming majority of Android devices run on ARM processors from companies like MediaTek, Qualcomm, and Amlogic.

That all means if you’re going to do Android on x86 correctly, you need a solution that covers you from end to end. From identifying your hardware targets, optimizing your firmware, deploying your OS in the field, and finally distributing and updating your software on those devices over the air. Calling them “bits and pieces” may have been burying the lede a bit: These are the cornerstones of an Android x86 fleet strategy. Without them, you’re far more likely to waste time building tools than you are to drive innovation.

All that said, running Android on an x86 processor today is entirely feasible from a power user or developer perspective. Open projects like and Bliss OS are being flashed to devices every day! But for businesses looking to deploy, manage, and update Android x86 devices at scale, these projects lack all that critical infrastructure (read: “bits and pieces”).

The first step is the scariest

For any business looking into the viability of Android on x86, research is likely to yield cause for concern. Years of Android’s x86 failures litter tech news publications: everything from phones to smartwatches, to TVs, to tablets. What you won’t see, though, is much talk about the embedded x86 and other dedicated x86 devices in the enterprise computing world and whether Android would be a suitable solution for them. (I will spoil this: It is.)

Until recently, few companies outside the true tech juggernauts – Amazon, Google, Facebook – looked closely at Android as a critical element of their dedicated device strategies. That, though, is rapidly changing. More businesses realize that Android is the most extensible, iterable, and secure platform for creating great device experiences with an exceptional degree of control and customization. The seal has been broken: Android will never go back in the “just a smartphone OS” box. Google acknowledges this with platforms like Wear OS, Android TV, and Android Automotive (a platform so nascent it doesn’t even have a marketing website). Android is remarkable precisely because it can be made to fit so many innovative and varied forms, and I’m confident x86 devices are one of the platform’s next big frontiers, with or without Google’s blessing.

Why? Because as enterprises and other large organizations decide how to evolve their device fleets, they’ll be faced with several options. Simply ripping and replacing is one, and by far the most costly. Upgrading existing systems sounds great, but many of these devices are past their Windows End of Life date, closing the upgrade path. Leaving them as they are is an unpalatable compromise, but one that businesses are forced to take as they weigh two choices: One costly, one likely not even a “choice.” What if there was a third path?

Esper has the world’s first (and currently, only) commercialized x86 OS based on Android. Built using AOSP, Esper’s x86 OS provides exactly what world-class device and product companies demand of a platform: agility, speed, and control. Esper’s solution excels in all three – here’s how it works.

What’s old is new again

Imagine a 15 year old point of sale (PoS) terminal in your restaurant running Windows 7. The Intel Core2 was the hot new chip in town when this machine was purchased, but you’re probably running something much more modest – an Intel Celeron, perhaps. Even if you could upgrade that system to a newer Windows platform, it’s likely that it wouldn’t run very well and would potentially be missing features or introduce breaking changes to legacy applications. And, put bluntly, that’s not a device strategy. It’s a band aid.

What if you could wipe Windows off that system and replace it with Android? “That’d be swell,” you say, “but isn’t that going to be some kind of VM like BlueStacks, or an Android emulator hack?” Done cheaply and simplistically, sure: You could probably get an Android VM running inside Windows. But that creates performance issues and division of system overhead, which makes your already-slow and old x86 Windows system even slower. And you still have no one to support you if an app doesn’t work or a system becomes unstable or fails entirely.

Starting at bare metal was crucial when we approached the Android on x86 issue, because it enabled a true “flip” scenario for our customers (that said, we also offer dual-boot and virtual solutions for x86). When we began demonstrating our solution, our customers knew we were on to something. Something big. We also discovered something everyone loves: Performance improvements. Running our OS on x86 hardware, your old Windows machines will get faster. That’s because Android is a modern OS built on the Linux kernel, designed for ultra-low-power devices, but we’ll take the credit! And yes, we’ve got benchmarks. Stand by for the full suite in a later post, but I’ll give you a taste here.

Geekbench: Typical PoS OS versus Esper x86 solution based on Android

The test system in this example is PAR 8000 series point of sale device, a more modern system than we’re running for some of our largest customers, but one of fairly modest computing power. It uses a dual core Intel Celeron 3955U processor launched in 2015, with no support for hyperthreading. We ran Geekbench on it three times, in this case testing on Windows 10, and our own Esper x86 solution based on AOSP. Higher is better.

On Windows, the PAR system scored 428 and 838 for single and multithreaded workloads, respectively. On our Esper x86 solution, that same system scored 541 and 1026. For single-threaded performance, that’s an uplift of 26%. And for multithread, the gain works out to a bit over 18%. We understand that benchmarks are just numbers in a vacuum and that real-world workloads are where businesses make decisions, and we’ve got more data we’re crunching in the lab (OK, it’s a room full of cash register computers).

Geekbench 5 results on a PAR EverServ 8300 running Esper’s x86 solution based on Android

Imagine entire restaurants running Android on legacy hardware without getting rid of a single computer. Converting retail signage and kiosks running Windows to a modern, fully updateable operating system. You read that right: OS updates. Because the x86 architecture is highly stable and well supported by Intel, bringing new versions of the underlying OS for years – up to a decade. And that includes security patches.

Learn more about Android on x86 hardware

This is where you’re going to start having questions, and I hear you! Right now, we’re more than happy to answer them, but we do ask that you get in touch directly (come on, we can’t give everything away). If you’re a reporter and you want to know more about this mysterious Android-on-x86 business, hit us up at

If you’re a business or org looking to check out our x86 solution, your VIP access lane to one of our many knowledgeable human beings is going to be via booking a demo here. We’ve worked with Fortune 100 and NYSE 100 brands in the enterprise, and we’ve worked with scrappy consumer tech startups and local small businesses. We’re built for any scale, and we can work with you to build a custom solution, x86 or ARM.