Sorry for catching up late, I was really busy before.
Note that I'm not familiar with Waydroid. Reviewing the Android part
and the overall architecture it was on my TODO list[5] but I've not yet
got the time to do that[1].
I'm also not a Guix maintainer and I don't know if the project already
took decisions or not with what I'm about to discuss.
What I wonder is that if Waydroid gets added as-is, it might be useful
to at least be able to test its functionalities with some FSDG
compliant image.
For instance if users report that audio is broken, it would probably be
a good idea to be able to run test ourselves. And if there is a bug in
binder, we could also do security testing ourselves for instance.
If I compare with another similar Guix functionality: we can
produce software for Microsoft Windows with "guix build -t
x86_64-w64-mingw32 hello" but we at least have Wine for testing.
As I see it, there might be several approaches to solve this testing
issue.
(1) Use GNU/Linux and Guix to make that FSDG compliant image.
For instance we could have:
+-----------------------------------------------+
| Guix host |
| |
| Waydroid (the host/container tools) |
| ^ |
| | |
| v |
| The communication protocols (like Pulseaudio) |
| ^ |
| | |
+---+-------------------------------------------+
|
+---+------------------------------------------------------+
| | Guix guest |
| v |
| Android HAL like hardware/waydroid/audio |
| ^ |
| | |
| v |
| Libhybris or compatibility software that can run Android |
| libraries on GNU/Linux. |
| ^ |
| | |
| v |
| GNU/Linux audio stack or software that can use the |
| Android audio API somehow. |
+----------------------------------------------------------+
I'm unsure how much work that would be, and I've also not looked if
some GNU/Linux distributions are already using libhybris with Android
10 HAL. I'm also unsure if we need to use glibc or bionic (guix can
build Android components with glibc and libhybris probably expects
bionic).
The advantage of this approach that it might be possible to do
automatic testing within Guix as Guix would be used everywhere.
(2) Another approach would be to look more closely at lineage-17.1 and
make a stripped down version that is hopefuly FSDG compliant. It
should normally build fine on top of Trisquel.
In Replicant we moved to AOSP for our work on Android 11, so we
didn't do extensive research on what needs to be removed in
LineageOS 17.1.
However there is at least low hanging fruits that could be removed
easily like:
- The Linux kernel
- The unused hardware support code, like vendor specific libraries
in hardware/ or device repositories in device/.
The waydroid additions probably need to be reviewed too.
The downside here is probably maintenance: users need a way to
report FSDG compliance issue, and there needs to be a way to fix
that.
(3) Porting the Waydroid modifications[2][3] on top of Replicant 11 (and
reviewing these modifications too).
While Replicant 11 is not really usable yet on real devices yet
(telephony support for the GT-I9300 (Galaxy SIII) isn't complete for
instance, sound support is very basic, etc), Replicant 11 status
shouldn't affect the ability to add Waydroid support.
The advantage of Replicant here is that there is already a community
and infrastructure and Replicant is already listed in the FSDG
compliant distributions.
An issue with Replicant would probably be with boringdroid[4]:
It ships a binary apk (though it's released under the Apache 2.0).
Building it from source within the Replicant source code would fix
that, and the boringdroid seems to be doing something like that
already. However we also need to deactivate it for real devices, so
that seems to require more code integration work as boringdroid
seems to patch core android components like
platform/frameworks/base[4].
By the way, does someone knows where to find information about the
architecture of Waydroid. For instance is there some document that
explains how it works (like that it uses a HAL that use alsa that
then somehow talks to the host pulseaudio?, what modifications it did
for graphics, etc).
References:
-----------
[1]In Replicant 11, we now use a kernel based on upstream Linux (more
precisely a Debian kernel with our patches on top). So we need to
understand which projects we can share (maintenance) work with.
Denis.