Hi, sorry for the late reply. Good question, I sometimes run ‘make clean’, especially when I observe weird things 
. Make clean also seems to delete all contents of the out folder
Hi Max_S, I created that script as kind of integrity check. Strangely, I did not observe build errors. Though, I might have overlooked a warning somewhere. What kind of additional checks do you have in mind? I do not yet check the sha1sums, but that should be no issue to add.
Sure, the UART is still connected. I just need some time to prepare to record stuff again.
Above, in post 23 is a link to a gist that shows how it looks like and the lines that are necessary in the kernel config.
Just drop me a message what I can try for you.
Yes, definitely. I’ll try to build LOS with it. Looks really great, they have important security features enabled as well like Android-Verified-Boot and SELinux.
Good that Fairphone supported the development. However would have been nice if they had published some details about that. But hey, finally we have something available we also can build upon 
I’m not totally sure, but it also seems that they officially signed the /e/ images. Otherwise I would expect that locking the bootloader would make it fail to boot. However I never tried, maybe the bootloader doesn’t check the signature or supports certificate pinning or something like that. I’ll try to check for that.
4 Likes
Yes, maybe some integrity check with hashes etc.
The build stopped for me with an error message when files from proprietary-files.txt were not available.
Oh yes, and it looks like there is some output from the bootloader. Lines like that are interesting here:
[21:46:24:644] [1840] avb_slot_verify.c[1840] :[1840] 417[1840] : DEBUG: [1840] Loading vbmeta struct from partition '[1840] vbmeta_b[1850] '.␍␊
[21:46:24:644] [1850] avb_vbmeta_image.c[1850] :[1850] 226[1850] : ERROR: [1850] Hash does not match!␍␊
[21:46:24:644] [1850] avb_slot_verify.c[1860] :[1860] 539[1860] : ERROR: [1860] vbmeta_b[1860] : Error verifying vbmeta image: [1860] HASH_MISMATCH[1870] ␍␊
[21:46:24:644] [1870] ReadRollbackIndex Location 0, RollbackIndex 0␍␊
[21:46:24:644] [1870] avb_slot_verify.c[1870] :[1870] 417[1870] : DEBUG: [1880] Loading vbmeta struct from partition '[1880] system_b[1880] '.␍␊
[21:46:24:689] [1880] negative Offset (-64) converted to (0xbfffffc0) ␍␊
[21:46:24:689] [1890] read from system_b, 0x40 bytes at Offset 0xbfffffc0, partition size 3849453568␍␊
[21:46:24:689] [1890] StartBlock 0x5fffff, ReadOffset 0x1c0, read_size 0x40␍␊
[21:46:24:689] [1900] read from system_b, 0x740 bytes at Offset 0xbff5b000, partition size 3849453568␍␊
[21:46:24:689] [1910] LastBlock 0x5ffadb, ReadOffset 0x0, read_size 0x140␍␊
[21:46:24:689] [1920] ReadRollbackIndex Location 2, RollbackIndex 0␍␊
[21:46:24:715] [1920] avb_slot_verify.c[1920] :[1920] 157[1920] : DEBUG: [1920] boot_b[1930] : Loading entire partition.␍␊
[21:46:24:843] [2070] avb_slot_verify.c[2070] :[2070] 232[2070] : ERROR: [2070] boot_b[2080] : Hash of data does not match digest in descriptor.␍␊
[21:46:24:890] [2080] avb_slot_verify.c[2080] :[2080] 157[2080] : DEBUG: [2090] dtbo_b[2090] : Loading entire partition.␍␊
[21:46:24:890] [2100] avb_slot_verify.c[2100] :[2100] 232[2100] : ERROR: [2100] dtbo_b[2100] : Hash of data does not match digest in descriptor.␍␊
[21:46:24:890] [2110] system_b uuid: 68bc91e6-9723-e5d0-1210-96dcc78c4f05␍␊
[21:46:24:890] [2110] boot_b uuid: 813695bb-3859-9b75-5afd-a3eb6165e68d␍␊
[21:46:24:890] [2120] vbmeta_b uuid: 4617542d-6902-0abe-e740-2c209d448ea4␍␊
[21:46:24:933] [2120] State: Unlocked, AvbSlotVerify returned ERROR_VERIFICATION, continue boot␍␊
However I guess it is caused by vbmeta we need to build, maybe with AVB enabled. The /e/ guys did that, so hopefully we can adapt that. If still not working I’ll come back to you.
After some night hours I got LOS successfully building with the /e/ config. Some small changes were required, e.g. in extracting the binaries. Great thing is that I was able to flash it with TWRP from @k4y0z now. Seems like my expectation with the vbmeta image was correct. Checking the image from stock firmware, /e/ and my build one with avbtool it seems like the test key is used for all of them:
Public key (sha1): cdbb77177f731920bbe0a0f94f84d9038ae0617d
This would also explain why bootloader can be locked with it.
Ear speaker is again not working with it. I think most probably because they use a different qcom hardware branch. I’ll try to switch to that and build again tomorrow.
I uploaded the built package and the images to github. Maybe someone want to give it a try.
I think we should go with that config as a base from now. The /e/ guys did a great job. And this would also allow to sync between the repos more easily.
@dk1978 What do you think?
10 Likes
@Max_S:
I agree. From what I could judge, everything in the device tree looks clean and well thought through. The /e/ people obviously got some “inside” knowledge such as Arima code contributions that we can make use of.
Hi guys,
I just updated my FP3 to the 0118 release. I examined the changes to the vendor blobs and stumbled over this change to what appears to be a list of emergency numbers of all things:
diff --git a/proprietary/vendor/radio/qcril_database/upgrade/0_initial.sql b/proprietary/vendor/radio/qcril_database/upgrade/0_initial.sql
index a06eba8..1d40d52 100644
--- a/proprietary/vendor/radio/qcril_database/upgrade/0_initial.sql
+++ b/proprietary/vendor/radio/qcril_database/upgrade/0_initial.sql
@@ -272,6 +272,9 @@ INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('231','01','911','','');
INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('231','01','112','','');
INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('214','03','112','','');
INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('214','03','911','','');
+/*<20200318-LindaGuo,Add emergency number 016 for Orange ES. */
+INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('214','03','016','','');
+/*>20200318-LindaGuo. */
INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('208','01','911','','');
INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('208','01','112','','');
INSERT INTO qcril_emergency_source_mcc_mnc_table VALUES('334','020','060','','');
If I interpret this correctly, then someone updated an emergency call number for Spain as 016. I don’t know about Spanish emergency numbers, but Google tells me 061 is an emergency number for health emergencies. Could this be a serious typo? Does anyone have more ideas?
1 Like
Hi,
I finally got it built and installed! It has been long for different reasons, but I’m ready now.
I have coding skills (that’s my job), but not much Andoid OS knowledge.
My FP3 is my only phone and must remain in a working state (or in a state that can revert to a working state).
Given the points above, I’m ready to help, just let me know.
I’m currently rebuilding with signature spoofing patch, if anyone is interested in having this patch, just tell me.
1 Like
@pipoprods:
you are welcome to help. If you need a working fallback for your phone, then I suggest you keep the stock Fairphone image on one slot and an experimental system like /e/ or LineageOS on the other slot. This should work, provided you take care to back up and restore your userdata partition which cannot easily be shared between the two systems.
1 Like
Why don’t you just google this? 016 is indeed a legitimate emergency number in Spain, see
https://violenciagenero.igualdad.gob.es/informacionUtil/recursos/telefono016/home.htm
2 Likes
Trust me - I did but did not find that page. Only pages about 061. That’s why I wrote here instead of troubling support, knowing there are smart people here. 
Anyway thanks for the info.
1 Like
You definitely need to have good backups in that case. Factory reset is required very regular unfortunately, e.g. when you switch between stock, /e/ and LOS. Also I’m unsure how device encryption influences that.
However I hope that we now come to a more stable state where we can switch between different LOS versions on the slots and don’t need to reset data all the time. I also want to start using the FP3 for daily usage and don’t want to order any more spare parts for my FP2 
Maybe you can try to build with the microg docker container. That would be one of my next steps at least 
Ok. How should we proceed on that? I’d try to get the branch to a buildable and good state first now. Should we then merge it to the lineage-16.0 branch or should we rename it and replace it completely? I mean it’s a lot of changes and I would instead try to move our README etc. to that new tree.
I built again. Now ear speaker and Wi-Fi should work. Find the package for installation with TWRP and the images here.
I also experienced some lag when scrolling so I tried to revert some of the graphics settings. But not sure yet if it improves it.
I faced some issues with extracting binaries. It complained about the WfdCommon.jar file. So I partly reverted the extract script.
@dk1978 Maybe you can try to extract binaries and build with the branch.
Ok. How should we proceed on that? I’d try to get the branch to a buildable and good state first now. Should we then merge it to the lineage-16.0 branch or should we rename it and replace it completely?
Good question. It seems that the /e/ build is not quite perfect either, judging by your findings and the commit history. I also have some open questions, such as whether products such as vendor/lib64/libsensorndkbridge.so are better built from source than simply copied as blobs.
Why does /e/ use a different extract script, and what does the final build product for the vendor partition looks like - and where do they get their vendor blobs?
I would suggest we go forward a bit more gradually, rather than copying their entire setup. First clean up proprietary-files.txt on our end so that it the final result is more or less identical to the /e/ version. That would make a merge less painful anyway.
3 Likes
Originally I took the script from Motorola’s river configuration and also needed to modify the script, because we don’t have a shared common platform in our case.
From this manifest file I guess they do something similar than we do. I mean take the binaries from stock firmware and maintain it in a (private) repository.
You mean still use our version of the proprietary-files.txt and the extract script together with their configs?
1 Like
Why did they chose that “e” thing over LineageOS for FP3? Any info on that?
2 Likes
I don’t have any info, sorry. But I assume that LOS wouldn’t be able to sell FP3s preinstalled while /e/ already has the infrastructure to do so. But that’s just guesswork (and probably off-topic here).
1 Like
You mean the official partnership between Fairphone and /e/? That’s easy at least in theory (I can’t speak for Fairphone).
LineageOS is done by a group of (great) volunteers, a non-entity hard to interact with as a company. LineageOS development could end today without any legal consequences.
Of course it won’t, but it could, and then what?
E is a foundation, a legal entity a company like Fairphone can interact with on legal and business terms. As @Ingo said, the foundation can sell Fairphones, for instance.
And the foundation has a track record of what it does for a few years now, that’s reassuring, too.
7 Likes