You can change it yourself if you want to add more info. I think they need to fix the build. We can’t fix all those things after the fact, the list will get too long. Not sure if “choosecombo” will affect the signing, I think it’s mostly the make files in core, but I’m not sure.
Just wanted to share my experience here:
I followed the steps as described in the wiki post (on Ubuntu 14.04 LTS), except that I downloaded the whole repo (missed the --depth=1) and added the patches for unified NLP. I had to add -w when flashing system.img as otherwise the phone would hang during boot at the white “Loading” screen (It got quite warm too and battery was very low after 15 minutes or so).
So far it seems to work perfectly (even the LED issue is fixed), although I haven’t tested much yet. One thing I noticed was the “introduction” to the UI (a few screens showing basic usage of the UI) - I didn’t notice that on the stock Fairphone OS.
Thanks to all of you who worked on this guide - it feels incredible to run a self-compiled OS on my FP2
I tried as proposed and got stuck on a problem when trying to embed Superuser (by phhusson) into my build:
Compiler stops because of multiple Android.mk-Files defining su. /system/extras/su comes with FP-buildtree. Websearch (example) gives just to delete the whole folder or renaming the mk-file. However if I try, both run into several different “no rule defined”-errors a little bit later in compile-process.
Since I didn’t managed to find a workaround in accordance to the explanations of koush or phhusson I renamed all Android.mk-files in Superuser-Directory into Android_su.mk. My assumption is, that any mk-file in build-tree will be called, but I am not sure whether this will install Superuser as meant considering the same procedure with the mk-file in system/extras/su didn’t work out aswell in the first place.
If my currently running build fails - any idea how to get rid of this? Thank you in advance.
Are you talking about “building” su or copying it into the right location later on? Is it possible to build superuser as an application and just install it later? I remember reading something about it, but I guess you need its “su” and the application?
Can you write down in pseudo code what you want to do? Maybe someone can figure out where to modify the make files. A quick and dirty way would be to just add it to an existing one.
Build new su_phhusson
cp su_phhusson to system/xbin/su
And yes, make includes every Android.mk file it can find. If the are called differently, not. Or they must be included in the Android.mk before.
# For apps_only build we'll establish the dependency later in build/core/main.mk.
# build/core/Makefile contains extra stuff that we don't want to pollute this
# top-level makefile with. It expects that ALL_DEFAULT_INSTALLED_MODULES
# contains everything that's built during the current make, but it also further
# extends ALL_DEFAULT_INSTALLED_MODULES.
Thank you for your answer. I want Superuser to be a system-app (embedded) in the OS-image.
build new su_binary_phhusson (ok)
copy su-binary_phhusson to system/xbin/su (ok)
make -j4 (not ok) --> system/extras/Android.mk defines su and packages/apps/Superuser/Android.mk defines.su
on rename (or delete) of system/extras/Android.mk:
make -j4 (not ok) --> no-rule-errors, e.g. no rule to make target ‘out/target/product/FP2/obj/SHARED_LIBRARIES/libwpa_client_intermediates/export_includes’
on rename of packages/apps/Superuser/Android.mk:
make -j4 (compiles 1h+)
worry: Superuser (not ok)
So what can I actually do to get rid of this su conflict. I do not see the function of system/extras/su anyway. Why is this called su overall? It doesn’t install su rights but causes errors in other branches when deleted.
As far as I know, the build system looks for any files with the .mk extension and pulls them all into one single, big mk file before building. Therefore, I would not use the mk extension when you attempt to move it out of the way for building.
Thanks, now I have two different opinions on this issue As I mentioned the build continues if the .mk-file of Superuser is renamed. Renaming or deleting the mk-file of the FP-build-tree will lead to early errors on includes. However I would like to be sure that .mk-files of any names are integrated properly. Or even better, to learn about how to work around such things. I mean this kind of problem should be common. Is there no possibility to “tell” the system-.mk-file to call the Superuser-.mk-file aswell?
Well, it will call just any mk file it can find. Did you clean the build completely and re-ran the environment.sh script (or what it’s called) after applying the changes?
The more clean way to do it would be to clone the repository where you want to do the changes, do the changes, commit and then replace this repository by your local copy in the manifest and re-run repo sync. But I guess for what you are trying the dirty way should be sufficient.
Wow, I didn’t know they had a public gerrit instance! Maybe it’s worth just cherry-picking all the commits related to supersu? They are supposed to include it in the build process if I read the commit log properly.
The ones that were merged into the source should appear under “closed”, but apparently there are none (yet). Personally, I also don’t like the idea of keeping things more or less closed (although you can dig through the git commit history of course if you want to).
But yes, we need a public issue tracker as already has been discussed here:
I guess it’s the right way to do it professionally (review, commit). But there is no howto for the “normal” people on how to pull what kind of changes (even if still under review). Some hints how do use it with repo can be found here.
Well if somebody (@xaxa a maybe?) would be so kind to cherry-pick this stuff and do a userdebug build and check if root is working we could include cherry-picking these commits in the build instructions as long as they remain unmerged.
After applying this hack, I got it to build. (Really weird error where build doesn’t pick up all source files.) It doesn’t install su to the correct location and correct permissions, though.
edit it turns out seSuperuser hasn’t been updated for building in-tree. Use my fork if you want it to compile. I can’t get the daemon to run on startup, though. Not even after adding import /init.superuser.rc after the other imports in system/core/rootdir/init.rc.
edit after adding some SELinux stuff (part of fork) the daemon starts, I just get Permission denied now.
Also, you can use this manifest now (for as long as the fork is needed).
As I mentioned the build continues if the .mk-file of Superuser is renamed. Renaming or deleting the mk-file of the FP-build-tree will lead to early errors on includes. However I would like to be sure that .mk-files of any names are integrated properly. Or even better, to learn about how to work around such things. I mean this kind of problem should be common. Is there no possibility to “tell” the system-.mk-file to call the Superuser-.mk-file aswell?