[HOWTO] ✏ Compiling Fairphone Open OS / Rooting

Click on the name of the user you want to send a PM.

thank you, but i dont get it. this is embarrassing but if i click on the username i just can see the users batches, activity… but i cant find a pm button. so sorry for my of topic postings.

What i need is an FP2 ROM. I formatted my FP2 and have no backup (yeah thats funny).

So if someone can help me out maybe you manage to send me a PM.

@tinkerweasel, could you get in contact with @dsfhoiud?

1 Like

Maybe this is the wrong thread?!

I noticed changes to the repository. Is there some kind of changelog available? Do we know if one or some of the known issues are already fixed in the Open Source sources? And how would one know if the sources available are stable for day to day usage?

Or is it to early to ask these questions and we expect something along these lines to come when Fairphone starts to publish pre-built OS versions later in Q1/2016?

To a certain extend I’m asking as I expect delivery of my FP2 and wanted to go Google-free right form the start…

Grazie mille for your thoughts… :wink:

There has been some bug squashing in the sources, but I’m not sure what has been fixed.

By extended use. If this is a concern, wait for the pre-built versions which will (hopefully) have some beta-testing done before general release.

1 Like

I finally managed to get a succesful build with OpenJDK 7. I wanted to try it out in the emulator first but the emulator doesn’t work at all. After some search I found one has to put

$ . build/envsetup.sh
$ set_stuff_for_environment
$ choosecombo 1 FP2 2
$ make -j8

in-between before compiling (isn’t mentioned in source.android.com aswell). However a build takes a couple of hours and I highly prefer to get the emulator working on the ready build afterwards. All solution I found refer to the whole android studio by google. If no other solution I will install it, but I am pretty sure we have people here who got the emulator running on their builds. If so, my first question is: where was actually the whole SDK-Stuff put into (by using the commands given by the thread-starter)?

Happy to hear it’s working for you. The emulator seems to be broken, I think some other people in this thread confirmed it.

What do you mean by “SDK-Stuff”? The problem is not the emulator itself but that the build script / process for building the emulator image (which is different from the production one) is broken, so using another emulator probably won’t help.

Thanks to whoever added a link to my post about the Gapps.
As far as i understand the issue, everyone who wants to build Fairphone OS by himself has to do these steps.
Otherwise, none of the binary blobs which need system access will work properly. Just have a look at the list of APKs to sign, and you’ll understand what i mean. :slight_smile:

2 Likes

My Docker-Build crashed at

target Package: FrameworkCoreTests_install_use_perm_good (out/target/product/FP2/obj/APPS/FrameworkCoreTests_install_use_perm_good_intermediates/package.apk)
warning: ignoring flag -c hdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c mdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c hdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c mdpi-v4. Use --preferred-density instead.
adding: lib/ (stored 0%)
adding: lib/armeabi-v7a/ (stored 0%)
adding: lib/armeabi-v7a/libframeworks_coretests_jni.so (deflated 75%)
warning: ignoring flag -c hdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c mdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c hdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c mdpi-v4. Use --preferred-density instead.
adding: lib/ (stored 0%)
adding: lib/armeabi-v7a/ (stored 0%)
adding: lib/armeabi-v7a/libframeworks_coretests_jni.so (deflated 75%)
target Package: FrameworkCoreTests_install_uses_feature (out/target/product/FP2/obj/APPS/FrameworkCoreTests_install_uses_feature_intermediates/package.apk)
warning: ignoring flag -c hdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c mdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c hdpi-v4. Use --preferred-density instead.
warning: ignoring flag -c mdpi-v4. Use --preferred-density instead.
adding: lib/ (stored 0%)
adding: lib/armeabi-v7a/ (stored 0%)
adding: lib/armeabi-v7a/libframeworks_coretests_jni.so (deflated 75%)

is there somebody with the same error?

Yes, i’m using AUFS. That could be the Problem.

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.

Below the list you published as reference.

/system/app/TimeService/TimeService.apk
/system/app/PPPreference/PPPreference.apk
/system/app/QuickBoot/QuickBoot.apk
/system/app/SVIService/SVIService.apk
/system/app/btmultisim/btmultisim.apk
/system/app/GsmTuneAway/GsmTuneAway.apk
/system/app/SystemAgent/SystemAgent.apk
/system/app/qcrilmsgtunnel/qcrilmsgtunnel.apk
/system/app/WfdService/WfdService.apk
/system/app/com.qualcomm.qti.services.secureui/com.qualcomm.qti.services.secureui.apk
/system/app/fastdormancy/fastdormancy.apk
/system/app/CABLService/CABLService.apk
/system/app/SimContacts/SimContacts.apk
/system/app/NetworkSetting/NetworkSetting.apk
/system/app/xdivert/xdivert.apk
/system/app/RCSBootstraputil/RCSBootstraputil.apk
/system/app/QTIDiagServices/QTIDiagServices.apk
/system/app/QtiDdsSwitchService/QtiDdsSwitchService.apk
/system/app/atfwd/atfwd.apk
/system/vendor/app/ims/ims.apk
/system/priv-app/com.qualcomm.location/com.qualcomm.location.apk
/system/priv-app/com.qualcomm.msapm/com.qualcomm.msapm.apk
/system/priv-app/CNEService/CNEService.apk

I’ve experiences exactly the same error and changing to devicemapper has solved it.

This solution is now also indicated in the Readme of the image (thanks to a generous contributer).

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 :smiley:

1 Like

Hello @kuleszdl, @tphysm, @fp1_wo_sw_updates

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.

subdir_makefiles := \
        $(shell build/tools/findleaves.py --prune=$(OUT_DIR) --prune=.repo --prune=.git $(subdirs) Android.mk)

Don’t forget to look into:

build/core/main.mk
build/core/Makefile

# 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. :expressionless:

@xaxa

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 :slightly_smiling: 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.

I’ve just noticed that there’s a couple of su-related open code reviews on Gerrit with topic:appops_su.
May be useful.

2 Likes

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.