Nichts falsch gemacht. Nach Installation von FPOS und dem Booten ins System wird dieser Wert auf “0” gesetzt.
Vermeiden könnte man das nur dadurch, indem man nach der Installation nicht ins System, sondern direkt in den Fastboot-Modus bootet.
Beim (durch die Installation automatisch ausgeführten) Booten sofort die “Leiser”-Taste drücken und gedrückt halten, dann kommt man direkt zurück in den Fastboot-Modus (dann wäre direkt nach einer manuellen OS-Installation der Wert von get_unlock_ability noch “1”).
Ich gehe nicht davon aus, dass dies jemals durch ein Update passieren wird.
Für alle, die ggf. an einem ähnlichen Punkt sind und noch nach einer Lösung suchen:
@Thanos und ich haben intensiv versucht, get_unlock_ability auf “1” zu bekommen, um einen nicht riskanten Weg für das Sperren des Bootloaders gehen zu können.
Allerdings hat mein Vorschlag
auch nicht funktioniert, da die “kritischen Partitionen” noch gesperrt waren und damit der manuelle Installer nicht durchlaufen konnte:
PS C:\Fair> fastboot oem device-info
(bootloader) Verity mode: true
(bootloader) Device unlocked: true
(bootloader) Device critical unlocked: false
(bootloader) Charger screen enabled: true
So sind wir am Ende mit Mut den etwas riskanten, aber schließlich erfolgreichen Weg gegangen, den Bootloader trotz “unlock_ability 0” zu sperren:
zuerst abgewartet, bis es ein aktuelles Update mit neuerem Security Patch Level gab und dieses per OTA update installiert und danach den Bootloader per fastboot flashing lock` gesperrt.
Da es sich somit um kein Downgrade handelte sah die “rollback protection” kein Problem und das Gerät hat problemlos gebootet. Mit gesperrtem Bootloader läuft jetzt auch die oben genannte AXA App wieder problemlos und der Schalter für die “OEM-Entsperrung” in den Entwickleroptionen ist wieder nutzbar.
