• Upstream
  • GuixBuildSystem
• Wiki
  • AndroidDistributions
  • BootloaderStatus
  • GNULinuxDistributions
  • LinuxSupportedDevices

Android distributions¶

• Table of contents
• Android distributions
  • Reviews
    • Anbox
    • Android x86
    • AOSP
    • AOSP Mainline
    • CustomROMs
    • DivestOS Mobile
    • Fairphone
    • GLODroid
      • device/glodroid repository
      • Forked repositories
      • Toolchains repositories
      • bootloader related repositories
      • Other repositories
    • LineageOS
    • Waydroid
    • Building a collaboration with other Android distributions
  • Comparison
• Comparison of distributions
  • AOSP and LineageOS

Reviews¶

Anbox¶

Manifest: https://github.com/anbox/platform_manifests/blob/anbox/default.xml
Android base: 7.1.1_r13
Based on: AOSP

Goals:

• Run Android (applications) in containers on top of GNU/Linux

Extra repositories (overridden or added):

Android x86¶

At the time of writing, the most recent images are RC images for Android 9, but there are branches for Android 10.

As they use (mostly?) upstream kernels, they sometimes have interesting code.

Source code: https://git.osdn.net/view?a=project_list;pf=android-x86
Manifest: git://git.osdn.net/gitroot/android-x86/manifest.git

Branches¹:

¹ https://www.android-x86.org/source.html

AOSP¶

AOSP doesn't support many devices, but it seem to support some devboards.

The advantage is that in general devboards are well supported by upstream kernels.

The official documentation also mentions some devboards .

¹ Some of the devboards in this page are probably supported: https://wiki.linaro.org/AOSP#AOSP_Dev_Board_Reference_Information

AOSP Mainline¶

website: https://github.com/aospm
manifest: https://github.com/aospm/android_local_manifests/blob/main/aospm.xml

Repositories:

¹ https://aosp-developers-community.github.io/#generic-hal-efforts

CustomROMs¶

CustomROMs seem to be a space for unofficial port of LineageOS. The idea is probably to develop the port until they manage to meet LineageOS's device-support-requirements.md . When the requirements are met, they are probably included in LineageOS directly.

• The Galaxy SIII (GT-I9300) is being ported to more recent LineageOS versions. There is a thread on the collaboration with Replicant in github. The person/people doing the port seem to alternate between an upstream kernel and a older kernel based on the vendor code depending on the amount of work required to finish the port and/or the difficulties encountered. As we are also using a kernel based on upstream Linux we collaborate on that part by reusing each other work when applicable.

DivestOS Mobile¶

This distribution is based on LineageOS. While they seem to reuse nonfree software to make the hardware work, they spent some time cleaning up LineageOS code itself.

For instance it contains patches to remove privacy issues and nonfree software included in CyanogenMod or LineageOS.

As we need to do that too in Replicant as long as we use LineageOS as base, it would be interesting to collaborate more with DivestOS on that part.

Web site:
https: https://divestos.org/
Onion: http://6sdlxbqgcxdbkvysoir2qvqqs5ro3fxgyl3phvuphcdyklv7rg57jhid.onion

Fairphone¶

As October 2020, they are porting the Fairphone 2 to Android 9. However to do that, they are using 3.4 kernel and not any upstream kernels.

In addition, they don't seem very interested in free software bootloaders, and the Fairphone 1 and 2 use Qualcomm System On a Chip.

However they are probably interested in free software libraries to make the port to newer Android versions easier.

GLODroid¶

Based on: AOSP
Manifest: https://github.com/GloDroid/glodroid_manifest/blob/master/glodroid.xml

device/glodroid repository¶

url: https://github.com/glodroid/glodroid_device.git

Content:

Forked repositories¶

Toolchains repositories¶

bootloader related repositories¶

Other repositories¶

It also contains various repositories for nonfree firmwares and nonfree bootloader components (BL1, etc), and a repository with just APKs (this might be an issue for license compliance).

LineageOS¶

See device-support-requirements.md for more information on LineageOS expectations.

Replicant has a script that is able to parse the LineageOS wiki data . That can be useful to find information on devices supported by LineageOS.

