Discussion: Ship with ashmem_linux and binder_linux Kernel modules

[egrath]

There’s a question, that every now and then pops up in the community board: “How to run Android applications on Endless”. Now, there’s a good working Android Runtime available for Linux, namely “Anbox” which currently provides a Android 7.1.1 environment.

I spent a few hours building it for Endless OS, but run into the issue that two kernel modules are needed for it to work:

1. ashmem_linux
2. binder_linux

The first one is already shipped, the later one unfortunately not. So my question is, if there is interest in including (2) with EOS for making Anbox work with EOS in the future.

Personally, i’m a little ambivalent about Anbox on EOS in general: On the first side, it will open up the OS to a whole new level of available Software. On the other hand, it may increase the volume on Questions about not working Software on the Boards, as not every Android app is designed to work outside of a Phone/Tablet.

Your opinions?

[Gilgamesh2]

Great Idea, “Not Every Android app is designed to work outside of a phone/tablet” who cares? those that will work will do! Plus it opens whole new possibilities

[Daniel]

Thanks for the suggestion and research. It would be great to have the Android app ecosystem available on Endless, but as you mention, I also have doubts as to how good the user experience would be, these types of things tend to have profound limitations.

I don’t see us pulling our internal focus away from our current projects in order to work on this, and we are actively trying to reduce our deviation and maintenance in other areas - i.e. we are working to reduce our Endless-maintained kernel patches, not add new ones.

I think the two most likely paths forward are:

1. binder gets included in mainline Linux, or some other solution is developed where you don’t need to run a special kernel to make this a reality
2. Endless opens up the ostree builder source code and infrastructure, this would allow an interested 3rd party to produce a variant of Endless OS with a custom kernel including changes such as this one

[egrath]

Hello Daniel,

both of the modules are already in mainline Kernel, only ashmem_linux is currently enabled in EOS kernel. The other one would need

CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"

in Kconfig.

See https://brauner.github.io/2019/01/09/android-binderfs.html for further details.

[Daniel]

Cool, that situation has advanced since the last time I looked (perhaps a long time ago!).

But the page you linked to explains that basically CONFIG_ANDROID_BINDER_DEVICES is the old and highly limited way of providing access to the kernel’s binder functionality.

This has been obsoleted by a new, flexible, dynamic solution called binderfs. This is already available on Endless as you note, or at least I could successfully get this far:

# mkdir /dev/binderfs
# mount -t binder binderfs /dev/binderfs
# ls /dev/binderfs/
binder-control

So the next step here would be to investigate how Anbox can be made to use binderfs rather than relying on the old static /dev/binder interface. https://github.com/anbox/anbox/pull/1309 may have some clues.

[egrath]

Hello Daniel,
thanks for the info, will look into this and put some work into making Anbox hopefully work on EOS. Will keep the community informed about the progress on this

[egrath]

Had some spare time this weekend to play around with Anbox … unfortunately, turned out that it’s quite problematic to get it running the way i wanted it to run (e.g. Flatpak’ed) due to various reasons.

Anyway as i’m currently in the exploration phase of this little spare-time project, i had quite good success in running recent AOSP builds in Flatpak’ed QEmu. Probably this will be the way i’m focusing on it now, as it has some features i demand:

• Runs Flatpaked with no external dependencies
• Play Store is working
• Performance is generally excellent
• 3D acceleration is working through Virgil (see Screenshots)
• Integration with the Host filesystem

Currently it’s not quite ready for public release, just needs a few more weeks of maturing.

Geekbench Performance:

3DMark Performance:

[Daniel]

That’s fantastic progress!