No I can install .apk files.
Right, sorry, I completely forgot (this issue has been going for so long…). I had considered adb but thought that surely should be blocked by FRP, interesting 
Ah, your problem is you want to download the apks to then install on the phone, completely misunderstood your question.
You mentioned in the other topic you can install apps from F-Droid, and that you checked that Aurora Store has the “Install unknown apps” permission set, so does installing apps from Aurora Store work?
Even if installing doesn’t work, you can get the apk that way. After you pressed the install button in Aurora store and the download completed, switch to the Updates tab and press the downloads icon in the top bar 
, long press the app and select “Save app bundle”, that’ll give you a .zip file with the apks.
1 Like
Awesome, thanks! That worked.
For anyone reading, the process thus is:
- Do the above to obtain the .apk
- Transfer file to laptop (e.g. using LocalSend)
- Have platform tools (
winget install Google.PlatformTools) installed (or use portable version) - Extract the .zip file (e.g.
Extract-Archive org.example.MyApp.zipin powershell) cdto that folder (org.example.MyApp)- Run
adb install base.apkwith phone connected via cable and USB debugging enabled in developer options
1 Like
@Wallby that is correct, there is no progress to report from the devs. The last word from them is that they will certainly be looking at following @anon73588713 ‘s advice to prevent the issue from occurring for new installs, but that they aren’t very confident that there is anything they can do with a device that has already triggered FRP to reset it. Without adb root (which isn’t possible in iodéOS) it does seem difficult. But I am not a developer so can’t speak too confidently.
1 Like
Thanks to all comments here. I’ll look more in details in the coming days and try to improve the installation procedure for the next release.
2 Likes
Well if they do find a way, that would be great. I am able to update just fine, I am on 6.10 now whereas I installed 6.9 initially. Still can’t set up a pin and thus not use fingerprint auth which gets annoying when using a password manager/2FA app as I have to type my password every time to get into the app.
From @vince31fr in our team chat, I think we understand now how the Fairphone devices ended up as unfortunate bricks (worst case if SPL also triggered) or as having FRP lock unable to be removed (as is the case for @Wallby ):
The only interest of flashing FPOS was to reset FRP, which removes Google account blocking. But, it switches off OEM unlocking, which may lead to a brick because of SPL.
With that insight, I think here are the steps that led to some users with hard-bricked devices:
-
User has a Google account registered under their prior ROM.
-
User flashes iodéOS… FRP is triggered (but as iodéOS doesn’t reset
get_unlock_abilityit is at1still so is able to reflash still). -
User is advised to reflash stock FPOS to reset FRP but they do not relock the bootloader at the end since they are planning to then reflash iodéOS again. The FPOS install resets
FRPbut also setsget_unlock_ability 0. Now phone is unlocked and FRP is reset but not able to be unlocked again (if later locked). In addition theSPLof the FPOS install is newer than the iodéOS version. -
User flashes iodéOS and re-locks bootloader. SPL triggers “rollback protection”: hard brick
since it won’t boot and get_unlock_ability 0.
Vincent has now made updates to the manual flash-all.sh install process, and will get to the installer in the next release:
So now, FRP will be reset from Pixel 5, up to Pixel 9, as well as FP4 to FP6. Only SPL problems should remain on them, but no more OEM unlocking disabled by FPOS
Rather than flashing factory FRP that sets get_unlock_ability 0 we are instead flashing a FRP that has get_unlock_ability 1. This means that going forward, iodéOS installs will “Allow OEM Unlocking”. User would then have to turn that off manually from Developer Options if they don’t want that disabled.
Now, to the problem of @wallby: They have FRP triggered, bootloader is locked, and have get_unlock_ability 0 due to the manual running of the lock_critical command. So they have a working locked phone but it is unable to be unlocked since FRP is triggered.
Question along with a slight hope: can you re-register your Google Account under microG using “System Settings > System > microG”? Maybe maybe this will disable the FRP lock? Please do try, we are not sure if it is possible with microG to get FRP unlocked or if it needs a ROM with full “Google Play Services”. I am sure you need some “New Year’s cheer” with your situation, hoping for this to work!
3 Likes
Awesome to hear that progress has been made about the issue.
I tried the steps. After removing and then adding the account, I tried setting up a pin (for the lock screen) first, that didn’t work with the same old error “already set up”, even though it isn’t. I then tried to do the OEM unlocking for double checking, and indeed the same issue happened. Toggle on, pop up with I think “are you sure” or something, and then on pressing yes it goes back one menu, then going back into the developer options and scrolling down the OEM unlocking option is back at what it was before selecting yes (still no). Dunno if any of that is redundant detail, but eh.
Anyway, good job on the fixes guys!
I found an even nicer way to install complex applications (multiple .apk files) in Windows:
$a = dir | Select -ExpandProperty Nameadb install-multiple $a
Dear @rik, since you became more active in the iodé forum last year, the quality and, in particular, the feedback on questions from iodéOS friends has improved significantly.
I would like to thank you very much for this, because iodéOS is also very important to me and is an excellent product. An excellent iodéOS CustomROM and CustomGSI deserve good marketing and user-friendly communication. Thank you very much—may it continue like this in the new year 2026, please.
4 Likes
Have only been a iodé user and forum member for less than half a year, but absolutely endorse this!
1 Like
I assume this means that it is also not able to be changed still
I think we have exhausted what we can do on this side. I recall earlier you indicated you had a return label ready to ship it back to Fairphone: I think that is what will need to be done to get it “un FRP’d”. As noted, thanks to the work from the devs this problem should not cause issues for future installs but sorry you had to find out the very hard way about the issue.
1 Like
@iodysseus and @MissPiggy thank you for the encouragement, I am also grateful for both of your contributions, they all are part of the whole. Increasing our “bus factor” on this forum (“how many contributors have to be run over by a bus before the whole thing is unrecoverable”) is a priority I saw when joining the community, and I am glad to see we have made a lot of progress this year.
We of course remain very small and are wading against the tides of huge corporations and a complicated and daunting code base that no single person can master, so things will come up that will set us back. If we can make sure to be a welcoming place and grow the community it will in turn incrementally reduce the strain on any single point of failure.
Thank you for getting this fixed (at least for future installs) 
Since I can’t help here anymore could you please anonymize my account, I don’t really have the time for multiple forums, I get nerdsniped too easily 
1 Like
Sorry to see you go. Just passing back the community’s thanks for your help and insights into the problem. After I send this message, I will anonymize your account, wish you the best of luck!