[ROM][UNOFFICIAL] LineageOS 16.0 for FP3

[Max_S]

@anarcat

LTE works now? it’s marked as “not working” in the summary here and on github… Would love to have an update on the LOS status for the FP3!

Yes, for me it was working fine today. Also I gave GPS a try few minutes ago (needed to step outside for that ). It’s also working fine.
However now the small things start to arise. E.g. for me the ear speaker was not working for calls.

[david-guillot]

@Max_S

@david-guillot

Flashing with fastboot (on both slots) seems to be going better, but first boot is stuck on LOS splash (it moves, but runs in circles ; I let it run for like 20 minutes just to make sure)

If the LOS boot screen is shown, is already good. Did you do a factory reset with fastboot -w? Do you have logcat output (adb logcat)?

Actually factory reset through fastboot did not work, something that seemed related to partition type/block-size. But factory reset through LOS recovery did work, ROM 20200330 could boot completely, and I then flashed 20200413 and it’s working like a charm! Did not have a chance to test many things but fingerprint lock is working, Wi-Fi as well, etc. I’ll try to install several apps from f-droid to see what can go wrong. Unfortunately I don’t have nano-SIM yet so I cannot test LTE/phone, but everything that can be done through Wi-Fi, I’ll test it

[dk1978]

@david-guillot:
Good news, nice to hear.
Let us know how audio and video behave, I still expect some problems there. It is a good idea to always let adb logcat run while booting and capture the output to a file, e.g.

adb logcat | tee adb.logcat.txt

Assuming there is no private data stored on your device, you can share the output file on Gist .

[michlx]

Hi @Max_S, I have not been very successful lately. Strangely, all the images that I compile seem to have issues and stop somewhere in the middle of booting. I was able to make out seven files that were missing in my proprietary files compared to proprietary-files.txt. However, a new extract of the files solved that. But that did not help much I’m kind of stranded in a sort recovery mode (the Fairphone logo persists & I can login via adb shell).
In case that I’m doing something wrong, I am very keen to find out what!
I just saw that you added lineage_16_fp3_20200413.tgz, so I’ll try that and see what happens.

[dk1978]

@michlx:
I assume you mean that the LineageOS logo persists? The Fairphone logo should no longer display if you are booting a LineageOS build.

You could try the following steps:

fastboot getvar current-slot # to confirm that you are still on your desired slot
# optionally fastboot -aa or fastboot -ab to always force the correct slot first
fastboot flash vbmeta vbmeta.img --disable-verity   --disable-verification # with a stock vbmeta.img
fastboot -w

Then reboot and see if things improve.

Regards,
D.

[michlx]

Hi @dk1978,

indeed, the Fairphone logo was persisting, it turned out to be recovery mode.
Both slots had an usuccessful state, that was probably the main cause.
I was able to fix that and finally boot the image that I compiled on Tuesday.
Very cool, the GSM modem works now and LTE is also there

So far, I do not have TWRP installed, so the recovery mode was using my kernel, booted half and just displayed the Fairphone logo (I do not know if this is normal or not).
It took a while to find out what was going on (in the end adb get-state also said “recovery”).

After flashing vbmeta with --disable-verification I ran into the same problems as k4y0z here:

[HOW TO] Flash a custom ROM on FP3 with GSI

Fingerprint sensor on arrowOS definitely worked for me. I think k4y0s can tell you more later.I wasn’t there all the time, I also played with another project or just talked with people But there is a command to get rid of the shutdown in 30 seconds, it’s “dm-verity enforcing” or something in adb, even works from twrp. I think twrp caused some issues because it modified some partitions by mounting them read write. Playing with vbmeta made my phone just showing a black screen for hours …

So I had to disable it again (and care about the slot success states).
Does it work for you?

[dk1978]

Hi @michlx,
I have not yet encountered problems like you described. My setup is as follows:

1. 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.
2. 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.
3. 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.

Regards,
D.

[basxto]

@dk1978

adb reboot “dm-verity enforcing”

If you don’t do that, the bootloader will mark your slot as non-bootable after some boots and switch the slot.

[michlx]

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…

[dk1978]

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.

[Max_S]

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?

@dk1978

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.

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?

[z3ntu]

@Max_S

I fell over the WeAreFairphone organization where you are members. Could we maybe also use this place for the repos?

That’s definitely possible, I’ve created GitHub - WeAreFairphone/android_device_fairphone_FP3: Android / LineageOS 16 device tree for Fairphone 3 and invited you. I’ll create the kernel repo in a second. For blobs you can use FairBlobs · GitHub which I’ve created for the FP1 & FP2

[dk1978]

Hi @z3ntu,
I am also interested in working on https://github.com/WeAreFairphone/android_device_fairphone_FP3, please be so kind and invite me as well.

[z3ntu]

I’ve added you as well. Thanks for working on this!

[Max_S]

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?

[dk1978]

@z3ntu: Thanks for adding me!

@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.

[david-guillot]

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?

[pipoprods]

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

[Max_S]

@dk1978

I have forged ahead and pushed a ton of changes and missing commits to the new repos.

Don’t know what you changed with your last commit, but it seems to be the same as in the merged pull-request before

[Max_S]

@david-guillot

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?

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