On Tue, 28 Jul 2020 10:24:37 +0100 "J. R. Haigh" <[email protected]> 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.
pgptP1xEWwMtd.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
