[Replicant] Android applications on ‘real’ GNU+Linux – Anbox?

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Wed Jul 29 03:40:39 UTC 2020


On Tue, 28 Jul 2020 10:24:37 +0100
"J. R. Haigh" <JRHaigh+ML.Replicant at Runbox.com> wrote:

[...]
> However, there are a number of Android applications
> from F-Droid that I'm keen to continue using,
[...]
> Anbox was recommended to me, but I don't see it in the repositories
> of either Debian or Guix. Also, their website seems flashy and far
> detached from the Free Software community.
Anbox looks really interesting, so I've looked a bit more into it.

According to their documentation, it run Android in (lxc) containers
which is way more efficient than emulators as it can share some of the
host resources like RAM in more efficient ways. Though it probably
cannot be as efficient as native Android or GNU/Linux applications as
the extra stack and libraries are probably running in parallel.

According to their website, it also seem to have limited hardware
features support (applications relying on specific hardware may not
work in some cases). I'm unsure what it means exactly.

It requires to build Android (they are based on Android 7.1.1), and as
far as we know, Android isn't packaged yet in GNU/Linux distributions,
even if a tiny part of it is usually packaged to get tools like adb.

Various GNU/Linux distributions approach Android packaging in different
ways:
- In GuiX it seem to be done in the right way: (very few) Android
  libraries are already packaged as individual packages, and you can
  build some low level Android software that have Android.mk if that
  software has very very few dependencies. I managed to build
  libsamsung-ipc with the Android.mk with GuiX for instance, but
  building libsamsung-ril requires to package a bit more dependencies.
- In Arch/Parabola some Android libraries are built as part of the
  android-tools package, however they seem to be included in the
  resulting binaries like adb.
- Debian had the Android SDK packaged at some point but it's probably
  not the case anymore. I didn't look in the details. Having an SDK is
  quite an achievement as it had Java packages.

It's probably still possible to package things in very quick and dirty
ways but then it would make certain things like license compliance
way more complicated. As far as I know the Anbox freedom wasn't
reviewed. It would be interesting to have a review on it though.

Anbox requires extra kernel modules (ashmem and binder). I've no idea
if that's done for making it easier to use or if they have
modifications, or to which Android versions it's tied to.

I've not found much documentation on anbox but I found a document
detailing a bit the general architecture:
https://github.com/anbox/anbox/blob/master/docs/runtime-setup.md

https://github.com/anbox also shows a bit which Android components were
modified, so it gives a general idea of the architecture too.

Beside the stock AOSP repositories that are in that manifest:
https://github.com/anbox/platform_manifests/blob/anbox/default.xml

They don't seem to have many repositories, so what they added is
probably easy enough to review for freedom.

However like with Replicant, the huge amount of upstream repositories
makes it way harder to review than GNU/Linux distributions.

In Replicant we need to improve on that as well: unlike GNU/Linux, we
have no package definitions, instead a license list is generated during
the build and included in the final images. We need to look more into
it to have a more clear and precise understanding of licensing.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20200729/c7651a7c/attachment.asc>


More information about the Replicant mailing list