Hi,
I’m a bit at a loss here, I don’t know what the question is…
The concept behind my modifications to the stock recovery:
deactivate zip file verification (in install.cpp in recovery)
at least SuperSu in its install script mounts partition,so it needs an fstab, and does not look for recovery.fstab. I work around this by making a link from recovery.fstab to fstab (in the Makefile)
As the install skript is a shell skript, we need an sh interpreter in the recovery. I had a compiled busybox left over from some tests with TWRP. I saved the executables and libraries and made the rcbins.tar. This has to be untarred at some place (preferably $HOME) and will also be copied to the sbin from the recovery
as the busybox binaries from TWRP are dynamically compiled, the system needs to know where the libraries are. This is done by the modification to init.rc after “on init”
edit: just checked the wiki. As vivia specifies a location for rcbins.tar and delivers the Makefile, follow the wiki post and leave my remarks here as a general explanation to know whats happening
The question from @vivia was if it is okay to share the recovery.img, or if it does contain bin blobs code. The Makefile is so big … and stuff gets copied around so it’s hard to tell without a clean (non-bin-blob) build. So the question is: Does the recovery contain any bin blob code?
Looks like I managed to compile the source now (on Gentoo btw). The “API was modified” errors are gone, didn’t do anything different than last time, just started from scratch.
Before I flash the system.img here’s one question:
I downloaded the original OTA-images (“FP2-gms36-1.1.7-ota.zip”) has a “system.new.dat” instead of the “system.img”. Can I use fastboot to flash the “system.new.dat” to restore the original ROM?
Oh wait, let me guess: you boot recovery and use adb sideload with the “FP2-gms36-1.1.7-ota.zip” (without unzipping it on the PC). Right?
Ah, I see. I do thinks that there are at least fragments from the blobs, as @Arvil also stated, there are files with qcom in it. As I do have a very slow system for compiling at the moment (have to switch to docker…) it’s not that easy to set up everything without blobs and issue a make recoveryimage to see whether it compiles or not. But I doubt it…
java -version && gcc --version:
java version "1.7.0_91"
OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-1~deb8u1)
OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
gcc (Debian 4.8.4-1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Good, that was the idea! But … as a stronger workaround you could also just use docker with the dockerfile, if everything else fails!
It works pretty well. You can just recycle your current working directory for that, so there would be no need to checkout all the code again, if you just want to build the image quickly.
Else, nothing comes to mind. Is javac -version the same version? Sometimes on Debian you can end up with different versions due to the alternatives management. Maybe someone else will come along and will be able to help you!
ls -al /etc/alternatives/javac should point to java-7-openjdk-amd64/bin/javac somehow.
First I tried it on my main machines at home which all run ~amd64 (= unstable for all not knowing Gentoo ;)). Since it failed there (not compatible with python 3, possible not compatible with perl 5.22.1) I ran the whole thing on my rented root-server which uses the stable packages. There I had no problems except the mentioned “You have tried to change the API from what has been previously approved” stuff (#180). Finally I switched to gcc 4.8 (though it shouldn’t make a difference since the compilers used are downloaded precompiled on “repo sync”), removed everything and started over. It then worked without a flaw.
The recovery boots and I didn’t yet flash the system.img. Version of make used:
GNU Make 4.1
Built for x86_64-pc-linux-gnu
After flashing the system.img, here’s another issue: The phone tells me that the storage space is running out: http://kripton.kripserver.net/pix/SpaceLow.png
However, “df” on the shell looks good to me:
java and javac are the same version, and [quote=“fp1_wo_sw_updates, post:256, topic:11600”]
ls -al /etc/alternatives/javac
[/quote] seems to be correct, too.
I’ve this problem with my two machines running Debian 8.2.
The update-binary is a shell script. Somewhat long but not that bad. I looked into it to learn why it failed while testing my recovery. Also, there are a few su programs in there, it has to detect the architecture and copy the correct su
just wanted to say thanks for the guide at the top!
Compiling worked for me on a freshly set up Ubuntu 14.04.3. First had problems when repo sync got stuck because of the lousy wifi connection (cabel recommended!) which led to compling errors.
Also “flashall” did not work, said android-info.txt was missing, although it was there. Flashing single images worked fine.
Now I have a google free, rooted fairphone.
My build has some issues with the privacy impact overlay (it was not responding), but that can be deactivated in the settings.
I feel like trying to compile once again following the guide provided thanks to you guys.
Just a little question: Which directories do I need to remove (or perhaps shorter: Which directories do I need to leave?) before starting the new compilation?
Right now, I am syncing repo again even though all corresponds to delta=0 up to now, but just in case updates have been made.
I am not sure if I understood the rooting guide in the wiki, especially if it is only for the official image for now.
Do I first need to do the compilation of the GSM-free FP OSOS and flash it on the phone or can I follow the complete guide - but flash system and recovery etc?
Sorry to bother you with such profane questions, but I am a bit impatient to set up my phone
Well, in the end the guide creating a recovery allows you to root the stock image, and freedom to install a zip via recovery (if you need it on osos) on any image, the guide for the recovery is for you
Is 
)
