Replicant

h1. Tasks

{{>toc}}

This page describes how to help Replicant if you have some time at hand.

Filtering the issue tracker for open issues, which have either one of the priorities "immediate":/projects/replicant/issues?set_filter=1&f[]=status_id&op[status_id]=o&f[]=priority_id&op[priority_id]=%3D&v[priority_id][]=39&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=cf_21&group_by=, "urgent":/projects/replicant/issues?set_filter=1&f[]=status_id&op[status_id]=o&f[]=priority_id&op[priority_id]=%3D&v[priority_id][]=33&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=cf_21&group_by= or "high":/projects/replicant/issues?set_filter=1&f[]=status_id&op[status_id]=o&f[]=priority_id&op[priority_id]=%3D&v[priority_id][]=27&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=assigned_to&c[]=updated_on&c[]=category&c[]=cf_21&group_by=, lists the important current tasks.

Additionally, below is an overview over tasks where help is greatly appreciated.

*Note: Working on most of these tasks and projects requires a sufficiently powerful computer with enough disk space to build Replicant.*

h2. Various tasks that don't require specific hardware

h3. Port Replicant to a newer LineageOS version and support in-system updates

Replicant is currently based on LineageOS 13.  It would be desirable to upgrade Replicant to a newer release of LineageOS. While at it, it would be useful for a Replicant device to be able to update itself to a new version of Replicant without requiring being connected to a PC. LineageOS already supports this; we suspect that it should be possible to adapt this LineageOS functionality to Replicant. Whenever possible, it would be useful to complete and submit some of the code written for Replicant to LineageOS.

*Difficulty*: Medium

*Requirements/Prerequisites*: Knowledge of C, C++, and Java.

*Expected outcomes*: Remove all proprietary components of LineageOS, port all the changes needed to successfully boot without any blobs, rebrand LineageOS as Replicant and support in-system updates

h3. Improve support for the free software compatible external WiFi adapter

All devices currently supported by Replicant have WiFi chips that requires a non-free firmware to work. So to have WiFi working with free software, users need to use external WiFi adapters. They typically use tiny ath9k_htc compatible USB WiFi adapter along with a tiny USB OTG Host adapter.

Such external USB WiFi adapters used with Replicant are originally intended for laptops, not phones. As a result, they tend to consume a lot of power. According to lsusb some ath9k_htc compatible devices can consume up to 500mA.

This poses several issues:

* Some smartphones and tablets might not be compatible, at the hardware level, with such big power consumption.

* They can adversely impact battery life

Such USB WiFi adapters can also randomly stop working completely on some devices (e.g. needing to unplug and replug the adapter periodically to keep it operational).

You will need to investigate reliability issues such as the one mentioned above and look how power consumption can be improved in the adapter firmware and/or kernel driver.

You will also need to investigate how much miliampers USB devices can use, at the hardware level, on the smartphones and tablets Replicant supports.

*Difficulty*: Medium/Hard

*Requirements/Prerequisites*: Knowledge of C

*Expected outcomes*: Reliable WiFi with external WiFi adapter

h3. Tackle security issues in Replicant

Replicant is plagued by various security issues, that are mostly due to using a downstream codebase. One of the most crucial issues is that Replicant uses an old version of the Android WebView (from circa 2015), which is also a functionality drawback.

An initial evaluation of the security issues in Replicant should be conducted, followed by the integration or update of the concerned components of the system.

It would also be nice to do the same for privacy issues. Since Replicant indirectly depends on the "Android Open Source Project" and directly depends on LineageOS, not all privacy issues might have been found fixed by Replicant. Once security issues have been fixed, it would be nice to try to identify as many privacy issues as possible, and in a second time to fix them.

*Difficulty*: Medium-Hard

*Requirements/Prerequisites*: Android build system, knowledge of system security, advanced git

*Expected outcomes*: Integration or update of components of Replicant to tackle security issues

h3. Fix the Free software distribution guidelines issues and improve the build system.

Replicant has some issues with "FSDG (Free System Distribution Guidelines)":https://www.gnu.org/distros/free-system-distribution-guidelines.html compliance: "F-droid":https://f-droid.org/ repository is not FSDG compliant anymore (Bug #1629), and Replicant can't be built from an FSDG distribution (Bug #1861). This ought to be fixed. Replicant should also be fixed to build without issue.

