[Replicant] Anbox freedom review; Replicant components inside the LXC?

[J. R. Haigh]

Hi all,

At 2020-07-29Wed05:40:39+02, Denis 'GNUtoo' Carikli sent:
> On Tue, 28 Jul 2020 10:24:37 +0100 "J. R. Haigh" <JRHaigh+ML.Replicant at Runbox.com> wrote:
> > […]
> 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.

That's good!

> 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.

But that's fine for just a few applications.

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

That's probably referring to applications requiring DRM, which I do not care for anyway.
	It could also mean vendor-provided applications that assume the specific hardware that they're bundled with, such as an FM radio application that only works with a particularly SoC or a camera application that assumes a particular camera module.

> 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.

Anbox is in Debian's contrib repository rather than main, which means that it is itself libre but depends on something with freedom issues. It seems that the problematic dependency is the dependency on some core Android components: “
> This package needs Android kernel modules and rootfs image, see /usr/share/doc/anbox/README.Debian for information.  
” – https://packages.Debian.org/stretch-backports/anbox
Could these components be replaced with Replicant's freedom-reviewed versions?

> 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,

Yep, I noticed the individual Android packages here:
https://Guix.GNU.org/en/packages/A

> 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.

Did you mean to uppercase the ‘X’ twice? By “GuiX”, do you mean GNU Guix (https://Guix.GNU.org )?

> - 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

2017 – https://Bits.Debian.org/2017/03/build-android-apps-with-debian.html

> 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.

Obviously it'll still be packaged but probably out-of-date.

> 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.

Would licence compliance complication be mitigated if the Android components required by Anbox were replaced by Replicant components? If all of the software being packaged is Free Software then surely licence compliance is less of an issue.

> As far as I know the Anbox freedom wasn't reviewed. It would be interesting to have a review on it though.

Yes, a freedom review of Anbox is a very good idea. (Hence I changed the subjectline accordingly.)

> 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.

Great!

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

Okay, but if you could replace the problematic dependencies with Replicant components then you would deduplicate that effort of reviewing freedom, as you already review the freedom of Replicant.

> 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.

Licensing is such a pain and hindrance to creativity and innovation.

Best regards,
James.
-- 
Wealth doesn't bring happiness, but poverty brings sadness.
https://wiki.FSFE.org/Fellows/JRHaigh
Sent from Debian with Claws Mail, using email subaddressing as an alternative to error-prone heuristical spam filtering.