FP4 and (unofficial) LineageOS

Currently compiling LOS 19.1. If no one complains this will be my last 19.1 build, since LOS 20 seems to be fully functional now.

1 Like

I’m using the same, as MagiskHidePropsConf doesn’t offer any FP4 verified signature for some unknown reason.
SafetyNet passes without issue on my device though. I’m not using MicroG since I’m rolling with GApps.

@anon62833029 did you enforce exclusion list in Magisk and add Play Store as well as Google framework to Magisk’s exclusion list ?

I remember having to:

  • wipe all cache/data for those apps while being in airplane mode
  • adding them to exclusion list in Magisk
  • setting verifed FP3 signature with MagiskHidePropsConf
  • rebooting
    to get everything working.

Hey @zocker1999net, thank you for providing the images! Today I tried installing your ROMs, which fails for the most current. The last but one works fine. Also, the OTA-Update fails. Can you confirm that or is it particularly me?

EDIT: The device is stuck on the boot logo on most current version.

It must be an issue with MindTheGapps. Is there a way to switch Gapps? Might have to try NikGApps.

Last 19.1 build, if no one complains.



sha256sum lineage-19.1-20221114-UNOFFICIAL-FP4.zip recovery-19.1-20221114-UNOFFICIAL-FP4.img 
acaebe80fc1ed13f310637a599d2058bff9318769eacad0e2277c0e183331e2d  lineage-19.1-20221114-UNOFFICIAL-FP4.zip
5d6c216dfae5ef26ea28406d4e0585cd2962b85ed7159f427bafb5cb2fcc73c4  recovery-19.1-20221114-UNOFFICIAL-FP4.img

It should be the same issue as for the official LOS FP3 release. Here’s my workaround to fix it.

Not sure about if it’s only related to MindTheGapps, but it’s a permission problem after the update. Maybe it’s caused of the security fixes inside the LOS update. But as stated above, I posted a workaround for it.

Personally if you want to switch to a new Gapps supplier, you should do a full wipe and a clean install. Otherwise you have old configs and scripts which can cause problems in the future.

1 Like

Thank you for the heads up. I relate to the microG version, which might well feature a similar issue as the GApps version. Reflashing of the microG unfortunately is no option, as I didn’t flash something additionally in the first place.
To clarify: The (then initial) boot also failed on fresh install.

All I wanted to say is that this isn’t only you which is affected. It seems like a bigger “problem” with the OTA-Update (FP3/FP4).

When GApps are installed during the use of your phone, you have to reinstall them via the recovery. It’s not a definition when you installed them, it’s a definition if you installed them. Then you have to overwrite the app settings with this reflash of the package.

Sorry for my question, but did you tried the workaround and did it solve the problem when using the new build?

1 Like

Thank you! Though this is reassuring, it’s sad to hear.

If I read your workaround correctly, the solution is based on reflashing GApps to get rid of the boot loop. As the ROM I used already includes microG, it isn’t flashed separately. Hence, re-flashing a “microG package” is not feasible to the extend I understand the matter.

Typos II

I don’t know too much about microG, but maybe there is an “integration” package available somewhere so you can flash it?

Second option but I’m not quite sure if it’s possible during recovery mode is to remove the microG packages with following adb command:

adb shell pm clear PACKAGENAME

e.g. for Google Play Services

adb shell pm clear com.google.android.gms

to get rid of the microG variant of the Google Play Services. Don’t forget to do this for all of the microG-packages listed on their homepage or which was integrated in your ROM.

After that, download the newest packages from the homepage and reinstall the microG-packages with this command:


e.g. for their newest Google Play Services variant it would be:

adb install -d com.google.android.gms-223616050.apk

DO NOT RESTART before you have reinstalled all the packages, otherwise some unpredictable errors could happen.

1 Like

Turns out my issues were permission related. Due to the number of messed up apps I did a factory reset. Still not sure how to prevent this from happening in the future.

Not sure if this is LOS 20 related, but my FP4 isn’t detected in File Transfer mode no matter the computer I plug it on.

Definitely not a driver issue, as I’ve tested it on 4 different computers that do see my 2 others devices.

Funny thing is I can run adb/fastboot commands without any issue.
Photo storage mode is also working.

It appears really only File Transfer mode is somehow broken. I think this has appeared since I updated from LOS 19 to 20 but can’t be 100% sure as I do not use this mode very often. Anyone else experiencing this ?

@Aaanze just tested it here on my side. Works for me under Linux. Did you try another cable?

