Targets Evaluation¶

• Table of contents
• Targets Evaluation
  • • Improving data on devices
    • Other data sources
  • Evaluation criteria for accepting new devices in Replicant
    • Minimal requirements
    • Good target
    • Ideal target
    • Known to be bad targets
  • Devices evaluation
    • Android devices
    • Non-android devices

• It can be used to evaluate potential target devices
• It can be used to denounce very vicious attacks on users freedom, for instance if the kernel is signed.
• It can be used to track if new devices have removable batteries

To track the upstream status of various devices, we also have the Upstream wiki page. Here we really need information on the upstream status of smartphones and tablets, even if the devices are worse than the ones currently supported as it helps plan the future of Replicant. For instance we could use the data to understand how to build virtuous circles with various upstream project that care less about freedom.

That page was previously used to evaluate potential target devices to which we may port Replicant, but the information on the devices Replicant would not want to support turned out to be useful as well.

Also note that adding support for a new device in Replicant takes some time and effort.

Because of that, adding new devices in that page doesn't guarantee at all that the device will be supported in Replicant, even if that device has significantly less freedom issues than the ones currently supported by Replicant, as some people still need to step up and do the work.

• There is also a forum section about devices evaluations.
• The mailing list can also be used to discuss about device evaluations

The developer guide explains the terminology used on this page. See also the website for background information.
The porting guides provide information how the following requirements can be evaluated.

Improving data on devices¶

It might be a good idea to investigate how to use Wikidata to store the data and be able to automatically generate some tables from that.

This could also enable us to share the work with other communities. However the main issue with doing that would be to ensure that the data quality is good enough to our standards.

The inventaire project has exactly the same issues and did a presentation on how they deal with it.

It's also possible to build compatibility tables with sparql querries but much more research needs to be done on how to best interface with wikidata data.

Other data sources¶

• LineageOS generates its wiki compatibility page from yaml data. We can also use the same data to find devices that might be interesting to support in Replicant.
• Wikidata had or has already a community of people involved in adding smartphones in wikidata.
• The gsmarena website also has some information on smartphones.
• Wikipedia has a lot of information on smartphones, including specifications.

Replicant even has a tool:"https://git.replicant.us/replicant/vendor_replicant-scripts/tree/research" to automatize that

Evaluation criteria for accepting new devices in Replicant¶

Minimal requirements¶

• Users must not be required to use download, install or use any nonfree software to install Replicant.
• The bootloader must not prevent users from installing modified kernel versions.
• Replicant will need to be usable on the device without having to redistribute any nonfree software.
• Users or automatic programs are not expected to download and install nonfree software to make the device usable.
• The device also need to have enough resources to run Android. For instance, at the time of writing, it's unrealistic to port devices with 128M of RAM to Replicant.

• The device must have at least one usable Linux kernel with with complete corresponding source code. If this is not the case, it might still be possible to obtain the complete corresponding source code from the device manufacturer, or to port the Linux kernel to the device yourself before starting to work on Replicant.
• Some devices might have CPU architectures not supported by the latest Android version, like MIPS. Replicant may refuse to support such devices due to concern over long term maintenance of the code.
• Replicant doesn't support CDMA yet. If your device has CDMA, adding support for CDMA may or may not be a lot of work depending on the device.

Good target¶

• Bootloader must be ready to flash images, or be very easy to unlock
• Free user-space implementation for most of the hardware already available
• Standard or well-known protocols used in the hardware (V4L2/ALSA/NMEA, etc)
• Proprietary loadable firmwares only needed for Wi-Fi/Bluetooth, and not camera, or other peripherals etc
• Freedom-compliant hardware design: Modem isolation (no shared mem, GPS, audio)
• It should be possible to deactivate the modem, either by hardware or software.
• To make the port easier, and to amount lower the maintenance work it would also be a good idea if the chosen device meets or exceed with some margin the minimum HardwareRequirements of the latest Android version.

Ideal target¶

• Free bootloaders that allow easy flashing for the user
• All the hardware using standard protocols, kernel-drivers and no user-space binary blobs
• Components do not require loadable non-free firmware
• There are ways to update the internal firmwares of the chips (for instance to allow a free software modem implementation)
• Has total modem isolation (doesn't control audio, nor GPS, mem, NAND, etc)
• not SIM locked

Known to be bad targets¶

• Qualcomm MSM/QSD devices are known to have bad hardware design where the modem controls GPS, audio (including mic), RAM, NAND.
  However, some MSM/QSD SoCs don't ship with a modem embedded, so they may be good targets. See the page on Qualcomm System On a Chip for more details on this issue.
• Nvidia Tegra 2 devices are known to be too slow with Replicant, since there is no NEON nor any free hwcomposer/gralloc.
  Perhaps newer Tegra SoCs (which include NEON) would be faster on Replicant.
• Motorola devices manufactured after the Milestone (inclusive). These have non-free locked bootloaders that check kernel signatures. sbf_flash, a utility capable of flashing Motorola devices, is non-free.

Devices evaluation¶

Android devices¶

Non-android devices¶

There are a small number of do-it-yourself phones where the user is expected to assemble the phone. Examples of this include the odroid phones which comes with android support. However, the issue is that not all users want or are able to assemble their own phones.