Replicant current status:

The last Replicant release is still based on Android 6.0.

In the previous years, a lot of work was done to make the Galaxy SIII (GT-I9300) usable with an upstream kernel, both on graphics and on the modem.

While working on this report we also found that the removal of 3G networks was more a serious problem than we originally understood.

As we understand from the Wikipedia article on 2G , GSM networks are also being removed in Europe as well (where most Replicant users probably reside). If somehow we understood it wrong please contact us on the Replicant mailing list as this has big implications for Replicant.

This means that none of the currently supported devices will continue to work on non-community networks in most areas of the world.

About a year ago, the current Replicant maintainer talked with someone that knows well European regulations and that person told him that there was no chance to stop 3G from being removed (for instance through legal activism) due to the low number of users still using 3G. Since we didn’t ask about GSM at the time, we have no idea if that can be blocked or not or how much effort that requires.

In any case it means that the only way forward for Replicant is to make sure it (also) supports devices that work on 4G networks.

Furthermore such devices should also have VoLTE (Voice over 4G networks) ; otherwise, although they would be able to get Internet over 4G networks, they could not to make regular calls or send SMS.

Unfortunately even the Galaxy SIII 4G (GT-I9305) which is a Galaxy SIII (GT-I9300) with a different modem doesn’t support VoLTE. So we cannot reuse most of the Replicant work we did.

Even if in some areas of the world (like some European countries), the devices currently supported will continue to work for very few years, and there was a big amount of work done to make these devices usable with more recent Android versions, a lot more work is needed to make that work usable daily (making power management work, debugging complex issues, etc).

The majority of recent devices (like newer Samsung smartphones) have too many freedom issues, making them unsuitable for Replicant.

Remains the PinePhone:

• The hardware already works under GNU/Linux.
• The battery life (in hours) is now almost good enough. Furthermore, it is possible to buy an additional keyboard that has a builtin battery to extend it more.
• There is an Android distribution (GloDroid) that supports the PinePhone. It has some usability issues that need to be fixed: modem disappearing on some models, no cellular data, no modem isolation, etc.

The PinePhone Pro and Librem 5 could also be supported but they are not high priority right now due to incomplete power management (PinePhone Pro) and high cost (Librem 5).

In light of this, the current Replicant maintainer applied for funding through NLnet (again) to fix some of the PinePhone’s issues and support it in Replicant. This application was accepted but he ended up being sidetracked by another project instead of working on that.

He got involved in what became GNU Boot and planned to have the project in good state by the end of the last summer, in the hope the work could be reused to ship a bootloader for the PinePhone in the next Replicant version.

See the GNU Boot 0.1 RC3 announcement and the NLnet funding application for more details.

Unfortunately the work on GNU Boot took way longer than anticipated, being unfinished yet. Because of that the work on the PinePhone didn’t even start.

In addition to that, the main Replicant maintainer was also demotivated (he did a lot of work that turned out not to be that useful) and he thought that the project was poorly managed by him. He was trying to understand what went wrong and how to fix it. Going to the 37C3 to find help was part of the fixing plan.

Identified issues:

Discussions between GNUtoo, dllud (both Replicant contributors) and several people we met during the 37C3 or on the train going to it converged to the same points and together we identified several issues:

Replicant has not enough people:

• A diversity of profiles helps solving issues and not be stuck. It also helps keeping the motivation as different people are good in different areas and thus people can more easily work on what they are good at and like to work on.
• We cannot expect a single person to take care of the community, help new contributors, handle project management, keep relationships with other communities, keep track of what work is getting done elsewhere to improve collaboration, manage the infrastructure (servers) and modernize it a bit, and at the same time work on the code towards new releases. So far the current maintainer has been switching from a set of tasks to another but that didn’t really work out.

It’s too difficult to contribute to Replicant:

• It requires computers that are not commonly available among people: to build Replicant you need a lot of free space (200+ GiB), a fast internet connection to download more than 50 GiB, 32 GiB of RAM or more (for recent Android versions), and sometimes run specific versions of distributions.
• It requires specific hardware like a Galaxy SIII (GT-I9300). People can’t help with commonly available emulators or single board computers.
• There is extensive documentation but it’s scattered around. Documentation is also lacking for the tasks that are the most important for Replicant (porting Replicant to newer Android versions). Though we can also have people helping new contributors again to compensate for documentation issues.
• We have a list of tasks and required skills for them but we lack information about the importance of the tasks. We also need to organize a bit how to assign tasks to people according to their skills and will. We were also advised to break the important tasks in more details.

Plan forwards:

Very short terms plans:

• Write this report: As we were not always discussing with the same people at the conference this should help us share information between ourselves and also with all the people that helped Replicant at the conference, to better organize the next steps.
• Setup a Replicant meeting online at a fixed time, on IRC/Big blue button/Jitsi/Mumble. If new people come we would do a short introduction and people would present themselves (especially what they are interested in).
• Re-run the call for the Community Manager. We will run almost the same call as before so the work will be less than last time. We will be looking for a candidate that can do a subset of the tasks in the call. As we were told multiple times that “Community Manager” was not describing the job well, we are also looking for a better term but so far no one found one that would feel right.
• Amend the NLnet proposal to include GNU Boot work as well to solve our dilemma.

Medium term plans:

• Find a way to get a build server. A KGPE-D16 would be a good idea. The FSF can probably buy it and host it for us.
• Work on the PinePhone (and on GNU Boot as well).

Long term plans:

While discussing with NLnet we were also told that it might be useful to collaborate more with DivestOS as part of our goals are similar. So we will need to evaluate again if there is enough proximity in our code to collaborate.

In the past people from DivestOS were really helpful as they found nonfree software inside Replicant and reported it to us.

Apart from that we don’t have long term plans yet. Once we have a Replicant release that supports the PinePhone, we will need to decide where to go next.

For instance we could support more devices, reduce the amount of work for adding support for newer Android versions, reduce the differences between GNU/Linux and Android, or simply keep Replicant up to date by supporting more recent Android versions with minimal work.

Right now we also didn’t spend much of the Replicant money and beside paying for a “Community Manager” we don’t have precise plans yet.

We have about $200 000 and so far we relied on funding from NLnet to bring Replicant back on track as it was easier not to mess up this way.

Money goes away fast and spending it all in the wrong direction would prevent Replicant from using it to become more sustainable. Very few projects have an opportunity to use money to grow or achieve more.

Instead most of the ones that want to grow and become (bigger) non-profits are stuck in a chicken and egg issue as they need more money (that they don’t have) to achieve more, which in turn leads to a greater need for donations.

