Winlator is an Android application that lets you to run Windows (x86_64) applications with Wine and Box86/Box64.
↫ BrunoSX
That’s all you need to know. There are videos up of things like Mass Effect 2 and Fallout 3 running through this, which is incredibly neat. I’m not entirely sure what the use case is, but who cares – this is an excellent idea.
This is why I was excited about the X86 smartphones. I still have one here, a Zenfone 2. The battery is garbage at this point, I can’t decide whether to try and change it or just dump the phone. I mean the phone is kinda rare, so maybe I would be better off keeping it.
What’s really disappointing though is how Intel pulled out of X86 for Android and support for this thing was basically abandoned. I was expecting it to get very good support like a PC does, since X86 is a standard.
Unfortunately Android isn’t architecture-independent, it has something called the Android NDK that allows native apps written in C and C++, most OpenGL and Vulkan Android games are actually native C and C++ apps. Google had to do this to make porting from iOS easier.
This means that if a game doesn’t have a corresponding x86-64 version (and a surprising percentage of them don’t), emulation is required, and performance will suffer. In some games, Intel’s emulator even led to crashes.
This meant any x86-64 SoC started with a huge disadvantage. Now add to the fact Intel’s 4G modems tended to suck, so you had another disadvantage too.
To be fair, the standard Android application model is to use Dalvik ( Java ) such that applications can be hardware independent. You are correct that many applications, especially games, choose to use “native” code instead as they value portability between operating systems more than portability across architectures. That is really more the fault of the applications than of Android itself.
Even if you ignore the issue of existing code, the market has its way of banishing apps compiled to made-up instruction sets and running emulated inside virtual machines, at least in areas where performance and latency matters (such as games and multimedia).
Google realised this, so they quickly allowed Android to run “native” apps. Problem is, fulfilling this market requirement made Android not architecture-independent. So, in a sense, it was Google’s fault for not seeing this entirely predictable result happening.
Dalvik is still good for minimizing the blast radius of exploits for apps that use it, so it’s not a total loss. But Google could have achieved the same with a hypervisor (like all modern videogame consoles do) without the emulation cost. They kind of hid the issue with ART (aka ahead-of-time translation) and by shipping pre-translated binaries for ARM, but the cost is still there even if reduced.
Anyway, I still don’t see any benefit from having x86-64 on your smartphone. I am not aware of VT-x being available in Android or any VM software that uses it.
About your phone, any half-decent repair shop should be able to change the battery. This will allow you to eke a few more years out of it before Google pulls Play Services support (and most of your purchased games stop working due to DRM issues).
But how does x86-64 benefit you? Can you have VT-x on Android (and what VM software do you use)? Because whatever raw performance advantage the Intel Atom may had is long gone.
There are definitely use cases for this, but not necessarily for the Android. What I’m talking about is that this technique allows for running Windows x64 software on any ARM host, including SBCs such as Raspberry Pi.
This project is specifically for Android and bundles everything nicely into an “app”. You are correct though that he is relying on tools which are more general. WINE is obviously translating the Win32 calls into Linux ones. Box86 and Box64 are being used to emulate an Intel CPU underneath. You could use those tools directly or package them in a more general way for Linux on ARM.
iOS isn’t the reason Android apps use native code, it’s because (1) Java performance is terrible, (2) noone wants to rewrite thousands of lines of C/C++ code in Java to produce an Android version of their app, (3) Java is awful so the less of the program that uses it,. the better.
Most performant Android apps are written in native code with just the minimum required amount of Java for handling the GUI.