It would also be nice to have the build system not depend on pre-built dependencies anymore, and to document which FSDG compliant F-droid applications crash because Replicant's incomplete EGL implementation (#705) and tag such applications as incompatible (so they are greyed out) until the EGL implemetation is fixed. Ideally Replicant builds should also be made "reproducible":https://en.wikipedia.org/wiki/Deterministic_compilation if they are not already.

*Difficulty*: Easy

*Requirements/Prerequisites*: Knowledge of shell scripts and the ability to learn the Android build system

*Expected outcomes*: The ability to compile Replicant from "an FSDG distribution":https://www.gnu.org/distros/free-distros.html, F-droid only showing FSDG compliant software.

h3. llvmpipe ARM optimizations

Project description: Replicant's EGL is implementation is incomplete (This has many consequences: #705). The goal is to make llvmpipe usable under Replicant and replace the incomplete EGL implemetation with that. The advantage of this solution over other solutions is that it is supposed to work on all Replicant supported devices and is also used within GNU/Linux.

See also the "wiki page about llvmpipe":https://redmine.replicant.us/projects/replicant/wiki/GraphicsResearch#llvmpipe for more details about the issue. Other solutions fixing the problem might be acceptable too, if it makes more sense.

*Difficulty*: See with the MESA project

*Requirements/Prerequisites*: See with the MESA project

*Expected outcomes*: Working EGL implementation, fast enough graphics, F-droid applications not crashing anymore because of EGL.

h2. Device-specific tasks

h3. Project focus

While supporting many common (Samsung) phones and tablets is relatively easy and fast to do, we think that it's at lot more important to support devices that are better for freedom. Many Samsung devices we do support have an isolated modem, however we can't free their bootloader because it is signed.

Devices like the GTA04 or the LG Optimus Black don't have this bootloader issue, while still having an isolated modem.

We therefore strongly advise to pick tasks that would improve the support for these more freedom-friendly devices in Replicant.

We however still accept contributions for devices with isolated modems and non-free bootloaders.

h3. U-Boot and Linux mainline related tasks and ports

h4. Enable Replicant to use a kernel that is as close as possible to mainline Linux by implementing generic Hardware Abstraction Layers (HALs)

Currently, Replicant uses a dedicated Hardware Abstraction Layer per device, because device manufacturers implemented non-standard kernel interfaces. However, Android works with mainline 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).