As such, getting the project back on track before even starting to evaluate how to use the money to do big changes to the project seems a good idea, as many projects were destroyed after getting too much money and failing to properly use it.

Other advices for medium/long term:

• One person also told us that businesses have interesting methodologies like “tracer bullets” in Agile methodology, or “Business model canvas” or some emotional approaches to tasks that might be worth looking at as they can work for non-commercial projects as well and can be adapted to a wide variety of cases.
• One of the people we talked to insisted on the importance of finding a good team and finding ways to divide tasks between people. For that person it was also important to find people that could work well together and that agreed on the same goal (to avoid infightings).
• We could also delegate more sysadmin work to the FSF: It would require less time from our side without compromising on freedom and with minimal extra work for the FSF sysadmins if we don’t require custom things.
• We were also warned that delegating tasks among ourselves still require time to organize. According to that person, in many cases if a person delegates a task, only 50% of the time is saved.

Other area of work:

Android SDK:

The main advantage of Replicant over other GNU/Linux distributions certified by the FSF is that it can run Android applications, but that is only relevant if there are 100% free software Android applications.

Somewhat recently we found out that it was no longer possible to know if Android applications shipped by F-Droid are really free, as F-Droid now uses the nonfree Google SDK to build the applications. As such we don’t know if they build with another SDK on FSF certified GNU/Linux distributions. We want to help fix that to make sure the solution really suits our needs.

If there were fully free drop-in replacement SDKs that also build on a 100% free distributions, that issue could be fixed for both F-Droid and Replicant. F-Droid may have further requirements as they probably have higher security demands than Replicant. For instance, they probably won’t like to depend on the (free software) binaries shipped in the SDK source code that are used to build it, and would rather build everything from source.

In the times of Replicant 4.2 (based on Android 4.2) Replicant produced its own SDK. After that several GNU/Linux distributions (Debian and some Debian derivatives) started shipping a fully free SDK for Android 6.0 so Replicant stopped producing newer SDKs.

Nowadays Debian and PureOS still package an Android 6.0 SDK but don’t support more recent versions of Android. They also don’t support the NDK that supports languages like C. F-Droid probably used these SDKs for a while, specially because they are completely built from source from well known distribution(s), but many Android applications don’t build anymore with these old SDKs.

After that, free SDKs for various Android versions started being released at https://android-rebuilds.beuc.net, but the main author of this work at some point moved on.

After that several people tried to continue that work somehow and published source code that can build SDKs but none published the SDK binaries.

In the GNU 40 conference in Switzerland, the current Replicant maintainer met the person behind SDK rebuilds (beuc.net) and also someone interested in giving resources (like server space) to build an SDK.

In the 37C3 we met additional people:

• Starfish, that wrote potentially 100% free Android applications and that also publishes source code to build a free Android SDK. His applications build with this free SDK.

  Starfish doesn’t publish binaries in order to avoid dealing with license compliance in case something is wrong in the SDK binaries. Replicant is happy to do that.

  Starfish can also accept contributions and bug reports for supporting FSF certified GNU/Linux distributions and for removing nonfree software from the SDK if any if found.

  As a bonus we also reviewed the applications that Starfish wrote so if the SDK works on 100% free distributions we’ll also have 100% free applications to promote to people without any freedom caveats.

• Another person (wizzard) jumped in to automatize the builds, making them run unattended on each new release.

So thanks to all these people everything is now in motion to get the SDK problem fixed once for good and in a better way than before: one that makes sure people can actually build Android applications with 100% free software.

Conferences:

At the 37C3 we managed to understand Replicant issues and a way forward probably because we started discussing the project issues in advance, which allowed just enough understanding to be able to ask for help. If we didn’t do that we probably would not have managed to get help that is that useful.

37C3 talks and interesting people:

While we (GNUtoo, dllud, and the people that helped us) did a lot at the congress (and even too much since we missed our own lightning talk due to too much cognitive load) at the end we managed to achieve the most important goal: finding a path forward for Replicant.

Alongside our main goal of putting the project back on track, we found time to host a variety of talks and events:

• We had an official Replicant assembly where people could meet us.
• We did a presentation named Smartphones freedom status in 2023 which looked at smartphone hardware and operating systems available in 2023. It wasn’t recorded. The slides are available as PDF and source code .

  At the end of the presentation, after the questions, we also got some feedback:

  • We were told that there are more applications for GNU/Linux that work on smartphones than what we assumed. They are referenced in https://linuxphoneapps.org and they also list applications available in PureOS landing (a rolling release version of PureOS) and Guix . Still they probably have less applications available than on F-Droid but things are progressing in the right direction.
• We also did a talk presenting the Replicant as part of the Critical Decentralization Cluster . Unfortunately it wasn’t recorded due to a technical issue, but we re-did it again the day after on a longer format . The slides source code and PDF are available.
• We did a presentation on the status of Replicant . It wasn’t recorded so if you want to know what was said, the slides are available , but you also need to read the presentation.txt to understand it.
• As a follow up to the presentation on the status of Replicant, we also had a meetup on the last day where we had discussions with the people attending the talk.
• We met someone repurposing smartphones who told us that on some Samsung smartphones/tablets, erasing the PARAM partition (with dd if=/dev/zero) sometimes removes restrictions that prevent the phone from booting custom distributions.
• Among those helping us, there was someone interested in using Replicant for education. The most problematic issue found is that the current requirements to work on Replicant are too much for students. Supporting single board computers or emulators would be a first step to help here. In general this would help finding new contributors.

OFFDEM / FOSDEM 2024:

The main maintainer of Replicant had already planned to go to an event of OFFDEM (an alternative conference to FOSDEM) on Friday night, and also to FOSDEM 2024 on Saturday and Sunday. Train tickets were already bought before Replicant took the decision to go to the 37C3, so he kept the plan.

As expected it was not as useful as the 37C3 for Replicant (it was way more useful for GNU Boot) but still some interesting things happened:

• He met Hans-Christoph Steiner from F-Droid and explained the status on having a fully free Android SDK. He detailed our work to provide binaries by setting up an automated build system that reuses the maintained scripts to build the SDK and that runs on a FSF certified distribution (Trisquel) to make this solution also work for Replicant.
• He was introduced to people working on CalyxOS by Michiel from NLnet.

  Before that he thought that CalyxOS was deeply problematic because even if on paper CalyxOS had the same freedoms as LineageOS, its security system removed users control of the devices (users don’t have root, etc) and didn’t have access to their data.

  But in reality CalyxOS uses SeedVault , a backup application that enables users to backup their data and restore it on any other distribution that may not have the same security model. SeedVault is also used by most Android distributions. It is therefore a good idea to see how it can be integrated into Replicant, as it seems to be made with user’s empowerment in mind. It can backup data (encrypted) to an USB key, so users don’t need a server or external services.

  In addition he was told by a CalyxOS contributor that it is relatively simple for users to build CalyxOS with their own keys, and so be in full control of the device.

  He was also told that newer Android versions don’t need F-Droid privilege extension anymore due to the inclusion of an API for stores inside recent Android versions (thanks to some European regulations).

