Profile

Replicant

Replicant 6.0 for the Samsung Galaxy S3

This post contains outdated information and links to outdated images. See the wiki and blog for development updates, up-to-date documentation and current images!See the archived post for documentation about my initial work and findingsSee this post for the Galaxy S2

Changelog of the latest version (replicant-6.0-beta-0001 from 27.1.17)¶

Added support for external WiFi dongles that use the AR9271 chipset Makes it possible to use WiFi with only free software as free firmware exists for the chip

January security updates for the kernel

Changelog of the sixth alpha release (replicant-6.0-alpha-0006 from 6.1.17)¶

Only the most relevant changes are listed.

Fixed sending of longer SMS messages

Fixed entering the SIM lock PIN Previously, if the PIN was entered incorrectly once, every subsequent try failed, even if the PIN was correct.

Reduced the camera preview resolution to speed up the preview a little bit

Moved the build system from Debian Jessie to Debian Stretch and fixed various build errors This allows to use the manifest merger tool and the Eclipse Java compiler from Debian.

Added the possibility to enable llvmpipe as software renderer by making it buildable for ARM See the Tips section below

Applied various performance improvements and fixes for graphics rendering, mostly from the Android-x86 project

Ported various security/privacy enhancements from the CopperheadOS project This includes the possibility to set an encryption password that is different from the lock screen pin/password. The phone will reboot if the PIN was entered incorrectly more than four times. Some privacy enhancements for the browser

llvmpipe has more complete EGL support than the Android software renderer, so more apps work with it, like Firefox-based browser or more recent webviews. Unfortunately, llvmpipe is still too slow to be the default renderer, but I made it possible to switch back and forth between llvmpipe and the Android software renderer. ADB and root over ADB needs to be enabled in the developer settings.

The camera "locks" sometimes or the error "Can't connect to camera" is displayed. Logs might help debugging this, at least the issue with the error message. Recent versions have a fix which allows to take a picture if the camera app seems to be unresponsive and you press the shutter button a second time.

Only the Galaxy S2 and S3 are supported. If you want to help getting other Replicant devices supported: Add the missing device repositories and try to merge the changes from CyanogenMod. If the device is not supported on the CyanogenMod 13.0 branch, you will have to look at forks that took up the development. Merging with an older branch could also be sufficient to get basic functionality working.

Newer webviews can't be used because they don't work with the software rendering Webview version 43.0.2357.134 is currently in use. It was released in July 2015. This can be fixed by making llvmpipe fast enough so it can be used as the default software renderer. Currently, the Android software renderer is the default.

There are still prebuilt binaries in the source tree I got rid of a lot of prebuilt binaries to make the build more trustworthy and to ensure that all tools are properly built from source with free software, but there are still a few left. The gcc-arm-linux-androideabi toolchain needs to be bootstrapped with proper 1st and 2nd stage compilers so it doesn't rely on the sysroot from the NDK. In general, there are still some prebuilt binaries from the NDK, SDK and other places in use, but nearly all of them shouldn't run on the host, but only on the Replicant device.

Please note that the build might even be broken on this branch and there are no git tags on this branch which pin the source code to certain versions.

Then download the source code:

repo sync

The F-Droid binary is downloaded separately. The download script will check if the signature of the F-Droid binary comes from the F-Droid release signing key. You can retrieve the current signing key with the command gpg --recv-key 7A029E54DD5DCE7A. Run the download script to get F-Droid:

./vendor/replicant/get-prebuilts

Before you can build the ROM in the regular way, you need to run a build script that takes care of building the toolchain:

./vendor/replicant/build-toolchain

In order to prevent strange errors, I recommend running the script in a newly opened shell, in which you haven't already run one of the commands like . build/envsetup.sh, lunch or make that change the environment.

Then you can run the regular build commands to create a Replicant 6.0 zip and recovery:

I also added a script that signs your build, takes care of generating the necessary keys and puts everything in the out/dist directory. Using this script, it is possible to rely on your own keys and not on the test keys which are not recommended to use because the private test keys are publicly available. Building from source and flashing the default image that is signed with the test keys basically disables all the security measures in Android that are based on signing keys. The script also makes it possible to use password-encrypted private keys. The images below are signed with my keys using this script. You can run the script the following way:

