Hi @michlx,
I have not yet encountered problems like you described. My setup is as follows:
Slot A has the stock Fairphone build (Fairphone_FP3_8901.2.A.0110.20200109_01092024_user_release-keys), not updated to the latest release yet, with Magisk installed to get a non-crippled adb shell. This is nice for testing and comparing things during development.
I never install TWRP, I only boot its image on-demand using fastboot boot ..., and so far I only used its modifying/installing commands to install Magisk on Slot A.
Slot B has our LineageOS eng build.
I never used the adb reboot "dm-verity enforcing" trick until now, so I do not think that step is strictly necessary. I tried that command just now and it indeed got rid of the 30-second reboot warning screen on booting into LineageOS.
I will have to invest some time and analyze the procedures on boot if we are ever to have a user-friendly and fail-safe flashing procedure.
Hi, that mostly resembles my setup . However, I haven’t used Magisk yet.
Looking back, I believe that, besides being an Android newbee, the proprietary files have been the largest cause of (really wild) trouble. First a bunch of files was missing, then only seven. In the latter case I am very sure that extracting them was successful. I have the impression that there is no check to see if the files listened in proprietary-files.txt are really there. Might be a flaw in the build chain. I started a script that might help but its still a hackery.
Nevertheless, what we achieved is great success so far .
I still observe some differences in what you and Max marked as working (outgoing calls, background light configuration, LED). I will have a closer look on that…
Hi @michlx,
yes, the proprietary files are trouble. We might as well have started out by flat including the entire vendor image and simply fixing paths where needed.
The proprietary-files.txt is an ugly hack - and no, the file itself is ignored by the build system. On every change of its contents you have to rerun the extraction script yourself. There is not much that can be done about that: the build system cannot know by what nefarious means you have acquired pre-built proprietary code artifacts and where you have copied or mounted them to act as the source for the extraction copy command.
Concerning the difference between what Max has marked as “working” in his README.me: his version is the authoritative one, I have simply not pulled in his changes yet in my repo.
Maybe we could push the extracted vendor files to a github repo and include it simply via the repo overlay. However I guess this would cause some legal issues. Does anybody know about the laws in detail here?
As I’m not comfortable with that situation (e.g. not enough time and experience to maintain this), I created a github organization FairphoneCommunity and imported my repo there. Let’s maintain it at this central place together in a clean way with pull-requests etc.
What you all think about that? Furthermore feel free to contribute, apply for access rights or suggest further repos we should add here. @dk1978 I already invited you.
Edit: @Ingo@z3ntu I fell over the WeAreFairphone organization where you are members. Could we maybe also use this place for the repos?
Thanks for that. Let’s have a common place where to put those things.
Unfortunately I accidentally imported the repo from mine instead of FairphoneCommunity one and we already made changes there Can you reset it please?
We can simply do the pull-request merge again. I missed to update the readme anyway.
But maybe can you make lineage-16.0 the default branch?
@Max_S: I have forged ahead and pushed a ton of changes and missing commits to the new repos. Hope I did not cause too much confusion - but we should be settled now at WeAreFairphone.
It’s great to see you guys going towards consistency and better communication, which is the path to an official LOS ROM
I have a question about current implementation: I see a lot of proprietary files (and the ear speaker issue seems to have been fixed by integrating more of them) ; is there a way to understand what they are, and do we have a chance to see, in the long run, some of them replaced by source-compiled binaries?
Hi there,
Just to let you know I’m trying to build it as well. I dont have much Android expérience, so I don’t know what help I’ll be able to give, but if I can, I will
Partly yes. Some may possible to build from Android sources or sources from Qcom respectively. However I guess that many of them will only be available as binaries for whatever reason. Of course you could invest lot of time to reverse-engineer or convince Qcom to release sources
@david-guillot:
Considering reverse-engineering: for fun I loaded some of these Qualcomm binaries into Ghidra and had a look at what they do. Most of the code is just boring glue code that translates requests to and from lower levels such as drivers. The really interesting Qualcomm code will likely be the firmware that controls radio/baseband and runs on a dedicated CPU core (modem partition)?.
Hm thanks for your answers @Max_S and @dk1978. My interest is less technical (I certainly won’t start a reverse-engineering adventure ) than functional (I like to know what parts of my phone require proprietary blobs) and I see a quite huge list in proprietary-files.txt, but I guess it’s the usual…
And actually my real interest is: how to make your amazing work an official LineageOS distribution as soon as possible, in order to have it updated and to recommend it to friends who own a FP3 but just want to keep things simple. There’s probably a way for me to help (not on the tech stuff but on structure/documentation/communication/etc.) meeting Lineage requirements. I have never done that but if you tell me what are your views on going official and on what parts do you need help, I’d be glad to give it a try .
Hi,
to cross-check if proprietary files are consistent, I’ve created a small script that checks if all specified files are there. That could help and warn if the proprietary-files.txt was changed or to avoid strange build issues (like on my PC … ).
After having a closer look on the proprietary files and switching to the WeAreFairphone repo, most of my previous issues vanished. The only thing that is not working so far is the earspeaker. That is weird as I see commints that should’ve fix it.
Does anybody else have issues with the earspeaker?
That is a bit worrying. I know it sounds lame, but have you tried a clean build (wiping the out folder completely)? I have had issues with left-over build artifacts on configuration changes already. Example: the useless FM radio app kept landing in the build image until I deleted intermediate build products by hand.
Please feel free to open an issue on the Github repository so we can look into this in more detail.
Not really. I am a software guy and I don’t know my way around the hardware internals of the FP3. If someone can demonstrate that an FM radio should be there and operational, we will get the app for it running. Until then, no point in including something broken. By the way- I have not seen any FM radio app in the stock FP3 system either.
. However, I haven’t used Magisk yet.
) than functional (I like to know what parts of my phone require proprietary blobs) and I see a quite huge list in 
.