• He met someone who is working on understanding the European regulations that aim to standardize digital identity papers and the way to store it. He already met that person at the 37C3 but this time there was more understanding and more time to discuss the issue more in depth. The regulation has requirements for smartphones so it will most likely affect smartphones distributions that use free software drivers (like Replicant, various GNU/Linux distributions, etc.). If done wrong, it would prevent free software users from storing their identity papers in their smartphones with free software (for instance because it could be stored “securely” in areas of the phone inaccessible to users and free software). One of the issue is that this person looks for help to understand the technical parts, and also for some associations to help in the fight to modify the laws to fit free software. Since Replicant has very little time to look at this now, he referred her to the Osmocom project that already analyzes somewhat similar designs like eSIM.
• He also met with Tiberiu from Technoethical, a shop that sells FSF certified hardware and Replicant compatible smartphones (that aren’t certified by the FSF due to nonfree bootloaders and other issues). Technoethical will be negatively affected by Replicant’s decision to drop support for the current Samsung phones in future versions, as PinePhone will become the major focus.
• The main maintainer of Replicant also met with Paul Kocialkowski. Before that meeting he thought that on GNU/Linux the eg25-manager program for the PinePhone only did simple things like setting up udev rules and had simple hacks to make the modem work fine. He thought that all stability issues were to be handled by Modem Manager. However the EC 25 Manager may also be monitoring the modem and restarting it when it crashes. This could explain modem stability issues with Android/GloDroid on PinePhones with 3GiB of RAM. The fix may be to port/reimplement that feature to make this model usable.

 

Edits:

1. Refrased Technoethical paragraph.

This year the FOSDEM will take place in Brussels the 4 and 5 February.

This year there will be a talk about Guix evaluation and usage for/by the Replicant project: How Replicant, a 100% free software Android distribution, uses (or doesn’t use) Guix, by the current Replicant maintainer.

As not everybody is familiar with Replicant or free software on smartphones, it will also have some background information on hardware and software of freedom in smartphones with a focus on FSF certified distributions.

We hope to also use this occasion to build collaboration with other projects, especially other Android distributions that use kernels based on upstream Linux.

We may update this blog post if there are last minute changes (if the talk is moved) or if we have new interesting information (like interesting talk to attend, other events, etc).

Replicant 6.0 0004 is now officially released. If you want to upgrade from Replicant 6.0 version 0003 or earlier you need to follow the data migration procedure that is documented in the Release notes page on the Replicant wiki.

Even if we released the images back in January 2022, we didn’t announce it officially at the time because the data migration procedure wasn’t complete yet.

What is new in this release

Replicant is in the list of distributions that are recommended by the FSF. As such, Replicant needs to follow strict criteria that ensures that the distribution does its best not to violates its users’ freedom.

However fixing the issues and making new releases can sometime take a long time. The last Replicant 6.0 release was from December 2017.

This new release fixes some very serious freedom and privacy issues:

