On Tue, 01 Nov 2022 08:04:03 +0100 Julien Lepiller wrote: > That sounds good to me. We could have a default, though we must at > least make sure we don't advertise for a non-free image. > > Concerning my own work, I'm currently trying to build some base > system libraries. I managed to get a working cross-compiler for > x86_64-linux-android, and I managed to cross-build a couple > libraries. I'm hopeful I'll be able to build bionic (android's libc) > by the end of the week, then a complete cross toolchain that will > help build the rest of the system. 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. [2]https://raw.githubusercontent.com/waydroid/android_vendor_waydroid/lineage-17.1/manifest_scripts/generate-manifest.sh [3]https://raw.githubusercontent.com/waydroid/android_vendor_waydroid/lineage-17.1/manifest_scripts/manifests/02-waydroid.xml [4]https://github.com/boringdroid/platform_frameworks_base [5]https://redmine.replicant.us/issues/2290 Denis.