• A Qualcomm SOC with an integrated modem inside (MSM*) for many devices
• A Qualcomm SOC without a modem inside (APQ*) for many devices
• A HiSilicon Kirin 970 SOCs for devices like:
  • The Huawei Honor View 10
  • The Huawei P20 Pro
• A Samsung Exynos 7580 SOC for the following device
  • Galaxy S5 Neo (Smartphone): It has shared memory between the modem and the SOC

It may be because they rely on nonfree software to support devices, which has not been ported to Android 9, or may be because they need more time to add devices with other SOCs like exynos.

Waydroid¶

Waydroid consist in some host tool that can containerize an Android distribution, and some changes on top of LineageOS.

• The audio library does something like that: snd_pcm_open(&out->pcm, "pulse", SND_PCM_STREAM_PLAYBACK, 0); [1], so if I understood right, it uses Pulseaudio's alsa compatbility layer.
• For the graphics, some repositories like mesa, minigbm are replaced by Waydroid's own repositories. It also integrates boringdroid APK as-is instead of building it from source. Boringdroid brings moving windows to Android instead of the default full-screen windows.

There is some interest in Guix about having something like that as a patch serie was sent for adding the Waydroid host part in Guix.

What would be more interesting for Replicant as-is that in android_hardware_waydroid², there is libraries that work with upstream kernels like the vibrator library. We also have our own vibrator library but it would probably be a good idea to share the maintenance somehow.

¹ https://github.com/waydroid/android_hardware_waydroid/blob/lineage-18.1/audio/audio_hw.c

² https://github.com/waydroid/android_hardware_waydroid

Building a collaboration with other Android distributions¶

• Replicant doesn't want to support devices that have more freedom issues than the ones currently supported.
• Many other Android distributions probably don't have the same goals with the freedom of the devices they support.
• Replicant 9 is based on upstream Linux and will have to maintain its userspace libraries.
• Some users may still want to support devices that have more freedom issues than the ones supported by Replicant.

It could be a good idea to share the maintenance of the code used to make Replicant 9 with other distributions.

Comparison¶

Comparison of distributions¶

AOSP and LineageOS¶

commit 22abc3cf4077644463a2dc1c59a5a74e9518ea16
Merge: 9e96d54 8a6b6c3
Date:   Sat Jul 13 18:57:45 2019 +0200

    Merge remote-tracking branch 'aosp/pie-gsi' into lineage-16.0-pie-gsi

BootloaderStatus¶

• Table of contents
• BootloaderStatus
  • Bootloader status

Bootloader status¶

GNU/Linux distributions¶

Halium¶

Some GNU/Linux distributions like Plasma Mobile, LuneOS, Ubuntu Touch use libhybris through the Halium project to reuse proprietary Android libraries

Mer¶

• Mer uses ofono for handling the modem
• For OpenGL it's not clear if they use nonfree drivers. It would be worth looking into it. Their stack seem to be able to use free implementations as well as nonfree implementations.

See the Mer architecture for more details.

PostmarketOS¶

PostmaketOS is probably not using libhybris at all and is instead working with upstream and probably doesn't depend on nonfree libraries

Replicant strategies¶

Replicant is currently involved with upstream GNU/Linux, but it would probably be a good idea to collaborate more with distributions that don't depend on libhybris.

GuixBuildSystem¶

Use cases¶

• It can build software that uses autotools and Android.mk Makefiles
• We might be able to use it to iterate over different Android versions, to test libsamsung-ril changes for various RIL API way faster (without even having to use it in a specific Replicant version, use repo, etc).
• It's more self contained than the whole Replicant source code

• Import the compilation flags for various Replicant versions like -Werror -Wnounused to make sure that everything is usable in all Replicant versions.
• Finish packaging libsamsung-ril
• Add more automatic testing either in libsamsung-ipc / libsamsung-ril and or in the unofficial Guix packages.

Implementation¶

Guix currently uses android-make-stub to build Android software using Android.mk.

There are some comments in Guix source code that cross compilation isn't supported for the android-ndk build system.

Practically speaking it means that Guix won't be able to build any BUILD_SHARED_LIBRARY, BUILD_SHARED_LIBRARY or BUILD_STATIC_EXECUTABLE, however building the HOST_* counterpart works fine.

