Replicant

{{>toc}}

h1. Funding

h2. Funding procedure

h3. Funding status

See [[TasksFunding]] for tasks that have been accepted by funding organizations. It also contains more background on such organizations.

h3. Applicants criteria

h4. When funding tasks with Replicant's money

In order to minimize the risk:

* The applicants will need to already have Patches in Replicant to apply. So if you want to apply and don't have any patches in Replicant, the easiest way is just to send some useful patches.

* The applicants will need to be able to demonstrate that they have the required skills by showing contributions in free and open source project in similar areas.

* The applicants will need to be able to do contract work

Alternatively we could also handle it in a way that is similar to the NLnet foundation, where we would only pay once some useful part of the work has been done.

h4. When funding tasks through other organizations

See [[TasksFunding]].

h2. Tasks that could be funded

h3. Port Replicant to a newer Android version

Replicant is currently based on LineageOS 13 which is based on Android 6.0.

It is becoming very urgent to upgrade Replicant to a newer release of Android, as Android 6.0 is not supported anymore. It would probably also make it way easier to fix the following issues:

* Replicant is currently lagging behind with security fixes

* Replicant cannot be built from a GNU/Linux distribution that follows the Free Software Distribution Guidelines

*Hardware requirements* :

* A computer that is able to build Replicant.

* A smartphone or tablet that can easily supported by the new version of Replicant and that meet Android 9 [[HardwareRequirements]].

*Expected outcomes*:

* Remove all proprietary components of LineageOS and make sure that Replicant follows the "Free Software Distributions Guidelines (FSDG)":https://www.gnu.org/distros/"

* Port all the changes needed to successfully boot without any proprietary software in Replicant

* Make sure that most of the security issues are fixed, and lower the attack surface if possible.

* Make sure that Replicant can be built on a GNU/Linux distribution that follows the "Free Software Distributions Guidelines (FSDG)":https://www.gnu.org/distros/

* Rebrand LineageOS as Replicant

*Funding*: We could apply to https://nlnet.nl/PET

h4. Subtasks

The following sub-tasks could also be worked on along with porting Replicant to a newer Android version, as it doesn't make sense to do them for older Replicant versions:

* [[Tasks v2#Add support for devices with an upstream Linux kernel|Add support for devices with an upstream Linux kernel]]

* [[Tasks v2#Add support for more recent smartphones|Add support for more recent smartphones]]

* [[Tasks v2#Add support for the devices supported in Replicant 6.0 and 4.2|Add support for the devices supported in Replicant 6.0 and 4.2]]

* [[Tasks v2#Support in-system upgrades|Support in-system upgrades]]

h4. Add support for devices with an upstream Linux kernel

It would also be useful to support devices using kernels that are based on upstream Linux with the least amount of kernel changes possible:

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.

*Hardware requirements* :

In addition to the requirements for porting Replicant to a newer Android version:

* A device that is already well supported by the Upstream kernel. That device don't need to be already supported by LineageOS or even Android.

*Difficulty*: Medium

*Requirements/Prerequisites*: Knowledge of C, some C++, the ability to understand Java, kernel interfaces knowledge

*Expected outcomes*: 

* Basic features working (graphics, touchscreen, buttons, audio, and telephony if there is a modem) for at least one device that use a kernel that is very closely based on upstream Linux with the generic HALs.

h4. Add support for more recent smartphones

The most recent smartphones that Replicant support are quite old (they were made around 2013). The goal here is to add support for more recent smartphones in Replicant.

Even if we think that it's at lot more important to support devices that are better for freedom (samsung devices usually have a nonfree bootloaders), adding supporting common (Samsung) phones and tablets is relatively easy and fast to do and could be a good way to get started in contributing to Replicant. 

It's advised to pick a device that:

* has an isolated modem (no shared memory between the modem and the processor running Android)

* meets Android 9 [[HardwareRequirements]] to still be useful when Replicant will be ported to Android 9

* has a modem that can easily be supported by samsung-ril and libsamsung-ipc 

* is or will be supported by lineageOS

Make sure to evaluate the device before starting to work on it. Some devices have been evaluated in the [[TargetsEvaluation|TargetsEvaluation wiki page]]. There is also a "forum section":https://redmine.replicant.us/projects/replicant/boards/27 for devices evaluation.

*Hardware requirements*:

In addition to the requirements for porting Replicant to a newer Android version: 

* One or more smartphones that are already well supported by LineageOS or the AOSP project and that can easily be added in Replicant.

*Difficulty*: Medium

*Expected outcomes*: 

* Basic features working (graphics, touchscreen, buttons, audio, and telephony if there is a modem) without requiring Replicant or the user to install or ship nonfree software or firmwares.

h4. Add support for the devices supported in Replicant 6.0 and 4.2

When porting Replicant to a new version, it's also a good idea to keep supporting all the devices we supported in the older versions, however this is not always possible or desirable.

In order not to require too much work, devices that were previously supported will have to meet the [[HardwareRequirements]] of the new Android version. Here many of the devices already supported by Replicant 6.0 already meet such requirements.

*Hardware requirements and dependencies*:

In addition to the requirements for porting Replicant to a newer Android version:

* The port to the new Android version needs to be complete for at least one device before starting to work on this.

* All the devices will need to be shipped to (or acquired by) the person working on this task before starting to work on this.

*Expected outcomes*: 

* For each device: evaluate if they meet the hardware requirements of the new Android version and document that in the wiki in an appropriate location  ( like [[HardwareRequirements]] for instance)

* For each device: basic features working (graphics, touchscreen, buttons, audio, and telephony if there is a modem) without requiring Replicant or the user to install or ship nonfree software or firmwares.

*Difficulty*: Medium

h4. Support in-system upgrades

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

*Expected outcomes*: 

* In-system updates working without being connected to a PC

h4. "Finish porting Replicant to a newer Android version" nlnet Grant application

|_. Project name | Finish porting Replicant to a newer Android version |

|_. Website / wiki | https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9 |

Abstract: Can you explain the whole project and its expected outcome(s).in 1200 characters

<pre>

Replicant is a fully free software Android distribution which

is approved by the FSF (http://gnu.org/distros).

The combination of Android Open Source Project source code with

the Linux source code provided by the device vendor is not

sufficient to produce a fully free Android distribution that

works: a lot of the code that makes critical hardware components

work (the modem, graphics, audio, GPS, etc) is in userspace.

Because of that, most device manufacturers don't release them as

free software.

To make such hardware work, the Replicant project manages to

replace or avoid such nonfree software.

Replicant is currently based on LineageOS 13.0 which in turn is based

on Android 6.0.1 which are both not supported anymore. Replicant is

based on LineageOS because it supports way more smartphones and

tablets than the Android Open Source Project.

The project consists in porting Replicant changes on top of the

Android 9 release of the Android Open Source project,

and when LineageOS 16 will be ready, to backport our changes on

top of LineageOS 16.

</pre> 

|_. Have you been involved with projects or organizations relevant to this project before?

And if so, can you tell us a bit about your contributions? | SEE TEMPLATE |

|_. Requested Amount (Between 5000 and 50000 Euros) | 50000 Euros |

|_. Does the project have other funding sources, both past and present? | SEE TEMPLATE |

Explain what the requested budget will be used for? 

<pre>

The budget will only be used to fund this task through contract work.

We think it will take something between 3 and 6 months of work

for one full time developer.

However it is always difficult to evaluate precisely the amount of time

that this kind of project would take as sometimes it can be slowed down

a lot due to bugs needing to be fixed.

For instance, when adding support for the Nexus One to Replicant,

a lot of time was spent dealing with display issues that didn't affect

the upstream projects, because they relied on the GPU which required

nonfree software to work.

If we take the cost of a Freelance developer in the USA (75$ to 150$

per hour) as a basis, to enable people living in Europe and the USA

to apply, we can fund a developer to work on it for a period that

is mostly equivalent to something between 2 to 4 months full

time.

So far we have at least one person interested in working on it

as a contractor (me), and one volunteer who wants to work on it at the

same time, but who cannot do it full time. We will make sure

that everybody has a chance to apply for doing contract work.

If the work is not done when the 50000E run out, and if we cannot

make sure that it will be completed by volunteers in a reasonable

timeframe, the Replicant project will most probably use its existing

funds to pay for contract work to make sure that this task is completed.

The Replicant project will also take care of ensuring that the

people that will work on this task have the necessary hardware to

do it, for instance by shipping or reimbursing the purchase of a

compatible smartphone with the Replicant project money.

Once we have the Samsung Galaxy SIII fully working with

Replicant 9, we will add support for most smartphones

and tablets we currently support in Replicant, and add support

for more recent smartphones (the most recent one we currently

support has been released in 2013).

We also have a very basic documentation on the Android 9 port here:

https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9

</pre>

Compare your own project with existing or historical efforts.

<pre>

Upgrading Replicant to a new Android version usually took about 2 or 3

months of full-time equivalent work for one person.

Here, we already have a device (The Galaxy SIII 4G) booting under Android 9

master before the release, with a kernel that is closely based on upstream

Linux, but a lot still needs to be done (modem, audio, sensors, etc) and

validated. The Android architecture also changed a lot more between Android

6.0.1 and Android 9 than it did when we ported Replicant to newer Android

versions.

</pre>

What are significant technical challenges you expect to solve during the project, if any?

<pre>

We will also need to make sure that Replicant 9 can be built with a

GNU/Linux distribution that is approved by the FSF. This could be

challenging if they lack some of the packages required to build Android.

</pre>

|_. Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes? | SEE TEMPLATE |

|_. Attachments | SEE TEMPLATE |

h3. Graphics acceleration

Currently, all supported devices on Replicant lack a free software driver for their GPU. This means that OpenGL ES (GLES) rendering must be done on the CPU (software rendering). The current approach to software rendering on Replicant 6 is based on "libAGL":https://android.googlesource.com/platform/frameworks/native/+/master/opengl, an optimized GLES 1.x implementation that uses "libpixelflinger":https://android.googlesource.com/platform/system/core/+log/master/libpixelflinger software renderer. Development on both these libraries ceased in 2013 and no work was done to support newer GLES versions.

The major consequences of this are that:

* Critical applications like web browsers crash due to lack of GLES 2.0 (#705). Replicant currently uses an out-dated browser that has many security flaws.

* Replicant relies on patches to the Android framework to make things like the camera application work.

* The rendering speed has degraded over the newer Android versions, like Android 6. Even applications that do not crash become difficult to use due to the huge rendering delays.

This task aims to fix all these severe issues by putting together a new graphics stack for the Android 9 port. This new graphics stack must be compatible with Android 9 Hardware Abstraction Layers (HAL) and provide at least GLES 2.0 rendering. It should be flexible enough to do software rendering with "Mesa":https://www.mesa3d.org/intro.html or "SwiftShader":https://swiftshader.googlesource.com/SwiftShader (Google's current software renderer), and also GPU rendering on devices where a free GPU driver is available.

"Joonas Kylmälä":https://redmine.replicant.us/users/8585 has done some introductory work on the Android 9 port for the i9305, and found a way to have it rendering to the screen. He put together a graphics stack composed of: gbm_gralloc ("Gralloc HAL":https://source.android.com/devices/graphics/implement#gralloc_hal) + drm_hwcomposer ("Hardware Composer HAL":https://source.android.com/devices/graphics/implement#hardware_composer_hal) + Mesa with kms_swrast driver with softpipe backend (CPU software renderer for GLES). This will be the starting point for this task.

Joonas' prototype shows that Replicant can use "gbm_gralloc":https://osdn.net/projects/android-x86/scm/git/external-gbm_gralloc/summary, an existing graphics memory allocator (gralloc) HAL maintained(ish) by Android-x86, in conjunction with "drm-hwcomposer":https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer, a libre implementation of Android's Hardware Composer HAL based on Linux's DRM, to achieve software rendering with Mesa. This solution avoids the need to write a custom gralloc for Replicant, and takes advantage of the hardware acceleration for composition provided by drm-hwcomposer on devices with a free software DRM driver (e.g. exynos-based smartphones and tablets).

Much more testing is needed to confirm that gbm_gralloc can be the definitive gralloc HAL on Replicant 9. It still wasn't tried with SwiftShader, or even Mesa's llvmpipe backend, which is a must since the softpipe backend is too slow to be usable.

Joonas' tests showed that some other components will need our attention, mostly the drm/exynos driver. In order to make drm/exynos work with gbm_gralloc and drm-hwcomposer Joonas had to disable "DRM-Auth":https://en.wikipedia.org/wiki/Direct_Rendering_Manager#DRM-Master_and_DRM-Auth and hack some missing pixel formats into it by using the default pixel format for everything. Besides drm/exynos, we will also have to make the graphics stack work with the "virtual GEM (vGEM) driver":https://www.phoronix.com/scan.php?page=news_item&px=DRM-vGEM-Mesa-Software, in order to support devices that lack a real drm driver.

The major and first goal of this task is thus to build upon Joonas's prototype and put together a stable and fully free graphics stack, compatible with GLES 2.0, that does software rendering through Mesa's llvmpipe with a decent performance.

*Hardware requirements*: A computer that is able to build Replicant. A Samsung Galaxy S3 or S3 4G to run the [[Porting_Replicant_to_Android_9|current Replicant 9 port]].

*Difficulty*: Medium / Hard

*Requirements/Prerequisites*: Knowledge of C++, kernel interfaces knowledge or the ability to learn them

*Expected outcomes*:

* Graphics stack with decent performance on software rendering

* Working GLES 2.0 implementation

* Fast enough graphics

* F-Droid applications not crashing anymore because of GLES.

*Time +estimation+*:

|_. Step |_. man-hours |

| Set up the development environment, including the current Replicant 9 port on the test device. |>. 24 |

| Read AOSP documentation and understand all details of the graphics stack. |>. 16 |

| Adapt the build files to use Mesa's llvmpipe backend instead of softpipe. Fix potential LLVM version incompatibilities between Mesa and Android. |>. 40 |

| Properly implement the missing pixel formats in drm/exynos and try to have it merged into upstream. |>. 72 |

| Find a proper way to use DRM-Master and DRM-Auth with gbm_gralloc and drm-hwcomposer. |>. 40 |

| Create test scenarios and check if the graphics stack works as expected. Consider "alternative grallocs":https://redmine.replicant.us/projects/replicant/wiki/GraphicsResearch#Gralloc if necessary. |>. 40 |

| Make the graphics stack work with vGEM driver besides drm/exynos. |>. 40 |

| Document the design decisions. |>. 16 |

|_. TOTAL |_>. 288 |

h4. Subtasks

The following sub-tasks could also be worked on after finishing writing the gralloc:

* [[Tasks_funding#SwiftShader|SwiftShader]]

* [[Tasks_funding#llvmpipe optimizations|llvmpipe optimizations]]

* [[Tasks_funding#Lima driver|Lima driver]]

h4. SwiftShader

"SwiftShader":https://swiftshader.googlesource.com/SwiftShader is Google's current software renderer that is capable of GLES 2.0 and is now "under work to support Vulkan":https://swiftshader.googlesource.com/SwiftShader/+log/master.

Mesa is the preferred renderer on Replicant for several reasons such as its support for both software and hardware (GPU) rendering, and its big community, with hundreds of active contributors. However, Mesa lacks a Vulkan software renderer. With Vulkan soon becoming a "requirement for new Android versions":https://android-developers.googleblog.com/2019/03/introducing-android-q-beta.html, we must make sure that Replicant's graphics stack can use SwiftShader in order to become futureproof. Furthermore, SwiftShader was built with performance in mind, specially for ARM CPUs, and may bring speed improvements on some devices.

The goal of this sub-task is thus to create a compile-time or run-time option that allows using Replicant 9 with SwiftShader as it's software renderer instead of Mesa.

*Hardware requirements*: A computer that is able to build Replicant. A smartphone or tablet that is supported by Replicant to be able to test the result.

*Difficulty*: Medium

*Requirements/Prerequisites*: Knowledge of C++, Makefiles and git. Android's graphics stack knowledge or the ability to learn them.

*Expected outcomes*:

* SwiftShader running on Replicant.

* Working Vulkan implementation.

*Time +estimation+*: 40 man-hours.

h4. llvmpipe optimizations

Mesa is a highly versatile library that can be extended with device drivers to allow it to be used in different environments ranging from software emulation to complete hardware acceleration. One such driver is the "Gallium llvmpipe driver":https://www.mesa3d.org/llvmpipe.html, which is a software rasterizer that uses LLVM to do runtime code generation. It only needs a CPU to run graphics computations and thus brings full GLES support to all Replicant devices.

"llvmpipe has been integrated in Replicant 6":https://git.replicant.us/replicant/external_mesa3d/log/ but it's not activated by default yet as it is very slow. It is also not fully complete.

To fix that, llvmpipe and/or the integration of it in Replicant should be optimized. We should first start by configuring llvmpipe and/or Mesa "to not implement very expensive OpenGL operations":https://www.mesa3d.org/perf.html. If that's not sufficient, or if that breaks application compatibility, various software or hardware features ("ARM NEON":https://www.arm.com/products/processors/technologies/neon.php, hardware 2D acceleration, etc) could be used to improve the speed.

Considerable speed improvements may be achieved with a fine-tuned emulation for division instructions. The ARM cores on many Replicant devices do not have hardware "support for the SDIV/UDIV instructions":https://community.arm.com/processors/b/blog/posts/divide-and-conquer. We should profile some apps and check whether GLES functions requiring divisions are to blame for the poor performance.

*Hardware requirements* : A computer that is able to build Replicant. A smartphone or tablet that is supported by Replicant to be able to test the result.

*Difficulty*: Medium / Hard (depending on the amount of optimizations required)

*Requirements/Prerequisites*: See with Mesa project

*Expected outcomes*: faster llvmpipe on ARM devices, able to run apps such as Fennec F-Droid (Firefox).

*Time +estimation+*:

|_. Step |_. man-hours |

| Setup a "testing and benchmarking environment":https://source.android.com/devices/graphics/testing |>. 40 |

| Disable expensive OpenGL operations. Check speedup and stability. |>. 24 |

| Recap matrix operations (Linear Algebra) and study ARM NEON. |>. 48 |

| Do a profiling of several apps to find the most used GLES operations. |>. 32 |

| Use "Ne10 library":https://github.com/projectNe10/Ne10 or "Neon Intrinsics":https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics for the most used GLES operations. |>. 80 |

| Fix bugs, re-write the code where needed, get it stable. |>. 80 |

|_. TOTAL |_>. 304 |

h4. Lima driver

"Lima":https://gitlab.freedesktop.org/lima is a free software Mesa driver for ARM Mali-4xx (Utgard) GPUs. These GPUs are present in several Replicant supported devices such as Galaxy S2, S3, S3 4G, Note and Note 2. 

Lima aims to full GLES support but it is still in development. However the "current implementation status":https://gitlab.freedesktop.org/lima/mesa/issues/39#note_79193 already allows the hardware acceleration of several tasks. GPU-based hardware acceleration is faster and less power hungry than software rendering, both by several orders of magnitude. It would allow Replicant devices to run applications with a performance close to that of non-free devices.

*Hardware requirements* : A computer that is able to build Replicant. A Replicant device with a Mali-4xx GPU that can run mainline Linux (e.g. Galaxy S3 or Note 2).

*Difficulty*: Medium

*Requirements/Prerequisites*: "See with Lima project":https://gitlab.freedesktop.org/lima/web/wikis/home#build-and-install

*Expected outcomes*: Lima driver being used for GLES rendering on a supported device.

|_. Step |_. man-hours |

| Rebase "Lima's Linux kernel DRM driver":https://gitlab.freedesktop.org/lima/linux on top of "forkbomb's Midas on Mainline kernel":https://blog.forkwhiletrue.me/pages/midas-mainline/. |>. 80 |

| Replace mainline Mesa for "Lima's Mesa":https://gitlab.freedesktop.org/lima/mesa (with their driver).  |>. 16 |

| Build and test thoroughly with "synthetic":https://source.android.com/devices/graphics/testing and real applications. |>. 40 |

| Create a fallback mechanism that uses the software renderer for GLES functions not yet implemented in Lima. |>. 100 |

|_. TOTAL |_>. 236 |

h4. Software Bill of Materials

* "Replicant 9":https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9

* "Mesa":https://www.mesa3d.org/intro.html (in particular: "Gallium llvmpipe driver":https://www.mesa3d.org/llvmpipe.html)

* "gbm_gralloc":https://osdn.net/projects/android-x86/scm/git/external-gbm_gralloc/summary

* "drm-hwcomposer":https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer

* "Linux kernel":https://www.kernel.org/ (in particular: drm/exynos driver and "vGEM driver":https://www.phoronix.com/scan.php?page=news_item&px=DRM-vGEM-Mesa-Software)

* "SwiftShader":https://swiftshader.googlesource.com/SwiftShader

* "Ne10 library":https://github.com/projectNe10/Ne10

* "Neon Intrinsics":https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics

* "Lima":https://gitlab.freedesktop.org/lima

h4. "Graphics acceleration on Replicant" nlnet Grant application

|_. Project name | Graphics acceleration on Replicant |

|_. Website / wiki | https://redmine.replicant.us/projects/replicant/wiki/Tasks_funding#Graphics-acceleration |

Abstract: Can you explain the whole project and its expected outcome(s) in 1200 characters

<pre>

Replicant is a fully free software Android distribution which is approved by the

FSF. All supported devices on Replicant currently lack a free software driver

for their GPU. As such, OpenGL ES (GLES) rendering must be done on the CPU

through software rendering (SR).

Replicant's current renderer is both incomplete and slow. It causes essential

apps like web browsers to crash due to lack of GLES 2.0, and many other

apps run too slow to be usable.

This project aims to fix this by complementing Android's 9 graphics stack.

Adding a few missing components will created of a fully-free, fast and compliant

graphics stack.

First we will write a gralloc (graphics memory allocator) tailored for SR that

is compatible with drm-hwcomposer (a libre implementation of Android's Hardware

Composer HAL). This gralloc enables drm-hwcomposer to work with SurfaceFlinger

and SwiftShader, creating a stack capable of GLES 2.0 on the CPU of all Replicant

devices.

Afterwards we will integrate and optimize Mesa's llvmpipe SR, which offers better

community support than SwiftShader. As last step we will add support for the

Lima driver, which will bring an even faster GPU-backed GLES to at least 5

devices.

</pre> 

|_. Have you been involved with projects or organizations relevant to this project before?

And if so, can you tell us a bit about your contributions? | SEE TEMPLATE |

|_. Requested Amount (Between 5000 and 50000 Euros) | 50000 Euros |

|_. Does the project have other funding sources, both past and present? | SEE TEMPLATE |

Explain what the requested budget will be used for? 

<pre>

The budget will only be used to fund this project through contract work.

We estimate that this project should take 868 man-hours to reach full completion,

with 632 man-hours being enough to reach all software rendering goals, leaving only

the GPU rendering to be done. A detailed run-down of this estimate is available at

https://redmine.replicant.us/projects/replicant/wiki/Tasks_funding#Graphics-acceleration

So far we have a team of two people interested on working on this project (the

two authors and submitters of this application). Both can commit to the project

on a part-time regime (17.5 hours per week), which means that the project should

be fully completed in about 6 months.

We will make sure that everybody has a chance to apply for doing contract work.

If we take the cost of a freelance developer in the USA (75 to 150 USD

per hour) as a basis, to enable people living in Europe and the USA

to apply, we can fund between 380 and 760 man-hours with the 50000 EUR budget.

This should be enough to cover all work on software rendering plus the initial

work on GPU rendering.

As happens on all software projects, getting a precise time/effort evaluation is

a difficult endeavour, specially when dealing with a project that is heavy on

research such as this one.

If the software rendering goals are not reached when the 50000 EUR budget runs

out, or if the Replicant project deems it necessary to have GPU rendering, it

will use its existing funds to pay for contract work if no volunteers are found

to finish the project.

The Replicant project will also make sure that the people working on this project

have the necessary hardware to do it, for instance by shipping or reimbursing the

purchase of a compatible smartphone with the Replicant project funds.

</pre>

Compare your own project with existing or historical efforts.

<pre>

Past Replicant versions have relied on patches to the Android framework to make

software rendering work. These patches were quite specific for Replicant and

had no use elsewhere. This made them unfit for upstreaming or sharing with any

other project.

Android's Project Treble new graphics stack allows us to follow a different

approach this time. Instead of patching the Android framework, we will

implement one of the well defined Android HALs (Hardware Abstraction Layer):

the gralloc HAL. The end result will be a software library that can prove to be

useful on several projects besides Replicant (e.g. Android-x86 project) and

thus fit for upstreaming.

Furthermore, past Replicant versions relied on Google's software renderers

(ligAGL and libpixelflinger) for OpenGL ES support. As quite a few other

Google's open-source projects, these two had no community behind them and got

stalled as soon as Google deprecated them.

This time will we take a different approach. Although our first graphics stack

will rely on Google's SwiftShader renderer, we will then move our efforts into

Mesa. Mesa is a big community project, with hundreds of active contributors and

great community support. It includes the llvmpipe software renderer along with

new drivers in development for GPUs present on current and future Replicant

devices. Mesa should provide a stable and maintained platform for years to come.

</pre>

What are significant technical challenges you expect to solve during the project, if any?

<pre>

We expect to solve significant technical challenges during this project:

1. Implementation of the first Android gralloc library compatible with software

rendering.

2. Development of free-software benchmarks for OpenGL ES on Android, used to test

our optimizations to llvmpipe.

3. Optimization of llvmpipe by at least one order of magnitude.

4. Running an exynos based smartphone with fully free-software GPU graphics

acceleration.

</pre>

Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?

<pre>

This project will re-use code from several projects such as Android,

drm-hwcomposer, Mesa and Lima driver. Whenever possible we will foster

collaboration with these projects and submit our changes upstream.

The Replicant project contributors and the FSF will supervise

contractors to do the work.

A blog post will announce that the Replicant project

has got some funding for this specific task, and that it is

looking for a contractor to work on it. This is to make sure

that everyone has equal chances in the application process.

Then the most suited contractor will be selected. Only contractors

that already have worked on similar tasks as part of free and open

source software projects will be chosen. This way we can look at

their existing contributions and make sure that they are able to

do the task before engaging with them.

The Replicant project will also make sure that the contractor has

or gets the hardware required to work on the task, before starting

to work on it.

</pre>

|_. Attachments | SEE TEMPLATE |

h3. 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).

*Hardware requirements* : A computer that is able to build Replicant. A smartphone or tablet supported by Samsung-RIL.

*Difficulty*: Medium to Hard

*Requirements/Prerequisites*: Knowledge of C.

*Expected outcomes*: Implement the missing features listed at [[Samsung-RIL]]. When all the features have been implemented, also ask usptream (LineageOS) if they want to use libsamsung-ipc and samsung-ril.

*Dependencies*: This task should be fairly independent as:

* [[Libsamsung-ipc]] should already be independent of the Android version (it can even run on GNU/Linux)

* [[Samsung-RIL]] can probably easily be adapted to newer Android version

*Funding*: We could apply to https://nlnet.nl/PET

h4. "Complete libsamsung-ipc and libsamsung-ril" nlnet Grant application

|_. Project name | Complete libsamsung-ipc and libsamsung-ril |

|_. Website / wiki | https://redmine.replicant.us/projects/replicant/wiki/Samsung-RIL |

Abstract: Can you explain the whole project and its expected outcome(s).in 1200 characters

<pre>

Replicant is a fully free Android distribution that is

approved by the FSF (http://gnu.org/distros). It supports

several Samsung smartphones tablets that have a modem.

The modem can be thought as a separate computer in a chip that

is dedicated for interfacing with the cellular network.

Many use custom protocols that are implemented by nonfree software

to communicate with the smartphone OS (Android). This has issues:

https://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor

The Samsung IPC protocol is used by the modems of the devices

currently supported by Replicant, and in many other Samsung

smartphones and Tablets.

Replicant implemented it in:

- libsamsung-ipc: the low level protocol implementation

- libsamsung-ril: the interface between libsamsung-ipc and Android

The project consists in implementing their missing features, which

are known and documented in the RIL API. They are things like

"start a conference call".

When they are completed, we expect other Android and GNU/Linux

distributions to start using and contributing to these libraries.

This will also lower our maintenance burden and improve Replicant

usability and compatibility with networks.

</pre>

|_. Have you been involved with projects or organizations relevant to this project before?

And if so, can you tell us a bit about your contributions? | SEE TEMPLATE |

|_. Requested Amount (Between 5000 and 50000 Euros) | 50000 Euros |

|_. Does the project have other funding sources, both past and present? | SEE TEMPLATE |

Explain what the requested budget will be used for? 

<pre>

The budget will only be used to fund this task through contract work.

We think it will take something between 3 and 4 month of work

for one full time developer.

If we take the cost of a Freelance developer in the USA (75$ to 150$

per hour) as a basis, to enable people living in Europe and the USA

to apply, we can fund a developer to work on it for a period that

is mostly equivalent to something between 2 to 4 months full

time.

The Replicant project will take care of ensuring that the

people who will work on this task have the necessary hardware to

do it, for instance by shipping or reimbursing the purchase of a

compatible smartphone with the Replicant project money.

</pre>

Compare your own project with existing or historical efforts.

<pre>

Here, implementing the missing features will be done in the same

way than before, which is running the proprietary implementation

and understanding the data format of the data going from/to the modem

that is gathered either with strace or by patching the kernel, and

implementing the feature in libsamsung-ipc and libsamsung-ril.

</pre>

What are significant technical challenges you expect to solve during the project, if any?

<pre>

There is currently no CDMA support at all in Replicant

and libsamsung-ril/libsamsung-ipc.

A lot of areas in the world don't have any CMDA coverage,

so testing the implementation could be challenging as it

would either require the contractor to live in an area

with CDMA coverage, or to be able to build a cheap CDMA

infrastructure to be able to test the implementation.

If we don't have good enough assurances that implementing

CDMA is doable, that will not be attempted.

</pre>

|_. Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes? | SEE TEMPLATE |

|_. Attachments | SEE TEMPLATE |

h3. 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.

*Hardware requirements* : A computer that is able to build Replicant. A smartphone or tablet supported by QMI-RIL like the Galaxy SIII 4G (i9305).

*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.

*Dependencies*: This task should be fairly independent as:

* The lower layers should already be independent of the Android version as they are used under GNU/Linux

* [[QMI-RIL]] can probably easily be adapted to newer Android version

*Funding*: We could apply to https://nlnet.nl/PET

h3. Finish to port the Galaxy S III (I9300) and the 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.

*Hardware requirements* : A computer that is able to build Replicant. A Galaxy S 2 (I9100), Galaxy S 3 (I9300) or Galaxy Note 2 (N7100), and a serial port adapter to get the kernel boot logs.

*Difficulty*: Medium

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

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

h4. "Finish to port the Galaxy S III (I9300) and the Galaxy Note 2 (N7100) to Mainline Linux" nlnet Grant application

|_. Project name | TODO |

|_. Website / wiki | https://redmine.replicant.us/projects/replicant/wiki/Upstream#Replicant-supported-Samsung-Exynos-devices |

Abstract: Can you explain the whole project and its expected outcome(s).in 1200 characters

<pre>

Replicant is a fully free Android distribution that is

approved by the FSF (http://gnu.org/distros).

TODO

</pre>

|_. Have you been involved with projects or organizations relevant to this project before?

And if so, can you tell us a bit about your contributions? | SEE TEMPLATE |

|_. Requested Amount (Between 5000 and 50000 Euros) | 50000 Euros |

|_. Does the project have other funding sources, both past and present? | SEE TEMPLATE |

Explain what the requested budget will be used for? 

<pre>

The budget will only be used to fund this task through contract work.

We think it will take something between 3 and 4 month of work

for one full time developer.

If we take the cost of a Freelance developer in the USA (75$ to 150$

per hour) as a basis, to enable people living in Europe and the USA

to apply, we can fund a developer to work on it for a period that

is mostly equivalent to something between 2 to 4 months full

time.

The Replicant project will take care of making sure that the

people that will work on this task have the necessary hardware to

do it, for instance by shipping or reimbursing the purchase of a

compatible smartphone with the Replicant project money.

</pre>

Compare your own project with existing or historical efforts.

<pre>

TODO

</pre>

What are significant technical challenges you expect to solve during the project, if any?

<pre>

TODO

</pre>

|_. Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes? | SEE TEMPLATE |

|_. Attachments | SEE TEMPLATE |

h1. Other tasks

h2. Tasks that are being defined

h3. Test infrastructure

Having an automated build and test infrastructure would be very beneficial for Replicant.

Issues:

* Running costs of such infrastructure have to be kept low, not to depend on continuous flow of money

h3. Documentation

A lot of time is spent on the wiki documentation, and a lot of information is redundant (for instance the installation guide)

TODO:

* Research documentation systems

* Research the technical knowledge required to use them

* Look into communities like RockBox on the benefit of non-wiki documentation

* Look if transitioning to non-wiki documentation would make the Replicant Project loose its contributors to the documentation

h2. Devices with 512M of RAM or less

We might want to consider Android 9 [[HardwareRequirements]] before working on that

h3. 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.

*Hardware requirements* : A computer that is able to build Replicant. An Optimus Black with u-boot and modified boot pins, a serial port adapter to get the kernel boot logs.

*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

h3. 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.

*Hardware requirements* : A computer that is able to build Replicant. A Kindle Fire first generation, a serial port adapter to get the kernel boot logs.

*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. 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.

*Hardware requirements* : A computer that is able to build Replicant. An Allwinner tablet, a serial port adapter to get the kernel boot logs.

*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.

h2. Tasks for Replicant 6.0

h3. Tackle security issues in Replicant 6.0

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.

*Hardware requirements* : A computer that is able to build Replicant. A smartphone or tablet that is supported by Replicant to be able to test the result.

*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 in Replicant 6.0

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.

*Hardware requirements* : A computer that is able to build Replicant. A smartphone or tablet that is supported by Replicant to be able to test the result.

*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.

h2. Research

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.

*Hardware requirements* : An ath9k_htc compatible WiFi card, the ability to measure the current usage, the ability to build the ath9k_htc firmware and driver.

*Difficulty*: Medium/Hard

*Requirements/Prerequisites*: Knowledge of C

*Expected outcomes*: Reliable WiFi with external WiFi adapter