./vendor/replicant/sign-build i9300

And finally you can flash the recovery in the download mode and sideload the zip in recovery mode:

If you have already built Replicant at some point and now you are getting build errors: Run make clobber and retry in a newly opened shell.If make fails, it may be necessary that run mka org.cyanogenmod.platform-res.

Add my key to your GPG keyringYou can retrieve it from the keyserver of your choice (gpg --recv-key 5816A24C10757FC4).Alternatively, you can download it from here: https://wiedmeyer.de/keys/ww.ascand import it with gpg --armor --import path/to/5816A24C10757FC4.ascThe key should have the following fingerprint: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4

You need to flash the new recovery first before you can flash the zip to your device. A full wipe is also necessary. Updating your ADB installation might help if you have problems with ADB.See the wiki for more details.

Replies (135)

I updated my initial post. There is now a section about the toolchain and build instructions. I merged my changes to the toolchain in the replicant-6.0 branch, so most of the toolchain needs to be build from source from now on. The security patch level should now be the correct one.

I also included links to a compiled zip and recovery if you are not able to build it from source for whatever reason and want to try it nonetheless.

Could you post more/previous output? This basically only shows that make gives up, but the actual error happened somewhere before.My 2 cents about using Arch for building this: Google uses an old and modified Ubuntu LTS release for building Android. Debian Jessie comes pretty close to this setup in terms of configuration and package versions. So I only had to fix very few build errors here and there. Arch however has very new package versions and differs quite a bit. I don't want you to switch to a different distribution for building Android. Indeed, I think it is very important that we make it possible to build Replicant on Arch, because then it is very likely that building it will work on various other distributions. But I just want to let you know that you will likely have more build errors in the future and that it could become quite challenging. I will definitely try to help you with build errors.

I will need logs for fixing the SIM card problem. I tested it with two different SIM cards (albeit same provider) on two devices and they always get recognized. So I don't know what could be the culprit.

Setting->Sound->Other did not yet crash on me but I will look into this at some point.

Encryption should also work. If this does in fact not work, then the logcat from the shutdown after the encryption was enabled and from the following boot needs to be inspected. The last time I checked, encryption did not work on CyanogenMod 13 because they likely forgot to add some SELinux rules.

@Simon: Yes, it uses Replicant's RIL and the proprietary graphics drivers are not used. It is unlikely that there was a different proprietary acceleration module added to the source code and I would not be aware of it. Feel free to check the source! I already went through quite some code and e.g. removed the linking to proprietary play services that CyanogenMod added. I will also watch out for the one-pixel split graphics bug.I won't provide support for running proprietary software on the AP, but if you want to get GPS working, you might start by looking at this commit: https://code.fossencdi.org/device_samsung_i9300.git/commit/?h=replicant-6.0&id=eb564f1803a0145eef68b59cdbb75362175d05a7

robin p: I won't do work on getting a sdk or ndk build ready for now. I don't see a point in doing so for the moment because there are still so many binaries. I think it has be investigated first if the build process for the sdk or ndk just repackages a lot of these binaries. Just to be clear: I see similar problems with the Replicant 4.2 source code. For now I recommend building an app directly from the source code. Just place it somewhere and run mmm path/to/app. The app just needs a Android.mk. It can be simple as this one: https://code.fossencdi.org/BlueGPS.git/tree/Android.mk. You should have run a complete build of the ROM before so that all dependencies are in place or you could try to run mmma path/to/app. Of course, if the app has a lot of dependencies, then it might not work because not all of them are there.

Thanks for update! I'm now trying to reproduce the build using the latest repo. I'm also quite concerned about the number of "prebuilds" needed, so thanks for working on that. Btw, you also need the 'bc' debian package in addition to the replicant wiki debian packages (it was not installed on my minimal debian machine).

Re the one pixel bug: I suspect it is related to the top menu appearing in the wrong place on first boot. I just tried booting your ZIP and it behaves the same as it did for my images: on first boot when I first click on the top right to drag down the menu, the menu appears in the wrong place (1-2cm to the left of where it should be, thus partially hidden). Once canceled, the menu always appears in the right place again. Not very important bug, but just strange. I think I only saw the one-pixel issue directly after first boot before, but cannot recall what I did instead of dragging down the menu.