See also the [[Upstream#Upstream-Linux|wiki page on Upstream Linux]] for more details on why using upstream kernel is beneficial, and for what devices to choose to work on this task.

*Difficulty*: Medium

*Requirements/Prerequisites*: C programming language, kernel interfaces knowledge

*Expected outcomes*: Replicant and/or upstream LineageOS support for a device using a kernel that is very closely based on the mainline Linux kernel with the generic HALs.

h4. Improve the upstream U-boot and Linux mainline support of interesting devices

h5. Finish to port the Galaxy S 2 (I9100), Galaxy S 3 (I9300) and Galaxy Note 2 (N7100) to Mainline Linux

The the Galaxy S 2 (I9100), Galaxy S 3 (I9300) and Galaxy Note 2 (N7100) currently use a kernel based on a vendor fork of Linux, which poses a maintainability and security issue.  Forkbomb has done some initial work on porting these devices to use mainline Linux.  You can help by continuing this work. This would also enable these devices to use generic hardware abstraction layers (HAL) when abstractions layers are ready, and to do some research on whether the "TrustZone operating system":https://blog.fossencdi.org/u-boot-galaxys3.html can be removed from such devices.

*Difficulty*: Medium

*Requirements/Prerequisites*: C programming language, driver development

*Expected outcomes*: Audio working, modem working, and Replicant or LineageOS booting with mainline Linux.

h5. Advance the Optimus Black U-Boot and Linux mainline ports

The Optimus Black from LG is an interesting device from the perspective of freedom and privacy/security. It has the ability to run a free bootloader and uses an OMAP3 SoC that is well-documented and supported in upstream U-Boot (bootloader) and Linux (kernel). Its modem is well-isolated from the rest of the device, ensuring a sane base for privacy/security. Currently, the device-specific parts of the mainline U-Boot and Linux ports are still at an early stage, where they are functional with a very limited set of supported hardware.

Advancing the Optimus Black U-Boot and Linux mainline ports would allow using the device with free, up-to-date and maintainable software and would pave the way for support in GNU/Linux systems as well as Replicant. A list of priorities in hardware support will be defined, with the objective of tackling as many as possible.

*Difficulty*: Medium to Hard

*Requirements/Prerequisites*: C programming language, driver development

*Expected outcomes*: Improved hardware support for the Optimus Black in U-Boot and Linux

h5. Select and/or port a tablet with an Allwinner SOC to mainline Linux and U-boot, and Replicant

Tablets with Allwinner SOCs are an interesting targets because they do not use signed bootloaders and the SOCs and various devices using them have good Linux and u-boot mainline support. If not much work is required for that, once the code is merged, the candidate is also required to work on the generic abstraction layer project which is also documented in this page.

The chosen tablet should have:

* A SOC that has good mainline support, see "the Linux mainlining effort page on linux-sunxi":https://linux-sunxi.org/Linux_mainlining_effort 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 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.

*Difficulty*: Medium

*Requirements/Prerequisites*: C programming language, driver development

*Expected outcomes*: Replicant support for a tablet using an Allwinner SOC, with free software bootloader and mainline based Linux kernel.

h5. Advance the Kindle Fire (first generation) U-Boot and Linux mainline ports

The Kindle Fire (first generation) from Amazon is an interesting device from the perspective of freedom and privacy/security. It has the ability to run a free bootloader and uses an OMAP4 SoC that is well-documented and supported in upstream U-Boot (bootloader) and Linux (kernel). It does not embed a modem, ensuring a sane base for privacy/security. Currently, the device-specific parts of the mainline U-Boot and Linux ports are still at an early stage, where they are functional with a very limited set of supported hardware.

Advancing the Kindle Fire (first generation) U-Boot and Linux mainline ports would allow using the device with free, up-to-date and maintainable software and would pave the way for support in GNU/Linux systems as well as Replicant. A list of priorities in hardware support will be defined, with the objective of tackling as many as possible.

*Difficulty*: Medium

*Requirements/Prerequisites*: C programming language, driver development

*Expected outcomes*: Improved hardware support for the Kindle Fire (first generation) in U-Boot and Linux

h3. RIL related tasks

h4. Implement the missing features of Samsung-RIL

Samsung-RIL is the RIL (Radio Interface Layer) that many Replicant devices use to communicate with the modem.  It is a free, reverse-engineered replacement for the proprietary RIL that the Samsung phones ship with by default (which has been found to have backdoors).

Right now, Samsung-RIL mostly implements only the protocol features that are absolutely necessary for the phone to be operable.  As a result, many more rarely used protocol features are unimplemented, which decreases functionality compared to the proprietary RIL. You can help by implementing the missing features of Samsung-RIL.

It would also be nice to fix most the reported bugs involving samsung-ril and libsamsung-ipc that are impacting users very seriously. This includes the bugs about the SIM card not being detected, and the issue about having metallic sound quality when doing voice calls over 3G (bug #1773). It would also be nice to be able to recover from EFS (the modem filesystem) corruptions (Bug #1869).

*Difficulty*: Medium to Hard

*Requirements/Prerequisites*: Knowledge of C.

*Expected outcomes*: Implement the missing features listed at [[Samsung-RIL]].

h4. Implement a fully-featured QMI-RIL

The LTE variants of the Samsung Galaxy S3 and Samsung Galaxy Note 2 use a different modem from the non-LTE variants that Replicant currently supports.  You can help Replicant support those modems by implementing a QMI-RIL, which performs a similar role on the LTE variants as what Samsung-RIL performs on the currently-supported non-LTE variants.  Wolfgang has done some preliminary work on this, so you'll probably be picking up where he left off.

*Difficulty*: Hard

*Requirements/Prerequisites*: Knowledge of C.

*Expected outcomes*: A QMI-RIL that supports voice calls, SMS, and data, with as complete a protocol implementation as possible.

h1. Funding tasks

We could try to fund the following separate tasks:

* llvmpipe ARM optimizations

* Implement the missing features of Samsung-RIL

And group the following tasks together for funding:

* Port Replicant to a newer LineageOS version and support in-system updates

* Enable Replicant to use a kernel that is as close as possible to mainline Linux by implementing generic Hardware Abstraction Layers (HALs)

* Fix the Free software distribution guidelines issues and improve the build system.

* Tackle security issues in Replicant

It would make sense to find out how much theses individual tasks depend on the Android version:

* Samsung-RIL probably doesn't have very hard dependencies on the Android version, and could probably made to continue to support Replicant 4.2, Replicant 6.0 and more recent Android version.

* It's probably better to add support for upstream kernels once Replicant is ported to a newer LineageOS version.

* The build system including the Free software distribution guidelines issues, and the security issues are also very tied to the Android version.