• We found an issue within the phone application: it was leaking the phone numbers of both inbound and outbound calls to third parties as part of a feature called phone lookup providers. More details are available in the bug report. Even if it was not trivial to reproduce and find the bug it’s now fixed as the feature has been completely disabled with 3 patches ([1], [2], [3]).
• F-Droid has been removed as many applications shipped in it are not compliant with the guidelines for distributions recommended by the FSF. It was kept so long because we expected to get it fixed upstream fast enough, but that didn’t happen for various reasons. We have setup a wiki page and a forum section for more information about the issue and how to deal with it.
• Several binary firmwares (without source code) related to the back and home “touch” buttons were found and removed with 4 patches ([1], [2], [3], [4]). The firmwares seem to have only been used for factory testing, so the buttons should still work on the devices that have them.
• The touchscreen firmware for the Galaxy Note 8.0 was also lacking any corresponding source code (bug #2194). That was fixed by removing it ([1]).
• On all the currently supported devices with a modem, when users set the device in flight mode, the modem is only asked to go in low power mode. Because of that the modem is probably still on and its OS is probably still running. Because of that we fixed the wiki and added scripts to disable (and enable back) the modem to the new Replicant images. They work by preventing Replicant to load the modem OS.
• We also got a report on the mailing list that a nonfree ambient SDK was added in CyanogenMod and was not removed either by LineageOS 13 or Replicant 6. So we removed it as well.

This release may also fix several bug(s) which made some SIM cards not recognizable by Replicant 6.0: we have now merged a fix for one of the bug (#1909) but as we don’t know if all the “SIM card not recognized” bugs are related. We would highly appreciate if those that opened the original bug report could confirm if it also fixes their issues as well.

Several issues still need to be fixed, but we didn’t want to delay even more this release, as that would prevent users from getting the fixes mentioned above:

• It’s still not possible to build Replicant 6.0 from a distribution that is recommended by the FSF (bug #1861).
• While removing the firmware of the Galaxy Note 8.0 touchscreen driver, many more firmwares without corresponding source code were found in the driver/touchscreen directory in the kernel used by most of the devices supported by Replicant 6.0. However they weren’t removed yet. Help is more than welcome to help with that.
• While investigating if it was possible to upgrade WebView, the Android builtin web browser component (bug #1786) we also discovered that, because Android build system doesn’t use a package manager, finding the license of each repository wasn’t trivial (bug #1973).
• More investigations are needed as well to replace WebView with a free software and up to date implementation (bug #1786).
• The bug related to a bad sound quality during calls in some circumstances (bug #1773) is not fixed yet, but there is a workaround that works for some use cases.
• The Let’s Encrypt certificates probably stopped working in Replicant 6.0 the first September 2021. Some browsers like IceCat should normally continue to work fine. See the Standing on Our Own Two Feet blog post by letsencrypt for more details.

As the internal WiFi doesn’t work with free software, some new network related features improving usability were merged :

• RepWiFi has been removed as it’s now possible to use the stock Android menus to handle the WiFi. This was done by patching Android to also accept external dongles. It is less reliable than with RepWiFi because in some cases reboots are needed for the WiFi to be recognized, and enabling the WiFi most probably also powers on the Internal WiFi chip as well, increasing the power consumption. However it should reduce the probability of applications like F-Droid being broken in the future, as it’s better integrated in Android. In the event that Replicant 6.0 stops being maintained and that Replicant 11 doesn’t get support for all the Replicant 6.0 devices, this patch should increase the lifetime of the affected devices.
• Ethernet support has been added but it doesn’t work on all the devices.
• The USB networking scripts were also been added to the devices.
• Support for some rt2500-usb dongles that don’t need the OS to load a firmware has been added to the Galaxy SIII 4G (i9305), which is an uncompleted device. It wasn’t added to the other devices to make the release happen a bit faster.

Other improvements were also made:

• llvmpipe is now the default OpenGL renderer. On devices with an Exynos CPU / System on a chip, this allows running many applications that weren’t working before. Unfortunately llvmpipe significantly slows down some system components used in the graphical interface. This has been catered for by patching Android to use the old libagl renderer for those system components.
• Scripts to switch between OpenGL implementations globally have been added to the image as well. Thus, if you want to revert back to the old behaviour, just run “graphics.sh faster” in a root terminal. To switch back to the new behavior you can instead use “graphics.sh compatible”. Note that “graphics.sh compatible” will still keep the old OpenGL implementation for the system components mentioned above, so there is little risk in trying the scripts.
• It’s now easier to build Replicant as there is a new script that wraps part of the building process. It’s also more convenient as it stores build logs. The script has been used to build the release, and the build instructions also use it now.
• It has became easier to modify the installation instructions as they now apply to all devices, and were split into parts that are reusable. This way if the instructions needs to be modified, it requires a single modification instead of 10 or 30 modifications like before.
• Instructions to backup the modem data partition have been added. The modem partition can become corrupted in some conditions. As it can be very difficult or impossible to recreate that partition, and that it’s required for the modem to work, we very strongly advise users to do a backup.
• A new wipe command has been added to wipe partitions, however it is not very well suited for wiping files. To efficiently wipe files another application or utility would need to be integrated.

Many of the improvements and fixes were also made possible thanks to the work of new contributors.

Replicant 11 status and policy changes for supported devices

Work on Replicant 9 has now shifted to Replicant 10 and then Replicant 11, and has been ongoing in parallel. As it will use a kernel closely based on upstream Linux, it has some implications:

• The work on Replicant 11 is made with the Galaxy SIII (i9300), so it should be supported.
• The Galaxy Note II (N7100) is very similar to the Galaxy SIII but requires a bit more work to be supported.
• The Galaxy SIII 4G (I9305) and Galaxy Note II 4G (N7105) could also be added if work is done to add support for their modem in Replicant.
• We don’t know yet how much work is needed to add support for the other devices that are currently supported by Replicant 6.0, so we don’t know yet if they will be compatible with Replicant 11 or not. We would need to find or get more information on the upstream status of theses devices before having a rough idea.
• It will be easier to add support for devices using a mainline kernel.

We also take advantage of this release to announce some policies changes:

• As Replicant 6 only supports devices with somewhat isolated modems, subsequent Replicant versions will also only support devices with isolated modems.
• As Replicant 6 only supports devices with replaceable batteries, subsequent Replicant versions will also only support devices with replaceable batteries.

The Replicant developers chose not to support these devices officially in Replicant for good reasons.

Supporting devices with non removable batteries ourselves has a lot of challenges:

• As Replicant 11 requires more work and working to upstream devices support in Linux takes more time than adding devices in Replicant 6:
  • if we start adding support for a device, we want to be able to spend the time required to do it right and to work with upstream projects like Linux to add support for it in theses projects as well. The advantage is that it makes Replicant and the device being added more sustainable. However if the device has a battery that is not replaceable by experienced users, developers, repair shops, or repair café, the device would have a very short lifetime which is incompatible with making Replicant sustainable.
  • Users would need to buy the device new in order to make sure that the battery lasts enough for a daily use. Buying the device second hand would be way more complicated as users would need to make sure that the battery last enough time. Developers would still be able to work on the device for a very long time, assuming that they are not users as well that want to use the device. But their work would not be very useful without usable devices.
  • In addition, being able to remove the battery of a device increase trust: for devices with a single battery, it’s easy to understand that without a battery, the device is really off. For devices with an additional backup battery, some background information on chip energy consumption is enough to understand what the device cannot do with such backup battery.

As for non isolated modems, if Replicant only support devices with isolated modems, it’s way easier for users and developers to remember that the devices they are using have a somewhat isolated modem.

However, as Replicant 11 is using a kernel closely based on upstream Linux, there is already some interest in adding support for devices already supported by Linux which have a non-isolated modem and/or a non-replaceable battery, and it would be sad to not be able to leverage all the work done in Replicant with these devices.

So practically speaking we are willing to help people and/or projects that are willing to support such devices. We are also accepting contributions in the Replicant source code for such devices provided that we can maintain the code without too much effort without having the devices.

So while anybody could test if the code still compiles fine, It will then be up to the people that have such devices to test if the code is still working over time. The code quality of such contributions may also have to be high as we want to keep maintaining that code over time without having the devices. The Linux kernel is already using a similar approach to be able to maintain support a lot of devices (including devices that the maintainers don’t have) without removing support for older devices.

We could even provide access to the Replicant infrastructure (for instance by creating Redmine sub-projects, opening new git repositories namespaces, and so on) to the people wanting to support such devices, but they would at least need to:

• Find a name that is different from Replicant for the project (to not confuse both projects, else it defeats the point of having some separation).
• Stay compatible with the strict FSF criteria as Replicant doesn’t want to host projects that are incompatible with such criteria. Though we already collaborate with other projects (which we don’t host) that aren’t compatible with such criteria.
• Take care of users support (as Replicant developers will probably not have these devices, so they won’t be able to test things to properly support users).
• Take care of the releases (as Replicant developers will probably not have these devices, they would not be able to test the releases).

As for the details on what constitute a “replaceable battery”, all the smartphones currently supported by Replicant 6.0 have removable batteries, so the batteries are very easy to replace. Compatible batteries can still be found in several cities and/or countries.

And for the tablets supported by Replicant 6.0:

• They all have batteries that are not removable in the usual meaning, but they can still be replaced by opening the device.
• It is easy enough for experienced users, developers, repair shops, and repair café to open the device and remove the battery, so it is probably possible to replace it as well.
• It would be interesting to know more about the availability of compatible batteries.
• It might also be possible to use tablets with batteries that last way less than when the device is new, as many people have them off most of the time. But even in that case it still shortens a lot the lifetime of the device, as they probably still needs a working battery to boot.

Over the years, none of the Replicant contributors have been able to find the time to add support for this chip,and at the time of writing this chip is still not supported by Replicant despite being relatively easy to add support for it compared with the Broadcom GPS chips that are present in the other supported devices.

Over time, contributions from other people and projects made it easier to add support for the GSD4t chip.

There is now some documentation of that protocol in the form of some Perl source that can probably decode the protocol, and there has also been some people doing research on it.

In addition it’s also easier to do some tests on GNU/Linux: there is now some support in upstream Linux for the Galaxy SII (GT-I9100) thanks to the postmarketOS contributor(s) who worked on that. The nonfree bootloader of the Galaxy SII (GT-I9100) might requires some patches on top of that, but we also maintain patches for the Galaxy SIII (GT-I9300 and GT-I9305) bootloaders in our kernel_replicant_linux repository that might also work on the Galaxy SII (GT-I9100).

The Replicant developers are mostly available on the Replicant mailing and on IRC (#replicant on the hackint, libera.chat and OFTC networks). See the CommunityAndContacts wiki page for more details.

As for how to integrate the work, we already have an example of GPS library that was used in Replicant 4.2 for the GTA04.

As postmarketOS is also interested in making this chip work with free software, it might be a good strategy to also consult them to see how that work could also benefit GNU/Linux distributions.

edit1: removed duplicated title.

License: CC-BY-SA 3.0 Unported

Edit1: Added forgotten link for rooting devices

Edit 2: Fixed wrong link location for rooting devices

Edit 3: Added Epilogue

In the summer 2019, in the Replicant contributors conference in Paris, the people present were all in favor of not supporting devices with battery that can’t easily be replaced, because it would make the use and development of Replicant for these devices too complicated.

In subsequent conference like the FOSDEM 2020, and in discussions with other Replicant users and/or contributors, people didn’t have objections to the decision.

Even if we don’t want to support such devices in Replicant, we are still open to collaborate with people wanting to add support for such devices in other projects. For instance we still support the Galaxy S and the Nexus S in libsamsung-ipc while the devices are not supported anymore in Replicant, and we also do accept patches for devices we don’t want to support in Repliant.

So in practice, some tablets like the Galaxy Tab 2 have battery that are not removable in the usual sense as you cannot remove the battery, without any tools, while walking, but the battery can still be replaced with the help of basic tools like tweezers and screwdrivers. In addition people don’t necessarily expect tablets to last one full day. So we still intend to support such devices.

However some smartphones, which are typically used during a full day without necessarily having the ability to recharge, cannot be opened with regular tools. For such smartphones you need a heat gun, and using that also damage the device along
the way. When the battery is glued with very strong glue, it makes it even more complicated and even more dangerous to change the battery as you need to use very dangerous chemicals to remove the glue. So we decided to not support devices like that.

Given the impact of the decision (most newer phones don’t have non removable batteries), even if that decision seem sound in theory, we also wanted to test it in practice, to be really sure it was the right decision.

To do that we decided to do a very quick experiment and see what would happen when adding support for a smartphone that has a non replaceable battery.

We also wanted to measure how much time was needed to add support for a device as fast as possible, because if we supported devices without a replaceable battery, we would need to rush to add support for the device while it’s still being sold new in order to maximize the lifetime of the device under Replicant. Otherwise, people would need to buy the device second hand, where the battery would potentially not last a full day anymore.

Choosing a device

We didn’t want to spend too much time on that experiment, so we didn’t do much research and choose the first phone that would match what we were looking for.

We wanted the most recent device device with:

• A non replaceable battery
• An Exynos system on a chip
• Android 6
• A stylus and a big display
• A lot of RAM

The device also had to be very similar to the ones we already support to spend the least amount of time possible on that experiment, so we also wanted the device to be made by Samsung, and to have a similar bootloader that is compatible with Heimdall.

So we choose a Samsung SM-N930F which meets all the requirements above. It also has an Exynos 8890, 4GiB of RAM, a stylus and runs Android 6. We wanted to have a stylus and a lot of RAM because as we didn’t really intend to add official support for it in Replicant, we still wanted the work to also be potentially useful for GNU/Linux distributions that might be interested in supporting this device or similar devices:

• The amount of RAM and the stylus makes it more easy to run GNU/Linux
  on the device:
  • As the stylus is more precise than big fingers, you can more easily use software that is less well adapted to the very small display, the very high pixel density, and big fingers.
  • Having 4GB of RAM should be good enough to run many common applications and desktops. It also means that the phone could be supported for a longer time if there weren’t other factors like the non-removable battery that would prevent that.

As for Replicant, the software support for this device is very similar to the Galaxy S7 which is supported by LineageOS.

Unfortunately, the device we chose has shared memory between the modem and the system on a chip[1] but as this was just for a quick experiment and that we didn’t intend to add support for it in libsamsung-ipc, we just ignored that issue in order to spend the last amount of time possible.

References:

[1]https://github.com/RegaliaEzz/Hexa-N930F/blob/master/arch/arm64/configs/exynos8890-gracelte_defconfig

Getting the device

The first problem we had was finding the device. We started looking locally, including in second hand websites, but we didn’t manage to find any. So after that we started looking in international second hand websites, and we found one.

The strange thing is that, while the device is very hard to find, there were many many offers for accessories for that device. At this stage we suspected that this was somewhat related to the non-replaceable battery, though some Galaxy S7 could still be found.

However for some reasons, even if the device was shipped, as we have proof that it was sent to the post office, we didn’t receive it. We are still investigating why, but we didn’t manage to get a conclusive answer yet from the shipping company as we were redirected from service to service and no one seem to know why the device didn’t reach its destination. The issue is also unrelated to COVID-19 as it was shipped by the person many months before it was declared a pandemic.

So we started again to look for a device and finally found a second device. The offer was really strange. It tell that they disguised the device to look like another one to make shipping work.

This didn’t surprise us, as some customs are already actively fighting against the right to repair devices[1]. So at the time we though it was because they decided to fight against the second hand market as well.

In that offer, the person giving the device away also had a strange request: she would not charge for the phone but she wanted us to get the data out of the phone. The person explained to us that she didn’t trust nor Google nor Samsung with her data, which included private pictures but didn’t manage to get her data out of the device. As the request seemed legitimate we agreed to try but as we are not expert in rooting that it might have failed. The data was not encrypted so it also would have made things easier.

References:

[1]https://boingboing.net/2018/10/20/louis-rossman.html

Working on the device

Working with that device was not easy. The first issue we got was that the battery would not charge at all, and the battery indication was at 0%.

This explained why the person wasn’t able to extract her data from the device.

We found on XDA that it was possible to get the battery charge again if we managed to downgrade the phone OS. This looked very strange. We also learned that the phone was fusing the OS versions somewhere. This was probably in the RPMB (Replay Protected Memory Block) partition of the eMMC.

As the device was on fuse version 1, we managed to downgrade it. All that was very strange. The 0% battery charging problem seemed to be a well known issue that is supposed to only affect the the devices fused with the version 2. Maybe it was because the battery was already very discharged that it did that, and that the bootloader and OS refused to charge it.

As we didn’t have a lot of time to spent on all that, we didn’t want to investigate more and proceeded to download OS images for older versions of the devices. We are also not sure if this was legal or not as the images weren’t hosted by Samsung, and so we don’t know
if the website we downloaded them from had some arrangement with Samsung or not.

As official repair shops need to have the images, we assumed that there might be a way for websites to get the images through legal means, especially in countries that have laws that are meant to guarantee the right to repair in practice.

Extracting the data

Before downgrading the images we still wanted to try to extract the data for the person that sent us the device. So as we were unsure if installing a recovery would erase the user data, we tried to find free software root exploits for the device.

We have summarized our attempts in the RootingDevices[1] page of the Replicant wiki. We still need to update it to add information about our attempts with the SM-N930F.

As we didn’t find any rooting application in F-Droid, and that we didn’t want to use nonfree applications to root the device, we instead started looking at vulnerabilities that enabled us to get root. For each vulnerability we looked if the kernel version of the device was affected, and if so we looked for free software versions of the exploits, that were often published without any license.

At the end we failed to find something that worked quickly so we resorted to just flashing a recovery and hoping that it would not erase the user data. According to the find command, the user files seemed to have been intact.

We then sent the ex-owner all the data, strongly encrypted with GPG, and when we got the confirmation that everything was fine we proceeded to erase all the data.

References:

[1]https://redmine.replicant.us/projects/replicant/wiki/RootingDevices

Working on Replicant

At this point, we found that the battery was just very old, this is why it was reporting a 0% capacity.

Each time we wanted to flash an image with Heimdall, we had to wait for hours for the device to charge a tiny bit.

The stress of the developer working on the device increased a lot because the device was potentially always on, and we didn’t know when it had the ability to record conversations or not, as we didn’t do a review of its freedom, privacy and security issues.

The developer’s passwords could be revealed as well, by recording the noise of his keyboard, and even GPG keys can be reconstructed through noise if they are used intensively.

In order to preserve the developer’s sanity and the security of the Replicant project, the device was kept in the fridge most of the time.

This was very weird for the people visiting that developer as he had to put the device in the fridge each time people came by.

Sometimes he forgot to put the device in the fridge and started to have political and/or intimate conversation and at some point he remembered the device and had to go put it in the fridge in the middle of the conversations. That was very weird. Especially the “Can you wait a second? I’ve to put the phone in the fridge.” part.

In addition to all these issues, we also had the device crash during development, however we couldn’t wait until the battery was fully depleted as the battery didn’t charge. We had to hope that the device wound not go in some mode where we were stuck. However it didn’t happen, and we always managed to recover.

Then one day, around when the COVID-19 confinement started, when he was away doing some sports outside, the neighbors heard an explosion. Apparently, besides the table where it was charging and and the wall around it, nothing was damaged.

As some of the neighbors called the police, that developer was then arrested and all his equipment was seized.

He was charged with:

• the possession of an explosive device
• reverse engineering
• theft
• counterfeiting
• violation of trade secrets
• refusing to give encryption key of his hard disks
• refusing to hand over his account details
• refusing to give his fingerprint and his DNA
• resisting arrest and insulting police officers
• destroying evidence

He plead innocent for all of the charges, and most of the charges were dismissed:

• The “explosive device” was in fact the Samsung SM-N930F, which is best known as Galaxy Note 7. As many other people also had one at some point, the court dismissed that charge, especially because this wasn’t done on purpose. The judge also said that they couldn’t condemn people for being stupid, not remembering about the issue, and relying on the outdated offline version of Wikipedia through Kiwix to do research on hardware.
• The reverse engineering charges were also dismissed as it was done for interoperability, and that the developer never agreed to any user license agreement that prevented that.
• Theft was quickly dismissed as it did not apply to the violation of copyright.
• The violation of trade secrets was also dismissed, even if printed schematics were found on the developer’s table. As the schematics were published online in many forums like XDA, they were also considered as fair use. Various leaked documents like the Snowden documents, or Wikileaks revelations were also used during the case to prove that some leaked documents could be considered as fair use. The fact that the documents had “proprietary” markings was also not sufficient as many public documents also still bear markings that were just not removed.
• Counterfeiting was also dismissed because no proof of violation of copyright could ever be found, and that the use of leaked schematics was considered as fair use.
• Refusing to give encryption key of his hard disks: with a lot of pressure from many associations, this was dismissed as it was merely an excuse to get access to the developer’s data and it was not relevant to the case. The same applied with his refusal of handling any of this account data (which also includes the passwords giving access to the Replicant infrastructure).
• Destroying evidence by erasing the data of most of his computers was also dismissed. First only the boot partitions were erased and it was again not relevant to the case.
• Resisting arrest and insulting police officers: there were no proofs that this ever occurred, and rambling against non-removable battery was not deemed strong enough to constitute resisting arrest and/or insulting police officers.

Sentences

However he was still charged with the following:

• Refusing to give his fingerprints.
• Refusing to give his DNA: the police still got his DNA even if he refused.

Subpoena and other declarations:

• The court also gave him a subpoena “Be more careful next time and work on more constructive things like adding support for phones with a removable battery only.” to which the developer agreed.
• He also declared that rushing to add support for a phone wasn’t a good idea either, as because of that, he didn’t realize that the device was a Galaxy Note 7.

He got a suspended sentence of 3 months for all that.

Getting the equipment back

As the court was very friendly he also got all his equipment back which usually never happens. Getting it back was still very challenging but it also turned out to be very fun.

As the developer had to sign a document with all the hardware on it, to get it back, the following conversations occurred when filling the list of hardware:

• Employee: What’s this thing?
• Developer: It’s a UART adapter for smartphone, you know behind the USB connector there is [very long technical explanations].
• Employee: Let’s write “UART adapter for smartphone”.
• Developer: It also probably works on tablets you know, and it can also do many other things other than UART, like power on the phone and switch modes [very long technical explanations].
• Employee: Let’s write “complicated computer hardware”.

Or:

• Employee: What’s this thing?
• Developer: It’s a hardware to trace the protocol between the SIM card and the phone modem, there is a standard called terminal profile which has many privacy implications like [very long explanations].
• Employee: Let’s write “SIM card tracker”.
• Developer: It can’t track SIM cards at all, but it can trace the protocol [very long explanation again].
• Employee: Sigh, let’s write “complicated computer hardware” again.

Or:

• Employee: What’s this laptop? It’s a laptop, right?
• Developer: It’s a Thinkpad X200, which is a computer capable of running Libreboot, this has many freedom implications like [very long explanations].
• Employee: Let’s write “vintage computer”.
• Developer: But I use that computer you know [very long explanations].
• Employee: Sigh, let’s write “complicated computer hardware” again.

Or:

• Employee: What’s that? Is it a very complicated smartphone?
• Developer: It’s just a usual Galaxy S II (GT-I9100G).
• Employee: Let’s write “Galaxy S II”.
• Developer: I’ve also a Galaxy S II (GT-I9100) which has a very different system on a chip [very long explanations].
• Employee: Sigh, let’s write “complicated computer hardware” again.

Or even:

• Employee: What’s that?
• Developer: I don’t know
• Employee: You don’t know? Is it yours?
• Developer: Yes, but I don’t know how to describe what it is, you can think of it like an Arduino running GNU/Linux, back in the days before any of the single board computer had systems to automatically detect hardware [very long explanations].
• Employee: What’s an Arduino [interrupting the developer]?
• Developer: [very long explanations starting].
• Employee: Sorry [interrupting the developer], bad idea, forget about my question, let’s again write “complicated computer hardware”.

At the end the developer got it all back, and the staff said it was the strangest set of seized equipment they ever seen.

He then was unavailable during a full week, as he was reflashing all the “complicated computer hardware” for security reasons. That meant that in practice he had to reinstall Libreboot[1] or other fully free versions of Coreboot that he used, Parabola[2] on all the desktops, laptops, servers, single board computers and smartphones that weren’t fully encrypted, reinstalling Replicant on some other smartphones and tablets, reinstalling LibreCMC[3] on various devices like WiFi access points, reinstalling various microcontroller projects like frser-duino[4] on his flasher, ralim/ts100[5] on his soldering iron, PedRom[6] on his calculator, Simrtace 1.0[6] on his SIM card tracer 1.0[7], etc

At least he could still trust his hardware and continue to use it after reinstalling everything. If the hardware had to run nonfree software, it would have been a different story.

Besides about 1 month of Apache logs, and the phone number of his contacts,
not much was exposed. We also hope that Android “Factory erase” worked fine on the SM-N930F but we can’t know as we didn’t try to recover any data.

The only device he didn’t got back was the Samsung SM-N930F, as it was probably kept or disposed by the Justice Department.

About the lost of the device, the developer commented: “I lost weeks [of work] because of that shitty phone”, “I don’t want that phone anywhere near me.”.

It turned out that, in addition to his allergy to nonfree software, freedom and privacy violations, that developer now became allergic to non-replaceable batteries as well. “Deciding to make devices with non-repleacable batteries is completely insane, it would be very important to ask ourselves how we got there.” that developer commented.

References:

[1]https://libreboot.org
[2]https://parabola.nu/
[3]https://librecmc.org/
[4]https://github.com/urjaman/frser-duino
[5]https://github.com/Ralim/ts100
[6]https://git.osmocom.org/simtrace/
[7]https://osmocom.org/projects/simtrace/wiki/SIMtrace

Epilogue

This blog post is a fictional political satire written by a Replicant developer for the first of April 2020. It may or may not represent the positions of the Replicant project. The story has been very strongly inspired by several real events.

• It contains several logic flaws that might have been spotted by attentive readers or people used to the zététique techniques. For instance the device was chosen to enable sharing work with GNU/Linux, yet, support for Replicant 6 is added in a way that doesn’t benefit at all code sharing with GNU/Linux at all as no support for that device is added in libsamsung-ipc. The fact that it was not clearly marked as a fiction was intended to help people test their critical thinking.
• It’s meant to criticize the systemic causes that resulted in the issue with the Samsung Galaxy Note 7 smartphone. The Wikipedia article on the Samsung Galaxy Note 7 has very interesting information on the impacts of the issue.
• It’s interesting to see how Samsung used the control it had on such devices, to remotely disable them. That control could be abused. This could also be an issue if people have important private data in it, that they weren’t willing to share with companies with huge track record of users abuse. So instead of having to adapt to every design choice of the smartphone industry, like non-replaceable battery, it’s sometimes better to start from limiting as much as possible the damage to users freedom and the environment, and try to adapt that to various uses cases instead. Here, having user removable batteries would be way more efficient than control over users devices for avoiding such issues or dealing with batteries that explodes or catch fire. Many manufacturers had to recall batteries over the years, and the impact weren’t as bad as with the Galaxy Note 7.
• As far as we know, that event didn’t make smartphone manufacturers switch back to user removable batteries. Samsung didn’t even add back non-removable batteries to the Galaxy Note 8 , which is the next model in the Galaxy Note series. If software or hardware that was threatening some economic or political power was the cause of issues that big, the reaction would most probably have been very different.
• In general, giving too much power to the manufacturers over the users is a very bad idea. For instance in the Volkswagen emissions scandal, if users had more control over their cars, an issue of that scale could have been avoided. In contrast, if users had total control over their cars, more users would probably do various modifications, including polluting more to gain more performance or tune their cars to pollute even less. It would have preserved users freedom and probably have a positive impact than with such scandal. The same reasoning apply to the radio lockdown directive, which Replicant took position against.

Copyrights

• CC-BY-SA 4.0

A Replicant contributors meeting will take place in or near Paris in France the 27 and 28 July 2019.

As we are still looking for a place to host the meeting, we don’t have a definitive address yet.

It will be open to anyone who contributes or wants to contribute to the Replicant project.

The meeting will most likely be in English as not all the Replicant contributors who plan to attend speak French.

More details will be posted on the wiki page dedicated to this event over time.

Last minute information, if any, will also be posted on that wiki page.

The Replicant project has been looking forward to support devices with free software bootloaders. While Replicant is a fully free software Android distribution, many freedom, privacy and security issues are orthogonal to the operating system. The hardware design of each computer (smartphone, tablet, laptop, etc.) people use, and the architecture of the cellular network also have their set of issues. For more information on these issues, the Replicant project has some documentation on the topic.

So far all the devices that are (or have been) supported by Replicant use a nonfree boot software (the bootloader). These devices also use hardware restrictions to deny users the freedom to replace them completely with free software, effectively forcing them to run nonfree software. This is a very serious freedom issue that prevents users from being in control of their devices.

There were several attempts to add support for devices with free software bootloaders in Replicant:

• The LG Optimus black: this smartphone doesn’t prevent users from replacing the bootloader. Paul Kocialkowsky did a lot of work to add support for this device in upstream u-boot (a free software bootloader) and added minimal support for it in the upstream Linux kernel. However support for some of its most important hardware components like the display are still missing in the Linux kernel. This device can probably still be found second hand
• The GTA04 smartphone from Golden Delicious: this smartphone has a free software bootloader which is based on u-boot. The smartphone was designed to run GNU/Linux and has almost complete support in upstream Linux. There were attempts to add support for it in Replicant 6.0, however a lot of time was spent to try to make suspend to RAM work with Android. However older Replicant 4.2 images are available. Several hardware revisions of the GTA04 have been made and shipped to customers and developers over the years. However this has stopped due to manufacturing issues. Another issue is that the revisions before A5 only have 512M of RAM and a high DPI display: This combination makes running Android 9 potentially challenging. Fortunately the A5 revision has 1G of RAM, but not a lot of working units were produced.

There is also some ongoing work to specifically add support for smartphones that are currently supported by Replicant like the Galaxy SIII (i9300), the Galaxy Note 2 (n7100) and their 4G versions (i9305 and n7105). The 4G versions could also be supported by Replicant if the work to support their modem (through QMI-RIL) is resumed.

The Replicant project will receive a mobile device, the NC_1 (formerly called Necuno Mobile) from its manufacturer (Necuno Solutions), which will have a free software bootloader

This device has the size of a smartphone, but doesn’t have a broadband modem: while users will not be able to use a built-in modem for phone calls, SMS or to access the Internet, it is still the best way to be completely sure of avoiding any freedom privacy and security issues related to broadband modems and the cellular network. It will also require less work to add support for this device in Replicant.

Even if it’s possible to disable the modem on some of the mobile devices currently supported by Replicant by not loading the modem’s code, some nonfree software still run on these mobile devices. This includes the bootloader and potentially any other nonfree software that it may load. Because of that we cannot be 100% sure that the modem is completely disabled.

The Necuno Mobile will use an I.MX6 Quad system on a chip (which is a chip that contains the main CPU, the microSD card controller, the GPU, etc.). Its free software support is better than for many other system on a chip: the only functionality of the I.MX6 Quad that requires nonfree software is the video decoding acceleration. The article on single board computers has more details on freedom issues affecting various system on a chip and by extension the single board computers that use such components.

A Replicant developer (Joonas Kylmälä) will receive a Necuno Mobile to work on it.

The Necuno Mobile should have a Linux kernel that is very close to upstream: this is a good opportunity for a new attempt to enable Replicant to use upstream kernels. This has many advantages. One of them is that in the long run, it should decrease the amount of work required to maintain the devices and potentially increase their lifetime.

This should also enable the Replicant project to more easily add support for other devices that can use an upstream kernel, like the GTA04, or devices like the Galaxy SIII (i9300) and the Galaxy Note 2 (n7100) that are starting to have good support in upstream Linux.

It is also very interesting in the long run as we could share some of the work with other smartphones projects like postmarketOS who are also trying to support mobile devices with upstream kernels. It could also enable the Replicant project to more easily support future mobile devices that will have free software bootloaders, as some of them will also use kernels that are meant to run GNU/Linux.

Replicant 6.0 early work and associated efforts: At Replicant, things are moving again: Replicant is being updated from Android 4.2 to Android 6.0 by Wolfgang Wiedmeyer. The status and feedback takes place in the forums before it is reviewed and integrated in the official Replicant repositories. This work is currently being done for the Galaxy S 3 (I9300).

At the same time, Wolfgang Wiedmeyer is also working on the following for Replicant 6.0:

• Graphics acceleration with mesa and llvmpipe: while this still uses the CPU, it should be faster and more feature-complete than the default implementation. This will hopefully fix some of the previously non-working applications in F-Droid.
• Building the toolchains: Replicant has always used some pre-built toolchains and utilities. Building such tools and/or using the ones from GNU/Linux distributions will make Replicant more trustworthy.

Replicant 6.0 should also bring full device encryption and SELinux support.

Future directions: In the future we also want to be able to support the upstream Linux kernel for devices with a minimal amount of effort. This was made possible thanks to:

• Android becoming more standard: it now requires very few changes to the upstream Linux to work. Linux also received changes that made it possible.
• The fact that the amount of work required to mainline a device in Linux has drastically been reduced, for some of the devices we target.

Devices such as the GTA04 and the Optimus Black are good targets for upstream Linux kernel support. They also allow running free bootloaders.

In a similar fashion, we also want to be able to support upstream bootloaders, such as U-Boot.

We hope that this will allow us to have longer term support for such devices. Even if Replicant is unable to continue to support such devices in the future, having them supported by upstream software will potentially enable users to use them with other free software distributions.

We have thus started the work to support devices such as the Optimus Black and the Kindle Fire (first generation) in upstream Linux and U-Boot. Other projects and individuals are also very actively adding support for other devices, such as Allwinner tablets, that will benefit Replicant eventually.

Helping Replicant by contributing to F-Droid: Replicant is supported, recommended by the FSF and listed as a fully free software distribution that respects the GNU Free System Distribution Guidelines, along with other GNU/Linux distributions such as Trisquel or Parabola. Replicant
ships the F-Droid package manager in its images.

F-droid is committed to distributing only free software, and it does. However some of it does not comply with the GNU Free System Distribution Guidelines.

Practically speaking some of the applications F-Droid distributes:

• Promote non-free software
• Depends on non-free software

While the list of such anti-features is displayed in red when selecting an application in F-Droid, applications with anti-features are still listed aside compliant ones. This is also quite confusing since free software isn’t expected to contain
such anti-features in the first place.

It took Replicant a long time to realize the issue, this is due
to its developers being very busy, to the fact that the anti-feature
display is confusing and that there was no clear smoking gun.

After an investigation, that was delayed due to the lack of time, a
smoking gun was finally found, and a bug report was opened on the Replicant side.

At FOSDEM 2016, the issue was discussed with F-Droid developers in order to find a way to fix it. On their side, F-Droid developers also opened a bug report. Due to various reasons, progress was very slow and we recently learned that efforts to fix this issue came to a stall.

Replicant developers are more dedicated and used to working on system programming than writing or modifying Android applications. They are also really busy doing so. However, some individuals wanting to help Replicant may be able to work on Android applications, with some time to do so. This is exactly the kind of skills required to solve this issue in F-Droid. Getting it fixed is crucially important for Replicant.

If you’re interested to jump-in and help resolve this issue, please get in touch with us or with F-Droid developers directly to get directions on how to get started.

We found out that on the Nexus S and the Galaxy S the modem could possibly spy the main CPU(where Replicant runs).
We are currently trying to see if that can be fixed(by loosing about 80M of ram) or not.

More details are available on our wiki