Re the Setting->Sound->Other bug: it crashes for me using your image too. Just go to Setting->Sound->Other and then press the back button. Boom.

Re the SIM issue: I may have damaged this S3, it now displays "No SIM Card" on every ROM I try. I distinctly recall it asking for a PIN a number of times before. I've tried restoring EFS but no difference. It might be a physical/mechanical problem on this S3. I'll need to buy another S3, or reinstall my hot spare S3...

Btw, you also need the 'bc' debian package in addition to the replicant wiki debian packages (it was not installed on my minimal debian machine).

Thanks, added it to the list.

Re the one pixel bug: I suspect it is related to the top menu appearing in the wrong place on first boot. I just tried booting your ZIP and it behaves the same as it did for my images: on first boot when I first click on the top right to drag down the menu, the menu appears in the wrong place (1-2cm to the left of where it should be, thus partially hidden). Once canceled, the menu always appears in the right place again. Not very important bug, but just strange. I think I only saw the one-pixel issue directly after first boot before, but cannot recall what I did instead of dragging down the menu.

Re the Setting->Sound->Other bug: it crashes for me using your image too. Just go to Setting->Sound->Other and then press the back button. Boom.

I can reproduce both of these issues now. For now I will focus on other issues as I don't see them as that important. They may not be related to the changes I made so hopefully, they get fixed on Cyanogenmod's side.

My TODO list for now (in order of importance):

figure out what the SIM card issue is that some or all? experience

get rid of more prebuilts

get SELinux working

get a newer Webview working

patch not yet fixed security bugs in the kernel

Re the SIM issue: I may have damaged this S3, it now displays "No SIM Card" on every ROM I try. I distinctly recall it asking for a PIN a number of times before. I've tried restoring EFS but no difference. It might be a physical/mechanical problem on this S3. I'll need to buy another S3, or reinstall my hot spare S3...

This is very unfortunate. Are you sure that it's the phone and not the SIM card? Does the SIM card work in a different phone?

I ran ./vendor/replicant/build-toolchain and it completed without errors, still I get a build error during 'make bacon' that seems toolchain-related.

[...]

That directory contains almost everything except gcc...

I may have run into this yesterday, too. I suspect the reason is that some of the environment variables, that envsetup, lunch or make set, conflict with the build script for the toolchain. Could you try these steps:

1) to migrated the RIL/IPC stack was it enough to edit samsung-ril and libsamsung-ipc or are there some other modifications in other repos ? While waiting for a stable 4.4 or 6.0 version for my I9500 i would like already to migrated the RIL stack to open source instead od the proprietary one while staying on cyanogenmod.

2) Except the I9500 mentionned above are there other devices that are replicant 6.0 RIL compatibles, will this work allow some more target phones to ber compatible or the RIL will not be compatible with recent exynos soc ?

I can reproduce both of these issues now. For now I will focus on other issues as I don't see them as that important. They may not be related to the changes I made so hopefully, they get fixed on Cyanogenmod's side.

My TODO list for now (in order of importance):

figure out what the SIM card issue is that some or all? experience

get rid of more prebuilts

get SELinux working

get a newer Webview working

patch not yet fixed security bugs in the kernel

That's a good priority order! The graphic bug is not important.

Re prebuilts, some should be easy to get rid of, like ccache, flex, bison -- not sure it is even worth rebuilding them, you could just rely on vendor OS tools unless Android has patches.

Re the SIM issue: I may have damaged this S3, it now displays "No SIM Card" on every ROM I try. I distinctly recall it asking for a PIN a number of times before. I've tried restoring EFS but no difference. It might be a physical/mechanical problem on this S3. I'll need to buy another S3, or reinstall my hot spare S3...

This is very unfortunate. Are you sure that it's the phone and not the SIM card? Does the SIM card work in a different phone?

The SIM works. I found a used S3 so I will try more when it is delivered...

I may have run into this yesterday, too. I suspect the reason is that some of the environment variables, that envsetup, lunch or make set, conflict with the build script for the toolchain. Could you try these steps:

rerun the toolchain build script in a newly opened shell without running any of the other commands like . build/envsetup.sh, lunch, make or others that modify the environment

