20 comments

[ 3.1 ms ] story [ 44.3 ms ] thread
Hmm. That's really handy at dealing with "download and use app to save %"

Sure. I'll make a VM, do the bullshit app, and pop the vm.

If there's no virtualization though then you'd need to find an x86 copy of the app right?
Most Android apps are just JVM bytecode and work on any architecture. Apps using the NDK (native development kit) are architecture-specific and often lack x86 binaries but ecommerce apps are highly unlikely to use the NDK.
Huh, I feel like I used to get tons of "app X wants to load binary Y.so" notifications with XPrivacy for quite a few apps... is it really that rare?
I wouldn't call it rare in general, but it seems pretty rare within the specific genre of ecommerce apps. Unless they use React Native, that requires the NDK.

I have an x86 Android tablet and it does emulate ARM binaries but the performance is bad enough that it is pretty obvious when you are running ARM binaries. I'm not sure how hard it would be to integrate libhoudini (Intel's ARM emulator) into this, if they ever even released the code.

Unfortunately libhoudini is proprietary. I don't think it's being updated for newer Android versions either.
Anbox is a great idea but it needs a lot of work to become a usable project. Currently, it's only available on a few distros, and app installation instructions are nowhere to be found.
> and app installation instructions are nowhere to be found

https://github.com/anbox/anbox/blob/master/docs/install.md ??

Or do you mean for installing Android apps?

(comment deleted)
What else would you install after putting Anbox into your setup?
(comment deleted)
Hopefully in the future it loses its dependency on systemd as well.
I'd love it if I could have both handset and server Android devices and they could talk to each other. Imagine running the server-side part of apps (e.g. always on, attached storage) on a bit of cloud that you own yourself.
Why does it matter what the backend OS is? Why does it need to be Android?
I think the idea here is that you would compile one native Android application that is running a single “distributed process” capable of spawning threads in both places, as if the phone and the cloud were two (very distant) NUMA noses of the same physical device. (Or, more practically, with the Android runtime doing transparent distributed RPC using a single set of static types that are marshalled between the client and server using something like protobufs.)

For this to work out, the devices really need to be either capable of running the same native code; or at least need to all be running an abstract bytecode VM with its durable state synchronized between them.

Has anyone tried running the Slack Android app with this? I am wondering if it would work better than the Electron based one available on desktop.