• BUILD_SHARED_LIBRARY becomes BUILD_HOST_SHARED_LIBRARY
• BUILD_SHARED_LIBRARY becomes BUILD_HOST_STATIC_LIBRARY
• BUILD_STATIC_EXECUTABLE becomes BUILD_HOST_STATIC_EXECUTABLE

For instance we have:

   (arguments
    `(#:phases
      (modify-phases %standard-phases
             (delete 'bootstrap)
             (add-before 'build 'patch-host
                 (lambda _
                   ;; TODO: Cross-compile.
                   (substitute* "Android.mk" 
                        (("BUILD_SHARED_LIBRARY") "BUILD_HOST_SHARED_LIBRARY")
                        ;; (("BUILD_STATIC_LIBRARY") "BUILD_HOST_STATIC_LIBRARY")
                        ;; (("BUILD_STATIC_EXECUTABLE") "BUILD_HOST_STATIC_EXECUTABLE")
                        )
                   #t))
             )))

Here the (delete 'bootstrap) is because the build is done in several phases, and here the bootstrap phase wasn't overriden by the android-ndk build system yet. As a result it tried to run autogen.sh. That might be because in libsamsung-ipc there is both an android build system and an autotools based one.

Example¶

• There is some work in progress to package libsamsung-ril for faster testing: https://git.replicant.us/contrib/GNUtoo/guix/tree/gnu/packages/replicant.scm?h=libsamsung-ril

Additional work¶

There is some work in progress by Julien Lepiller / roptat to package more Android components (including build systems like blueprint / soong) in this android-build.scm .

LinuxSupportedDevices¶

• Table of contents
• LinuxSupportedDevices
  • • Smartphones and tablets with a free software bootloader and work in progress upstream Linux support
    • Replicant supported Samsung Exynos devices
    • Replicant supported Texas Instruments OMAP4 devices
    • Other devices with some upstream support.
    • Allwinner devices
    • Rockchip devices
  • External links

Smartphones and tablets with a free software bootloader and work in progress upstream Linux support¶

Replicant supported Samsung Exynos devices¶

Replicant supported Texas Instruments OMAP4 devices¶

Other devices with some upstream support.¶

More upcoming Exynos related mainlining work could potentially be discovered at this Tizen wiki page

Allwinner devices¶

• Many of them do not use signed bootloaders.
• Many of the SOCs and various devices using them have good Linux and u-boot mainline support

For instance the Lime 2 from Olimex is pretty well supported and is easy to find.
However this device is a single board computer and, as such it doesn't have the have the usual peripherals that are commonly found in tablets and smartphones. This makes a port on this device less relevant and less useful.

Some research is needed to identify which devices are easiest to work with. Tablets that don't have a modem seem to be better than smartphones, as supporting the modem would require to have it supported in Linux and the userspace libraries. This might even require to write and upstream a Linux driver for the modem.

• A SOC that has good mainline support, see the Linux mainlining effort page on linux-sunxi for more details.
• A Free software bootloader, or the ability to easily add support for the tablet to a free software bootloader.
• The ability to power and use an USB WiFi card or chip that is compatible with the ath9k_htc driver.

It would also be better if the chosen tablet doesn't use an AllWinner SOC with a PowerVR GPU, as MALI GPU have more probability to be usable with free software in the future.

Rockchip devices¶

• There is a Linux upstream status page in the opensource.rock-chips wiki
• There is also some information on u-boot in the opensource.rock-chips wiki

External links¶

• https://talk.maemo.org/showthread.php?t=99357 list of smartphones (and tablets?) with a link to their dts: it has devices that we don't have yet in the list above.

Upstream Linux¶

• Table of contents
• Upstream Linux
  • Tracking upstream patches
  • Benefits of using Upstream Linux
  • Requirements
  • Devices
  • Linux upstream status
• Bootloaders
  • Bootloader status
  • See also
• GNU/Linux components
  • Modem support
  • Upstream userspace hardware support libraries
  • Upstream non-hardware specific userspace
  • MTP
  • libc
  • Other projects interested in using upstream Linux and/or contributing to it
    • PostmarketOSpmOS wiki: upstream kernelpmOS wiki: i9305 with upstream kernel
    • O-DROID
    • osmocomBB
    • Mali
    • LineageOS
    • oFono
    • Parabola
• GNU/Linux distributions
• Android distributions
• Design decisions
  • Various
  • root filesystem related
  • Gatekeeper HAL backend
  • Handling dynamic major/minor /dev/ nodes
  • Firmware loading
  • Embeddable web engine
• Web engine backend
  • Upstream web browser engine comparison
  • Forked web browser engine comparison
  • How and if to implement a webview compatible API
• Tools and build systems
  • Projects
  • Approaches
• Coding standards and style

Tracking upstream patches¶

We have a new issue tracker for tracking upstream status of various patches.

Benefits of using Upstream Linux¶

Currently, Replicant uses device specific Hardware Abstraction Layers, because device manufacturers implemented non-standard kernel interfaces. However, Android works with upstream kernels and supports plug-n-play hardware nowadays, so it makes sense to have generic Hardware Abstraction Layers for the standard interfaces of the Linux kernel (ALSA, V4L2, etc).

• It would allow supporting external WiFi dongles such as the ones supported by the ath9k_htc driver and free firmwares without the need for a specific application or configuration.
• It would make devices last longer by alleviating the device specific maintenance burden: If LineageOS stops supporting a Replicant supported device, Replicant would need to maintain it by its own. This would require a lot of work, unless the device is already supported the upstream Linux kernel and generic hardware abstractions layers. This would also enable Replicant to support devices that are not currently supported by LineageOS with a lot less work.
• It would enable the support for devices that are or will be added to upstream Linux.

• The device specific work could be shared between GNU/Linux communities and Replicant communities. This could result in less work to do to support individual devices. Since Android libraries depends on Android's libc, non-standard proprietary libraries might be harder to reuse than the free software implementations, so we might get even more collaboration thanks to that.
• It would enable GNU/Linux distributions to more easily support smartphones and tablets, which would hopefully enable FSDG distributions to be able to focus on usability instead of hardware support. This way, if one day Android devices stop using the Linux kernel, stops being free software, or if the code takes directions that are too much problematic, already having GNU/Linux based Android alternatives would reduce the amount of work needed to be able to get again a fully free software distribution for smartphones and tablets.
• Older devices with less amount of RAM than Replicant current minimum requirements could be used with GNU/Linux and possibly repurposed for other usages, reducing the amount of electronic devices waste.

Requirements¶

• For the other standard interfaces (like ALSA, etc) a device running a upstream Linux Kernel with as few patches as possible is required.

Devices¶

• The work needed to have the device usable with upstream Linux.
• The work porting or writing Android hardware abstractions layers.

• requires no or very minimal work to be fully supported by Linux.
• have less hardware features (so we don't need to support them in Linux and in the HALs).
• is easy to buy, so the work can be shared among multiple people.
• doesn't have more freedom flaws than the devices currently supported by Replicant

It is also a good idea to keep one image per device at first, as trying to make a single image that
would work on all ARM device supported by upstream Linux is complicated: Even GNU/Linux
distributions have a hard time doing that for ARM devices.

Linux upstream status¶

In some cases, even if the upstream status looks good, nonfree bootloaders can get in the way. We have a list of stock bootloaders incompatible with upstream Linux in this page: BootloadersIncompatibleWithLinux.

See LinuxSupportedDevices in the upstreaming sub project for the upstream status for various devices.

Bootloaders¶

Bootloader status¶

See the BootloaderStatus page on the upstream subproject.

See also¶

• Google Summer of Code 2018

GNU/Linux components¶

Modem support¶

Upstream userspace hardware support libraries¶

Upstream non-hardware specific userspace¶

MTP¶

• look at https://github.com/viveris/uMTP-Responder to see if it can be integrated in Android. It is known to work with the upstream kernel.
• Also compare with other implementation, including the Android one.

libc¶

Other projects interested in using upstream Linux and/or contributing to it¶

PostmarketOS
pmOS wiki: upstream kernel
pmOS wiki: i9305 with upstream kernel¶

O-DROID¶

osmocomBB¶

Mali¶

LineageOS¶

oFono¶

Parabola¶

GNU/Linux distributions¶

See GNULinuxDistributions for more details.

Android distributions¶

There is a community that include various project (distributions, HAL, etc) meant to reduce code duplication between projects working with AOSP.

Website: https://aosp-developers-community.github.io/

We definitely need to collaborate with them.

For distributions review, see AndroidDistributions for more details.

Design decisions¶

Some decisions have been taken by upstream projects, for instance the the Android Open Source Project (AOSP) is pushing device manufacturers to use signed bootloaders and not give the users the ability to replace those bootloaders. Therefor it is best to revisit such decisions and decide whether or not to implement a given feature.

Various¶

We can get both: we can enable users to get logs at boot while avoiding any security issues.

To do that we can keep disable adb and root disabled at boot, and enable users to add it back by editing the boot.img or recovery images. We have a tutorial for that in the AddingADBRootToAnImage page and we are working on script to automate it even more.

root filesystem related¶

Gatekeeper HAL backend¶

Background information: Gatekeeper is a daemon that is used to store passwords and other secrets.

Handling dynamic major/minor /dev/ nodes¶

Background information: We can manage to avoid this use case for now.

Firmware loading¶

Embeddable web engine¶

The Android API for embedding a web engine is WebView.

Web engine backend¶

• Using a recent webview based on chromium would create freedom issues as we don't know the license of chromium
• Using and old webview based on webkit would bring back many security issues

To solve that we need to find a solution that depends on a good upstream as we are not going to write a web browser engine ourselves.

Upstream web browser engine comparison¶

This lists upstream projects that are not forks tracking another upstream project.

Forked web browser engine comparison¶

TODO: Add various chromium versions here.

How and if to implement a webview compatible API¶

TODO

Tools and build systems¶

Replicant has an issue with licensing (bug #1973) where we don't know under which license is Replicant. This due to the fact that the Android build system doesn't use a package manager during the build, and so it doesn't have license definition for each repositories.

A good way to fix that and also gain the ability to natively build GNU/Linux components like MESA or ofono would be to use a build system that use a package during at least during the build.

• GNU/Linux distributions need to package Android tools which are built with the custom Android build system
• Some distributions mixes GNU/Linux and Android

Projects¶

Approaches¶

Coding standards and style¶

• Having inconsistent style makes it harder to read the code, spot bugs, etc
• Fixing inconsistent style too late results in commits that are extremely hard to review².
• Fixing inconsistent style in unrelated commits makes rebasing code painful

¹ https://peps.python.org/pep-0007/
fn2. Example: https://git.replicant.us/replicant/hardware_replicant_libsamsung-ipc/commit/?id=3f706fe2556b5efe29aa16a1232a3dc5d5646f55
fn3. https://curl.se/dev/code-style.html

Wiki¶

• Table of contents
• Wiki
  • Bootloader projects
  • Distributions
  • Linux
  • Various
  • Wikidata
  • License

Bootloader projects¶

• BootloaderStatus: Upstream and downstream status of bootloader for various smartphones and tablets.

Distributions¶

• AndroidDistributions: Review of various Android distributions
• GNULinuxDistributions: Review of various GNU/Linux distributions

Linux¶

• LinuxSupportedDevices: Smartphones and tablets supported in Linux
• Exynos TODO list: https://exynos.wiki.kernel.org/todo_tasks . Has very important information such as "Fix entering AFTR (cpuidle) when some power domains are off." that could help avoid waisting many hours debugging some difficult issues.

Various¶

• Upstream: Lot of reviews of upstream projects and design decisions. Need to be split.

Wikidata¶

• comptible with can be used to tell that a device is compatible with a dts file that is part of Linux for instance. Note that we want to avoid having Linux being compatible with way too many devices. Instead it's better to have the devices be compatible with Linux not to have a list of properties that is gigantic. Note that at the time of writing (December 2020), this property is very new, so not everything has been converted to use it yet.
• Before other properties like Platform were abused to express compatibility between hardware and software
• Other properties like operating system also do exist

License¶

All the wikis in this Redmine instance are available under the Creative Commons BY-SA license.