check if the gcc binary is now there in toolchain/gcc/arm/arm-linux-androideabi/install/bin/

I can confirm that this works.

Btw, it would be nice to get reproducible builds of Replicant... the reproducible-builds.org team has good resources here. The first step would be to set up a build server to feed the outputs into diff'ing tools.

Update: The described workaround should not be necessary anymore. See later comments or the updated post.

Regarding the SIM card issue:

If the SIM needs to be unlocked on boot, then it does in fact not work. The SIM cards, that I always tested before, had the SIM lock removed. I tested it today with a locked one and it shows the behavior that sebastian k and My Self described (no SIM card recognized and no pin unlock request). It's likely that the Samsung-RIL will need another update to make this work.

As a workaround for now, you will need to remove the lock. With a different ROM, go to security->"set up SIM card lock" in the settings and disable the lock. Then the SIM card should work.

Funny enough, setting the lock actually works, but this is of no use if the unlocking doesn't work.

To be honest, I really freaked out about this news! @Wolfgang: Thanks a lot for saving me from some (more) sleepless nights about Replicant's security situation.I bought an used I9300 as fast as I could and since this has arrived, I tried to figure out some basics:

This is really nice to hear :)The security situation still needs some work, though. I will be able to get SELinux working in the next weeks. Besides that, the main problem is the outdated kernel. At least, all the kernel vulnerabilities of the last two years have to be checked if they are already fixed. Additionally, the drivers and other parts, that are not maintained in the upstream kernel, have to be investigated. I am also not fully convinced that Google is fixing everything in their AOSP code, especially in external. And as I detailed already in my post, the webview is also an issue.

These patches are also already included in the sources. All the security patches from the February issue should be included now, too. They were already included in changes I merged from CyanogenMod.

I realized there is a basic root "management" by setting:Settings -> Developer options -> Root access -> from Disablet to: Apps onlyBut I wanted more or less the same root management as I knew it from Replicant 4.2, because I love the benefits like PIN protection or the clearly arranged logging overview.So I did the following:

It is really awesome that Pierre-Hugues Husson maintains Superuser and made it compatible with recent Android versions. It is obvious that Superuser is more feature complete but I am skeptical if it's worth the effort to integrate it in the source build. Regarding the PIN protection: Does it really have a security benefit? If the phone is unlocked, would it be possible to remove the protection by deleting app data of the Superuser? Also, does it prevent to enable root over adb? So the question is basically whether it really makes evil maid attacks harder. Access to all you data is probably already there (https://xkcd.com/1200/)Having logging of root accesses is definitely a benefit!

You could already test if the integration of Superuser as a module works. Just place the Superuser and Widgets repos somewhere in the source dir (e.g. in external/Superuser). You probably will need to remove the existing su module by deleting the system/extras/su dir because otherwise the modules will conflict. Then adding Superuser to PRODUCT_PACKAGES e.g. in vendor/replicant/config/common_full.mk should be enough. This should build Superuser as an additionally dependency automatically when you start the next build.

Furthermore I let the app 'LiveWallpapersPicker' exist, but removed the following system apps (mostly EGL needing- and so crashing live wallpapers) instead:

1) to migrated the RIL/IPC stack was it enough to edit samsung-ril and libsamsung-ipc or are there some other modifications in other repos ? While waiting for a stable 4.4 or 6.0 version for my I9500 i would like already to migrated the RIL stack to open source instead od the proprietary one while staying on cyanogenmod.

I only had to fix build errors in libsamsung-ipc and only needed to deal with the code to investigate some initial problems but I did not need to implement anything in there. To my knowledge the code is already more or less complete for the currently supported devices. If you want to add support for a new device, then you will probably have to do quite some work in there. Paul or others who actually worked on that code will be able to answer questions regarding this.Samsung-RIL is device-independent and the actual project that needs to be updated to be compliant with a new Android version. There is still some work to be done, but these changes will affect all devices.Then you need to do changes to the device sources. You can check the differences between the respective repositories (e.g. for the i9300) at CyanogenMod and Replicant to get an idea of what needs to be done.

2) Except the I9500 mentionned above are there other devices that are replicant 6.0 RIL compatibles, will this work allow some more target phones to ber compatible or the RIL will not be compatible with recent exynos soc ?

