For the full thread, see this topic on the FP4 forum: Restoring stock OS after unsuccessful LineageOS (iodé) install - #15 by Wallby - Fairphone 4 - Fairphone Community Forum
Apparently @rik can turn this into an issue on the gitlab issue tracker page? According to: How to submit a bug report?
So the current situation is that the device is locked but the device is unbootable? I did read through the thread but it may be easier to restate the current situation here.
If this was a purchase from iodé then did you also contact support? Just trying to make sure we aren’t crossing paths.
No it’s not unbootable. Hirnsushi has expertise about this that I don’t have. This comment is his conclusion: Restoring stock OS after unsuccessful LineageOS (iodé) install - #14 by hirnsushi - Fairphone 4 - Fairphone Community Forum
I didn’t purchase anything from iodé. I have a Fairphone 4 that I installed it on coming from stock FP4 OS.
So you are back on stock FPOS then. I don’t quite understand the line of thinking, as far as I know the FRP would prevent installing an older patch set, but a new (esp. iodé 7 beta) iodé build should match the upstream patch version.
But maybe the situation is that supposedly since FRP was triggered it then prevents the bootloader from being unlocked again? That means in Develop Options you can no longer enable the “Allow OEM Unlocking” option?
No I came from stock FP4 OS to iodé. To avoid confusion, it seems better to take your time to read it when you can then to respond fast and wrong a lot. That only clutters the thread.
Yes I can no longer unlock the OEM option in the settings. That is correct.
Yes fair enough, but linking us to other threads to understand your situation also leads to confusion. The thread you referred us to is titled “Restoring stock OS after unsuccessful iodé install” and there is so much back and forth on it about if FRP is enabled or not and try this try that etc that it leads to a bit of confusion.
Now back to your case: I will check with the devs to see if they can comment on how to reset the FRP trigger (that I am still not certain if that is the reason you can’t enable “Allow OEM Unlocking”).
Note I am not a dev at that level btw and yes I have never dealt with FRP getting triggered or even realizing it was a think until recently… I still don’t find it to be a particularly useful design feature if simply flashing another ROM would reset FRP protection.
Note that the other Fairphone user who had FRP triggered did reset it by using the Fairphone web installer but in their case their first sign of a problem was that they could not disable OEM Unlocking. After install of iodé, that option “Allow OEM Unlocking” should remain enabled, so did you then disable it yourself, and after that it was not able to be re-enabled again? Or how did it get disabled? It seems that triggering FRP doesn’t remove that option, as again this other user that triggered FRP did not have that happen?
My suggestion while we see if the dev team can advise on resetting FRP while the device is locked is to attempt to upgrade to iodé 7 beta. I am hopeful that would fix the issue and re-enable “Allow OEM Unlocking”, after which you should be cleared to reinstall FPOS which should reset FRP. At least it is worth a try?
I can explain that part, here’s a quote from the relevant post:
Before that I had ran the lock_critical manually after having already booted the stock Android installation. I didn’t run the fastboot lock command but instead started the iodé installer at this point because it required an unlocked but locked critical state.
Fairphone OS, and most other custom ROMs (as far as I’m aware), will reset get_unlock_ability on first boot.
A new user who unlocks the bootloader, flashes factory images for good measure (which boot by default after installation), will automatically end up with get_unlock_ability at 0. Iodé not resetting OEM unlocking doesn’t mean it gets enabled again, if it’s off it’s off.
With iodé you can just turn it back on again, even with an unlocked bootloader (usually greyed out in that case on other ROMs), but since FRP got triggered that’s not possible anymore.
(Edit: Now that I’ve thought about it a bit more, that really shouldn’t be happening at all. I know for a fact, that installing FPOS again will turn get_unlock_ability to 1 again, without the user having to touch the OEM unlocking switch (assuming the bootloader wasn’t locked of course).
So the question is, does installing iodé behave the same. If it doesn’t, what’s the reason for that, could it be related to not flashing FRP.
I remember that we tried flashing FRP when people started bricking their FP4s years ago to get get_unlock_ability back, but I don’t remember the outcome, nor do I have a spare phone to test… 
)
If the user unlocks the bootloader and then directly installs iodé without flashing factory images first, get_unlock_ability stays at 1, because the first boot on iodé doesn’t reset it.
At that point the bootloader could get unlocked again, and the FRP blocker could be solved by flashing factory images, same as the other thread.
Now the actual issue is iodé not flashing the FRP partition. There’s no reason to keep a Google account in FRP, there’s no mechanism to disable it from microG, it serves no purpose on a phone without Play Services, other than create a potential brick risk.
My proposed solution for this specific case was: We need an ota that flashes FRP, if that is possible, otherwise it has to go to Cordon to get reflashed.
And in the future, please start flashing FRP during first install 
1 Like
The allow OEM unlocking was disabled after installing iodéOS and from the first time I booted it. The iodé installer caused a prompt (one of those bootloader ones) asking whether to relock the bootloader. Thinking that this is desirable always I pressed yes. But the installer triggered it, I didn’t.
1 Like
The lead dev is looking at both these requests, but their first guess is that flashing FRP as part of an OTA will not be possible.
@Wallby there is an issue flashing iodé v7 beta specifically for a locked FP4 that can leave it unbootable, so do not attempt this. The FP4 beta has been pulled for just this reason, but if you previously downloaded it do not install it.
@anon73588713 thanks for the explanations, I am appreciating this challenge more. But I am still not sure how under normal operation a user with a new install of iodé would have get_unlock_ability ever set to 0. Yes, it may be put to 0 when the factory image was installed as you note, but then the bootloader would need to be unlocked before installing iodé and thus the value should be 1 at all times when installing iodé correct?
So in this case, I guess the manual running of lock_critical after install is what then set it to 0? I think a takeaway is then for us to strongly advise not doing that (thus only run fastboot flashing lock if a user wants to lock apart from the installer prompt). Then only use Developer Options to disable get_unlock_ability if that permission wants to be removed, since this would uncover the problem of not being able to toggle that setting as it would not be able to disabled there as the other user with FP5 reported.
In summary, I’ll create a gitlab issue requesting FRP being reset as part of install: Re-flash `FRP` on new installation (#57) · Issues · ota / issue-tracker · GitLab
@Wallby for this current case, it could be that waiting for a fixed FP4 iodé 7 build would enable you to use Developer Options to enable “Allow OEM Unlocking” again. Also it is possible the developer will sort out a way for you to reflash FRP via OTA. But otherwise it does seem you may need to send it to Fairphone?
1 Like
Thanks for the warning. Glad that I waited. I could wait as I have access to everything I need to. What’s the pace at which iodé developers usually work? Weeks? Months?
I had to run lock_critical because I had /e/OS installed before the FP4 stock Android image, which requires unlock_critical to install. And because iodé required a locked critical section (or whatever it is called, I am not an Android developer), I did that as documented on Fairphone’s website for restoring the stock OS.
Installing factory images doesn’t lock the bootloader, the install script doesn’t perform that step. They just dump you in a newly installed system, with get_unlock_ability set to 0 and expect you to reboot yourself and lock it. Which is wildly more unsafe then just locking it before the first boot, at which point get_unlock_ability would still be at 1. If you flash factory images with an outdated SPL and follow the official instructions, then that’s a brick. I’ve told them for years to fix it… 
A user could just flash factory images without locking the bootloader, run it for months (adding a Google account in the process), and then flash iodé. The bootloader is already unlocked, I don’t need get_unlock_ability, you can’t even enable the OEM unlocking switch on stock if the bootloader is unlocked, it’s greyed out.
For that user to start the iodé installation at 1, they’d need to either flash factory images again without booting them after installation (requires modifying the install script or catching the reboot in time), or fake a locked bootloader with Magisk, which makes the OEM unlocking switch available again.
(Or they could run the complete stock installation, including taking the risk to lock the bootloader themself, to then immediately unlock it again, and only after that start the iodé installation, I wouldn’t…)
No, get_unlock_ability was already at 0 at this point, fastboot flashing lock_critical happened after the first boot, and that’s what reset it.
I’ll try to write a test case that hopefully makes this reproducible, starting point is a FP4 with a locked bootloader:
- Enable OEM unlocking in the developer options,
get_unlock_abilitychanges to1 - Run
fastboot flashing unlockandfastboot flashing unlock_critical, still at1 - Install the factory images,
get_unlock_abilityis at1during installation, changes to0when we reach Android userland - (Run
fastboot flashing lock_critical) I would skip that part, checking thatfastboot flashing get_unlock_abilityreturns0should be enough for this test and is safer - Set up a Google account on the phone, which primes factory reset protection
- Our bootloader is still unlocked so we directly start the iodé installer, don’t lock the bootloader in the end and don’t let the installer finish, just stay on that prompt
- Open a terminal and check
get_unlock_abilitywhile the installer is still running, then finish the installation (without locking!) and check it again after first boot - Try enabling OEM unlocking and see if it crashes
- Optionally (in case it crashes) repeat the previous step while running
adb logcat -c && adb logcat *:E > logcat.txtand look for FRP in the output
The most interesting part is the value of get_unlock_ability in step 7. If my theory is correct then it should stay at 0.
If it’s 1 before the first iodé boot we have to look for a different cause for the reset, could be FRP getting triggered, I’m not sure.
I would run that test myself, I already have iodé on my FP4, but I don’t have the time to set up my phone again from scratch the next few days (realistically not before the end of the year tbh) 
1 Like
@rik Should I upgrade to 6.10? I saw it is available now through the built in (non beta) installer? Any risk in doing so?
I ran through the steps myself, and yes, the iodé installer, unlike the FPOS installer, doesn’t revert get_unlock_ability to 1 during installation, which is a problem.
No idea what part of the factory install script is responsible for that, it’s not fastboot flash frp frp_for_factory.img, that didn’t change anything when I ran it on its own.
So as far is a can see the two main issues iodé has to fix:
- Figure out a way to switch
get_unlock_abilityto1during installation, same as factory, so users can’t get stuck with a locked bootloader in case something goes wrong - Flash
FRPin the future, so there’s no Google account remaining on the phone and factory reset protection doesn’t prevent users from switching OEM unlocking to on again in the settings
I’m gonna go back to my own iodé install now, with factory images flashed before without reboot and get_unlock_ability checked, hopefully everything goes smoothly 
Edit: Back on locked iodé install that thankfully still boots 
3 Likes
Thanks for the testing and helpful summary of recommendations for the iodéOS installation process. I have added them (and credited you) on the issue report.
2 Likes
Did you read past my question? As in it was a tiny reply perhaps hidden by @anon73588713’s long post after.
The ota process is still backed by A/B partitioning, so if the install becomes unbootable it will fall back to the previous version after a certain number of tries.
But you also won’t gain anything, I ran the 6.10 ota through payload_dumper and there doesn’t appear to be a frp image in there.
Whatever solution the devs might come up with, I don’t think it’s in that release, sorry…
1 Like
Ah ok. Thanks.
Is there a way to use any of the Android platform tools or Android studio (from within an emulator) to download an .apk file for a program I want to install, by logging into my Google account using the platform tools (if that is possible) or in an emulated device?
To install apps on the phone you’d need a FRP bypass, which doesn’t look very promising right now, not sure any of them still work.
Android Studio will let you run apks and can support the Play Store, but depending on the app they might detect they’re not running on actual hardware and refuse to work.
If you’re on Linux you can try out Waydroid, I know people who use that to get banking apps on their PC, might work in WSL as well.
There are several other Android emulators out there I don’t have any experience with, if the iodé devs take long enough you might even be able to use Valve’s Lepton, when that gets released…
I’d start with Android Studio since it’s the official path and should have the best compatibility.