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"
> <[email protected]> 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.
_______________________________________________
Replicant mailing list
[email protected]
https://lists.osuosl.org/mailman/listinfo/replicant