AFAIK it should be possible as long as support can be added to libsamsung-ipc, but I'm not sure.

Sync errors like the one you were having shouldn't be an issue for quite some time now. It should work if you sync again, but you will probably have to remove the affected repositories from the .repo/project-objects/ directory.

Re prebuilts, some should be easy to get rid of, like ccache, flex, bison -- not sure it is even worth rebuilding them, you could just rely on vendor OS tools unless Android has patches.

That's what I did. Only ccache is not yet replaced. If there is demand for it to be working, then I'll look into it. Should be easy as long as the Debian version is compatible.

Btw, it would be nice to get reproducible builds of Replicant... the reproducible-builds.org team has good resources here. The first step would be to set up a build server to feed the outputs into diff'ing tools.

It would be awesome, indeed. Especially if it would be built with an OS that is reproducible in itself, like Debian Stretch will hopefully be. But I think that it does not make much sense if the compiled image contains binaries or if the build relies on binaries in the source tree, which are not reproducible. So getting rid of prebuilt binaries that are not verifiable or not yet verified is the first step in my eyes.

Your build failure should be gone now. You could also run make clobber before rebuilding and after syncing, just to make sure.

Thanks for working on this! Your documentation already helped me quite a bit. Feel free to try it out, but only building an image for the i9300 will work for now! Building the sdk will likely fail because of missing dependencies.

Nearly all the build errors that where reported in this thread are due to the constantly changing source code. The version I was working on was not the same others were testing at a later point because they already pulled in new changes from CyanogenMod when they synced. The problem is that CyanogenMod does not use tags for their repos so there is no sane default way of freezing the code at a certain version. I solved this problem now by mirroring the CyanogenMod repos on my server and tagging versions that I tested and believe to be working. So everyone gets now the same version when syncing on the replicant-6.0 branch. And this way, it's also possible to have the same version I used to compile the images that I offer for testing (see my updated post).I am planning to update the mirror at least monthly so that the latest security fixes get pulled in. I will probably do the intial work and testing on a separate branch (replicant-6.0-dev) and then tag everything when I think that it works fine. After that, I will update the replicant-6.0 branch with the new tag and everyone gets the new version.The current version is already tagged on the replicant-6.0 branch, so it should just build fine if you try it. But it can still break on a different distro than Debian Jessie.

Locked SIM cards should now also work. The issue with the pull down menu after boot and the crash of the "other sound" menu should be gone, too.

I also updated various areas of my post, including the build instructions and the image section.

What's coming for the next version: I got SELinux working in enforcing mode (also in the recovery), but I need to to do a bit more testing. The issue with the wifi dropouts seems to be gone, but I need to investigate this a bit more. I also currently redo the kernel branch so we have a version without my experimental changes.

SELinux is now running in enforcing mode. The Wifi dropout bug is gone and the Wifi is stable.

Signing the builds with the script works also great so far.

The recovery checks the signature of the install zip and refuses to install it if it has not the signature stored in the recovery. CyanogenMod added another check that also compares the signature to one stored on the current data partition. If they don't match, it also won't install anything, unless you do a factory reset. This check does not happen if the data partition is encrypted because the recovery does not yet decrypt it. It would be helpful if the recovery would be able to decrypt the data partition and could do the check. Currently, the phone just becomes unresponsive after decrypting the data partition if there are different signatures present. And you would have to figure out for yourself that a factory reset is necessary.

The Wolf had linked a tutorial of how to unpack the CM13 to install non-free software, but decided to remove for some reason. Then, I think it's a little inappropriate to discuss technical details of non-free software here in this forum. It's just my opinion.

The Wolf had linked a tutorial of how to unpack the CM13 to install non-free software, but decided to remove for some reason. Then, I think it's a little inappropriate to discuss technical details of non-free software here in this forum. It's just my opinion.

Pity. I'll see if I can find something.True about the non-free software here...

The Wolf had linked a tutorial of how to unpack the CM13 to install non-free software, but decided to remove for some reason. Then, I think it's a little inappropriate to discuss technical details of non-free software here in this forum. It's just my opinion.

If anyone has details on this. Can you drop me some info @ divan<a>santanas.co.za ? Pretty please. ;)