I assume you’re referring to microG Service Core? If so, yeah, I did. Aside from that, I also added FakeStore. SafetyNet check still yields CTS profile mismatch, unfortunately. I’ll try a few other options, though I might just end up switching to NikGApps.

I had the same issue happen to me recently; disabling USB debugging seems to have helped. Though this only occured once, on my Windows boot, where I haven’t enabled USB debugging since. On Linux it appears to mount properly either way.

Edit #1: Just tested it on a different machine running Windows. Results in the exact situation you described, with PTP working and file transfer (MTP) being broken. It seems Windows does not recognize the device as an MTP source when in ADB+MTP mode for some reason.

Edit #2: It seems it was a driver issue after all. When USB debugging and MTP are enabled, an unrecognized MTP device appears under “Other devices” in Device Manager with apparently no drivers available for it. To fix this, you need to select said device, and navigate to “Update driver” → “Browse my computer for drivers” → “Let me pick from a list of available drivers on my computer” → “Portable devices” → “(Standard MTP Device)” → “MTP USB Device”. Then click next and proceed against the warning. Windows should now correctly recognize your phone as an MTP device even with USB debugging enabled. As for why this occurs, I can’t really elaborate further.


This absolutely mind blowing.
How weird that multiple computers, simultaneously lose the ability to detect the device as MTP USB ?
This was so unlikely I didn’t even thought about checking the device manager. How silly of me…
Anway, thanks a lot :slight_smile:

1 Like

I wouldn’t say they lost the ability to detect it as an MTP source, rather the phone changed the USB data it reports to the computer upon connection.


More specifically:

  • the product ID for FP4 changes (from 0x4EE1 to 0x4EE2) when in ADB+MTP mode, thereby making the same USB MTP interface appear as a separate device;
  • additionally, in the same ADB+MTP mode, the bus driver fails to report a compatible ID of USB\MS_COMP_MTP for the MTP interface (possibly due to LOS 20 not providing enough data to Windows to classify it as such) which is required to identify the device as a viable candidate for the MTP driver (see line 37 of %SystemRoot%\System32\DriverStore\FileRepository\wpdmtp.inf_*_*\wpdmtphw.inf; INF files are used during device installation processes); or, alternatively, …
  • the MTP interface should have bInterfaceClass = 0x06, bInterfaceSubClass = 0x01, and bInterfaceProtocol = 0x01 (see line 38 of the same file), but in our case it has the values 0xFF, 0xFF, and 0x00, respectively.

Given the above, it seems reasonable that the MTP driver is not considered to be appropriate (since neither of the two conditions to do so are met) and the MTP interface is left untouched.

Now, to understand why the bus driver fails to report a compatible ID of USB\MS_COMP_MTP when USB debugging is enabled requires, I would imagine, at least a superficial understanding of the USB and MTP protocols, and their implementation within Windows and/or Linux. Neither of which I have, so my journey ends here.

If anyone’s interested, the sources:

  1. Overview of Device and Driver Installation - Windows drivers | Microsoft Learn
  2. USB Generic Parent Driver (Usbccgp.sys) - Windows drivers | Microsoft Learn
  3. Enumeration of USB Composite Devices - Windows drivers | Microsoft Learn
  4. Overview of INF Files - Windows drivers | Microsoft Learn
  5. INF Models section - Windows drivers | Microsoft Learn

The information above was obtained through Device Manager and USBView.

I suspect that your hunch about LOS 20 being the cause of this is correct, though.

Any time.


Good morning!
I’m still using LOS 19, but only because I didn’t have time to update.
Since I installed LOS (on my FP4 of course), I can’t receive SMS anymore.
Does anyone have any idea what this could be due to?
Thanks a lot!

I haven’t really an idea, but at least I can contribute some questions. :smiley:

Did you already try another messenger app? Sending SMS is working fine?

Have you been able to receive SMS with the FP4 using the original ROM or did you flash LOS immediately and had an Apple device before?

1 Like

Oh I had this one too !

I can’t really tell what I did, but eventually, it started working, like after a few days…

I did a lot of probably useless stuff such as clearing cache of the application, reflashing LOS, installing then uninstalling alternative SMS app, sending myself a lot of SMS from my own device…

And one morning… I received a whole bunch of SMS at once, and it started working.
Sorry for the imprecise answer, but that’s all I’ve got at this point.

Maybe you could also doublecheck if the phone number of your SMS central* is correct.

*don’t know want it is actually called in English.