Android 4.4/5.0 OOB?


I would like to see an android ROM that can be run from SDcard as an alternate boot.
 
Cool. It might already work on arm devices too:

Does Anbox need a specific Android image for every device?
No. Anbox does not need a specific Android image for every device as it's is especially build in a device independent way. Anbox will ship with a single Android image per architecture (amd64, armhf, arm64) and no device specifc modifications are required.

Is someone up to trying it on Pandora ?
 
I'd love to see someone who's working on the Pyra OS weigh in on this. Will it possibly work?
 
I'd love to see someone who's working on the Pyra OS weigh in on this. Will it possibly work?
I don't work on Pyra OS, but the aims of Pyra OS and Android compatibility don't seem well aligned to me. The aim of PyraOS is to make the best linux computer OS possible, and that means using a new and unpatched kernel. Android kernels are older, patched with shit, and running various open and closed source kernel modules. That means you can't expect an android userspace to run on top of the Pyra kernel. That leaves some kind of virtualisation, which as far as I know the OMAP5 doesn't have many features to help you with, so I think you're left looking at some kind of emulation, though it need not be as slow as an emulator for a different architecture, it could perhaps do live patching of the android system in order to keep it in a sandbox, but I can't see that happening very quickly at all.
 
Anbox looks pretty promising!

Note to whoever finds the time and inclination to bring this to the Pyra - please set it up so it can be installed multiple times and run in separate instances. Why? I want one android sandbox / container running for work apps and one for games.

But - yes - that looks very promising indeed!
 
OMAP5 doesn't have many features to help you with
The Cortex A15 is actually one of the few ARM32 cores to have hardware virtualisation support. Unfortunately, this was little used and support for it is being removed upstream. Either we will have to maintain it ourselves, or convince the maintainers to reinstate it with a good use case, if we do want to use it with newer kernels and Qemu versions.
 
Not to begin with but the danger is it could increase at any time, as the base kernel code diverges from where it is now, and you might need to understand anything that's changed to be able to port the existing code to it.
 
Back
Top