New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Just because the JVM is multiplatform, doesn't mean's it runs natively, any system call made will have to be emulated via a hook or made against a virtualized kernel.> @dev_vps said:
LOL, WSL is a Linux in a VM
WSL 1 is not a VM. Won't require any virt features to be enabled.
On the other hand WSL 2 is a VM. Uses hyper v underneath.
WSL 1 emulates system calls, that's also not native
WSL 2 is Hyper-V with Linux VM, that's also not native
None of them are native, but system call emulation is akin to wine, low overhead.
As for 2, hyper v or not is not the point. It's a VM and there are various winapi to manage vm's like whpx.
The only possible way for Android apps to run natively on Windows is for Windows to switch to the Linux kernel which will never happen.
I just remembered trying to emulate Android via Android studio and that thing would take like 10 minutes to boot. That's as much knowledge as I have with Android emulators.
This whole discussion with @dev_vps is whether Android apps can run on Windows natively, the answer is no.
@dev_vps keeps saying yes, but the answer is no.
None of this is about how Hyper-V and the Windows virtualization API works specifically.
I have less tech knowledge than you but I also think what you are saying makes sense.
Agree.
Feel like ppl confusing a lot of terms with each other. Native application simply mean the application is designed and compiled for a particular platform in mind. Running it on another platform seamlessly doesn’t mean that now the application can run natively on both.
(Although really the term native is really vague imo, just one of a lot of jargons that spew up from mobile app development)
There are a few rare cases such as custom written/generated multi-architecture (ARM/x86) or multi-platform (Linux, Windows) single binaries that takes advantage of executable formats (ELF/EXE) and OS process init behavior to allow a single file to run on different architectures or platforms (sometimes even both) without any change to the file and importantly does not include/rely on a runtime, interpreter, or VM (such as JVM).
This rules out copying bytecode from Kotlin/Java and running the same code on a Linux JVM and Windows JVM. This also precludes copying a Python script between a Linux and Windows installation of CPython.
The fact of the matter is, running Android in a VM or full blown emulator is nowhere close to any respectable definition of running natively.
This is rather interesting, do you have an example? I would love to see it. My understanding at the moment is limited at cross compilation only, in which I still need to produce multiple binaries regardless.
Probably not even that. When you dissect Android you'll find that it's very much not Linux in any way beyond using the kernel. There is a ton of custom services and apps don't talk directly to the kernel anyways (outside of jni use) but there is a shitton of java apis layered on top of it for the actual apps to use.
Look up Fat Binaries and Universal Binaries.
Most commonly they cover multiple CPU architectures by intelligently packing the code of each architecture into a single file and taking advantage of OS level calls to initialize the process to operate on each of the supported architectures. This is the dumb but simplest way of achieving multi-architecture binaries.
There's multi-platform binaries, these are more difficult to create due to OS level differences, but with carefully crafted compiled code it can be done, see the cosmopolitan project on Github: https://github.com/jart/cosmopolitan
The above tool can help you generate a single binary that runs on: Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS
And the above is truly native, none of that WSL or Windows Subsystem for Android "native" srtuff.
There is a bunch of very weird things as far as hybrid executables go. I don't think hybrid exe-elf has been archived/is possible but there is lot's of ps-sh, vbs-sh and similar. The closest to an actual Lin-dows binary is probably a com-elf hybrid (or maybe exe-sh?). Don't quote me on this though. It's more of a curiosity thing in my opinion so i didn't spend a lot of time on this.
If it doesn't rely on any Android OS specific features (directly or indirectly), it's not really an Android specific app at that point, such that's no need to run a Android/Linux VM.
You would just extract the bytecode, plop it on the JVM for your platform and run it.
It would just be a JVM based app you're running on Windows and the argument is moot as we are no longer talking about "running Android apps" on Windows "natively". We're just running a standard JVM app as this point, no special need for emulation/virtualization and lots of system resources saved.
It exists, it's real and is compiled (not pseudo-shell execution)
I've never argued for being able to run those apps natively or rather as-is (natively might be a bit ambigous?). Sure an android spin-lock-app would probably also work on windows as-is but beyond that there needs to be at least some kind of compatibility layer.
Do you have any links for this? To my best knowledge it's not possible to overlay exe and elf headers while still keeping both valid (enough) to actually run.
Well everything boils back to this statement from:
Interpret that as you will @totally_not_banned . But in my books, running a VM/emulator as Windows 11 does via WSA is not in the slightly sense natively.
Lol, why do you keep arguing when i practically say the same? One could even say that it's not possible to run java bytecode natively. I just think natively might be a bit misleading as in people thinking "natively = doesn't require emulation" and it's probably (at least in theory) possible to run Android apps without emulation just like WINE means Wine is not am Emulator.
I'm not saying I disagree with you, I'm saying we are moving away from the original context which was Android apps in Windows 11 via a VM constituting "native" execution.
WINE is infamous for it's acronym, but is functions effectively as a Win32 API wrapper, shimming the Win32 API against the Linux kernel along with a bunch of other compat layer code. While it doesn't act like a fully blown emulator, it translates lots of OS level calls. I would find it difficult to call this kind of shim "native" execution.
All of the above ignores CPU arch differences if not compiled for the corresponding CPU architecture. Meaning is the app package is targeted for ARM, it's using either hardware accelerated or software level ARM -> x86 translation (akin to Rosetta).
We need to get a kernel level programmer of Linux and Windows, a professional linguist, ISA engineer, polyglot, etymologist, historian, OS engineer to spend the next eternity debating "natively" and I will happily join in.
LET will be the perfect forum to debate until the end of time until we can prove @dev_vps wrong or right.
Will you join me @totally_not_banned ?
I know next to nothing about Windows but in theory a VM is not needed here as (outside of JNI which is quite uncommon with Android apps i think) all of Androids APIs are pure Java so to the app itself it's irrelevant which kind of kernel is running below that. Obviously the Java APIs need to be provided for the app to actually run. Kind of like how Wine provides the Windows API to the code it runs. Admittedly where emulation starts is a kinda murky topic. At least Wine's interpretation is that simply providing a given API is not emulation though.
Like i said, native execution is kind of weird already when talking about Java bytecode. I'd rather use the term native in relation to architectures (even though your intention is still quite obvious) and in my opinion it's hard to classify Java bytecode in this regard. To run natively on would have to assume it to be kind of an architecture, which i feel is somewhat off.
Well, CPU differences are moot when it comes to Android apps (again outside of JNI) as they are plain Java bytecode and don't make any assumptions about the CPU they run on.
The moment that a full blown OS VM (not just a JVM) is used, it's not native anymore, we agree on that.
WSA uses an Android VM. Therefore, using it to run Android apps is non-native.
We have an agreement, and I go off to find more chicken.
Like i've said, i feel the term native is a bit weird here. Obvious in intention but weird.
We never had a real disagreement. Just a slightly incompatible terminology
Back to the original point,
@threalatm , get a dedicated and run Android VMs or containers as bare metal as possible instead of having nested virtualization with Windows Subsystem for Android or BlueStacks with virt enabled.
Seconded. Android x86 in Qemu has worked quite well for me in the past.
Anything which requires a bunch of phones but you don't want to buy the phones.
So sneakers are still a thing?
This is what the OP should do in the first place. Forget Bluestacks.