Kann ich den Bootloader wieder gefahrlos schließen?

[sterum]

Hallo zusammen,

Nachdem ich nun mein neues 6mq erhalten habe wollte ich als erstes auf OS-L wechseln. Das Telefon wurde mit OS-G 3.7 geliefert, da die OS-L 3.7 aber älter ist konnte ich dies nicht über die OTA App machen. Der Versuch die

SHIFT6MQ.SOS.3.3.G.20210726-RELEASE-DOWNGRADE_WIPE_OTA.zip

über die OTA App zu installieren schlug ebenso fehl wie über das Recovery (sowohl adb sideload als auch die Installation von SD-Karte).
Ich hab dann beschlossen das Lineage Recovery zu installieren und die Installation von OS-L 3.7 damit zu machen. Das hat auch wunderbar geklappt. Dazu musste aber natürlich der Bootloader entsperrt werden. Um wieder das Stock Recovery zu bekommen hab ich dann die Datei recovery-SHIFT6MQ.SOS.3.3.G.20210726-RELEASE.img nach recovery A und B geflasht, was auch funktioniert hat.
Und jetzt zu meiner eigentlichen Frage: Kann ich nun den Bootloader wieder gefahrlos schließen? Mit

fastboot flashing lock

 

[@Lhotze]

Wenn auf beiden Slots (A und B) in der Super-Partition ShiftOS installiert ist und die Bootloader/ Recovery's in beiden Slots zu den entsprechenden Installationen der Super-Partition passen, dann ja. Wenn auf einer Partition noch ShiftOS-Light und auf der anderen ShiftOS-Google drauf ist, aber auf beiden Recovery-Partitionen das Recovery von ShiftOS-Google, möglicherweise noch in einer anderen Version als das des Light-Builds drauf ist, würde ich es nicht riskieren. Ich weiß nicht, ob diese Konstellation den dm/avb check besteht.

Bsp.: Das Recovery in Slot A wird nach öffnen des BL ersetzt. System ist nicht mehr verifiziert und das System startet nach schließen des Bootloaders nicht mehr. Auf Slot B (alle Partitionen inklusiv Boot und Recovery) wird nun über das neue Recovery ShiftOS installiert. Das System ist weiterhin (wegen Recovery A) nicht verifiziert und startet bei BL schließen nicht mehr.
Jetzt wird nach einem Neustart der Slot auf B gewechselt. Im (Shift) Recovery wird über ADB Sideload jetzt erneut ein Shift-Image installiert. Das ersetzt alle relevanten Partitionen auf A inklusive Boot und Recovery. Jetzt ist auf allen Partitionen Shift-Firmware drauf, Boot, Recovery und System passen zueinander. Systemverifizierung wird bestanden, nach schließen des BL startet das System wie gewohnt.

Fun Fact: Das geht auch mit ShiftOS-Light und ShiftOS-Google in jeweils einem Slot wenn deren Integrität stimmt, da beide Firmwares verifiziert sind.

Leider ist mir kein Weg bekannt, vor dem schließen zu überprüfen, ob vollständige Integrität gegeben ist.

Aber nach zweimaligem Flashen mit einem zwingenden Recovery-Neustart zum Slotwechsel dazwischen und wenn für den zweiten Flashvorgang das vorhandene Recovery genutzt wurde und nicht extra eines neu installiert wurde, dann sollte das LineageOS-Recovery save überschrieben worden sein und die Integrität passen.

Greetz

 

[sterum]

Könnte man in etwa so vorgehen?

fastboot flash recovery_a recovery-Lineage.img
fastboot flash recovery_b recovery-Lineage.img

In das Lineage Recovery wechseln und von dort aus Shift OS-L installieren
Dann den aktiven Slot wechseln

fastboot set_active B

Neu starten
Dann wieder In das Lineage Recovery wechseln und von dort aus nochmals Shift OS-L installieren
Den aktiven Slot eventuell wieder auf A zurück wechseln

fastboot set_active A

Dann Das Shift Recovery in beide Slots installieren

fastboot flash recovery_a recovery-SHIFT.img
fastboot flash recovery_b recovery-SHIFT.img

Wenn auf einer Partition noch ShiftOS-Light und auf der anderen ShiftOS-Google drauf ist, aber auf beiden Recovery-Partitionen das Recovery von ShiftOS-Google, möglicherweise noch in einer anderen Version als das des Light-Builds drauf ist, würde ich es nicht riskieren.

Heißt das, für Shift OS-L brauche ich ein anderes recovery.img als für OS-G und die Versionen müssen auch zusammenpassen? Wenn ja, wo bekomme ich das Recovery für OS-L.

Danke

 

[@Lhotze]

Wie wäre es mit:

fastboot boot LineageOS-Recovery.img

Bootet direkt in das Recovery ohne zu installieren. Flash hier die ShiftOS.Zip.
Gerät aus. Start in den Bootloader und dann von vorne.

Zum Schluss hast du auf beiden Partitionen das identische ShiftOS und das Recovery wurde by the way in beiden Slots angeglichen ohne das ein anderes Recovery installiert werden musste.

Greetz

 

[sterum]

Also wird das richtige Recovery beim Installieren der Shift-OS.zip mitinstalliert?

 

[@Lhotze]

Im (Shift) Recovery wird über ADB Sideload jetzt erneut ein Shift-Image installiert. Das ersetzt alle relevanten Partitionen auf A inklusive Boot und Recovery. Jetzt ist auf allen Partitionen Shift-Firmware drauf, Boot, Recovery und System passen zueinander.

That's what i said...

 

[sterum]

Das mit den Slot A B Geräten muss ich mir noch mal genauer ansehen ...

Wenn also Slot A aktiv ist werden beim lnstallieren der zip's über das Recovery die Partitionen in Slot B überschrieben, und umgekehrt wenn Slot B aktiv ist die Partitionen in Slot A?

Danke.

 

[@Lhotze]

Genau so ist es. Ist ein sehr praktischer Mechanismus, wenn mal ein Update schief läuft.

Es ist immer der gleiche Slot aktiv, Updates werden in den inaktiven Slot installiert und nach einem Neustart der Slot gewechselt. Wenn das Update schief geht, wechselt der Slot zurück und man kann das Update erneut versuchen.

Musste ich aber auch erst alles mit dem 6mq lernen. Hatte davor auch nur One-Slot-Devices.

Greetz

 

[Uli]

Frage: Wenn das Lineage recovery mehr Möglichkeiten bietet, könnte man es ja in beiden Slots beibehalten, SOS-L, installieren und den Bootloader dann wieder schließen? Wenn man das will. Ich selbst will root haben deshalb bleibt der schön offen

 

[@Lhotze]

Frage: Wenn das Lineage recovery mehr Möglichkeiten bietet, könnte man es ja in beiden Slots beibehalten, SOS-L, installieren und den Bootloader dann wieder schließen?

Kannst du machen, wenn der Bootloader offen bleibt. Sobald aber etwas an der Integrität einer zertifizierten Firmware geändert wurde (da zählt ein anderes Recovery oder Boot-Image dazu), dann wird der dm-verity /AVB-Check nicht mehr bestanden und bei geschlossenem Bootloader startet das System nicht mehr. Sogar dann, wenn es der inaktive Slot ist.

Dann kann ich über Fastboot nichts mehr ändern und da das System nicht mehr startet, kann ich den Bootloader auch nicht mehr entsperren.
Im besten Fall kann die ursprüngliche Integrität über Neuinstallation im Recovery wiederhergestellt werden. Im schlimmsten Fall ist das Gerät gebrickt.

Root verändert übrigens auch das Boot-Image und dessen Signatur. Auch hier würde das System bei Bootloader-Schließen nicht mehr funktionieren. Ob die "keep dm-verity" Option bei Magisk funktioniert will ich nicht testen .

Greetz

 

[Uli]

Vielen dank für deine super wertvollen Erklärungen

 

[sterum]

Ich habe nun den Bootloader geschlossen. Hier noch einmal eine kurze Zusammenfassung.

Ausgangslage war ein geöffneter Bootloader mit einem installiertem Lineage Recovery und SHIFT OS-L jeweils in beiden Slots.

ACHTUNG! Alle folgenden Angaben ohne Gewähr!

1. Das Gerät im fastboot Modus starten
2. Feststellen welche Slot gerade aktiv ist

fastboot getvar current-slot

Diesn Slot merken oder notieren
3. In ein SHIFT OS-L recovery booten

fastboot boot Shift6mq_ShiftOS-L_Recovery_initial_release.img

4. Vom Recovery aus SHIFT OS-L per adb sideload installieren

adb sideload 3.7.L.20220511-RELEASE-LIGHT-OTA.zip

Wenn z.B. der aktive Slot a ist wird SHIFT OS-L ind den Slot b installiert, ebenso wird das passende SHIFT Recovery in den Slot b installiert.
5. Das Gerät wieder in den fastboot Modus starten und feststellen welcher Slot aktiv ist

fastboot getvar current-slot

Falls noch der gleiche Slot wie oben aktiv ist den Slot wechseln. Entweder a oder b je nachdem

fastboot set_active [a|b]

6. Dann in das Recovery starten. Hier sollte dann die soeben installierte Version angezeigt werden. Dann kann mit adb sideload in den anderen Slot installiert werden.

adb sideload 3.7.L.20220511-RELEASE-LIGHT-OTA.zip

Damit wird SHIFT OS-L und das passende Recovery in den zweiten Slot installiert.
6. Nun kann das Gerät neu gestartet werden. Dann in den Systemeinstellungen die installierte Version kontrollieren. Diese muss mit der Vorher kontrollierten Version des Recovery übereinstimmen. Wenn ja das Gerät wieder in den fastboot Modus starten und den aktiven Slot wechseln.

fastboot set_active [a|b]

7. Nun wieder in das Recovery wechseln und die Version kontrollieren. Danach kann gleich wieder SHIFT OS-L gestartet werden. Hier nun auch in den Systemeinstellungen die installierte Version kontrollieren.
8. Nachdem man sichergestellt hat das in BEIDEN Slots sowohl das Recovery als auch das installierte SHIFT OS-L die gleiche Version haben kann der Bootloader wieder geschlossen werden.

fastboot flashing lock

9. Nach einem Neustart kann in den Systemeinstellungen die OEM Entsperrung wieder abgeschaltet werden. Danach muss das Gerät nochmals neu gestartet werden.

 

[Punk9216]

Blöde Frage... mein Shift6mq wird von Win11 nicht mehr gefunden... hab verschiedene MTP Treiber ausprobiert aber krieg das grad nicht mehr zum Laufen...
Will den Bootloader schließen mit fastboot flashing lock aber er findet kein device...

Nachdem man sichergestellt hat das in BEIDEN Slots sowohl das Recovery als auch das installierte SHIFT OS-L die gleiche Version haben kann der Bootloader wieder geschlossen werden.

fastboot flashing lock

9. Nach einem Neustart kann in den Systemeinstellungen die OEM Entsperrung wieder abgeschaltet werden. Danach muss das Gerät nochmals neu gestartet werden.

irgendeine Idee?

 

[danielp]

@Punk9216 das heißt du hast dein Problem hier gelöst? Wäre schön zu erfahren wie?

Blöde Frage... mein Shift6mq wird von Win11 nicht mehr gefunden... hab verschiedene MTP Treiber ausprobiert aber krieg das grad nicht mehr zum Laufen...

Nicht mehr gefunden heißt es ging vorher? Oder hast du es bis jetzt nur noch nicht ausprobiert?
Hast du schon ein anderes Kabel probiert?

 

[Punk9216]

Nur kurz Off-Topic wegen deiner Frage bezüglich der "Lösung" (ich nenns einfach mal so, auch wenn ich nicht weiß, ob das vielleicht nicht so klug war... Hab jetzt halt einen offenen Bootloader)
Hab den UBPorts Installer auf meiner Ubuntu Partition gestartet und da schien das problemlos zu verlaufen im Vergleich zu meinem Versuch auf Win11.
Kann damit zwischen OS-L und G hin- und herwechseln, habe aber noch einen offenen Bootloader, den ich laut der Anzeige nach erfolgreicher Installation mit UBPorts wohl auch noch nicht schließen soll, da das noch nicht implementiert sei. Meine Frage oben hat sich also vermutlich erstmal erledigt.
(Ist der offene Bootloader eigentlich ein Problem? Kenne mich da nicht wirklich aus und konnte auch nicht so viel im Internet dazu finden... Nutze momentan eh noch mein altes Handy, da mein Shift6mq ne Zeit lang in Reparatur war)

 

[@Lhotze]

Bootloader schließen nach UB-Port Installation ist deswegen ne schlechte Idee, weil der Installer sein eigenes Recovery mitbringt, was nach Installation in der inaktiven Partition ist und die Systemintegrität stört.

Ich wiederhole mich zuweilen, aber der ungefährlichste und imho leichteste Weg ist derzeit, wenn das downgrade-paket nicht funktionieren sollte:

1.) Bootloader mit fastboot öffnen
2.) in bootloader booten
3.) mit

fastboot boot pfad/zu/Recovery.img

das aktuelle LineageOS-Recovery booten ohne es zu installieren.
4.) Im Recovery entweder von SD oder per ADB das gewünschte Shift-OS firmware-Zip installieren (kein OTA sondern das komplette System. Ist so zwischen 700mb und 1,3Gb groß, je nach Version.
5.) nach Installation wieder in den Bootloader booten.
6.) mit

fastboot boot pfad/zu/Recovery.img

das aktuelle LineageOS-Recovery booten ohne es zu installieren.
7.) Im Recovery entweder von SD oder per ADB das gewünschte Shift-OS firmware-Zip installieren (kein OTA sondern das komplette System. Ist so zwischen 700mb und 1,3Gb groß, je nach Version.
8.) In den Bootloader booten und diesen schließen.

UB-Installer verspricht anfangs automatisierten comfort. Danach muss man aber wieder mit fastboot ran. Da besteht meiner Meinung nach eine zu große Gefahr durcheinander zu kommen und was zu übersehen.

Ist der offene Bootloader eigentlich ein Problem?

Das System läuft und mir wäre bisher keine App bekannt, die deswegen Probleme macht. Das System ist anpassbarer, da wild die Partitionen manipuliert werden können, bsp root oder ein anderer Kernel mit anderen Funktionen (Undervolting etc)

Das ist aber auch Sicherheitskritisch relevant.
Bsp.: Die Nutzerdaten sind verschlüsselt. In Version 1 des Betriebssystems gab es einen Bug, der Zugang zu den Nutzerdaten ermöglicht. Mit Version 2 wurde der Bug behoben. Das System ist auf Version 4.
Jemand bekommt das Smartphone (ohne Sperrpin) in die Hände. Mit offenem Bootloader könnte nun ohne Probleme auf Version 1 gedowngradet werden um den Bug auszunutzen.
Oder es könnten manipulierte Dateien, bspw ein anderer Kernel installiert werden, mit dem Schwachstellen ausgenutzt werden können.
Bei einem gesperrten Bootloader müsste dieser erst dafür entsperrt werden.
Im System müsste die OEM-Entsperrung aktiviert werden und danach noch mit fastboot den Bootloader öffnen. Das löscht automatisch alle Nutzerdaten, damit sind die also "sicher".

Ein geschlossener Bootloader schützt also nicht vor Verlust (ein Full-Wipe) kann ja jederzeit über das Recovery ausgeführt werden, und die Google-Gerätesperre lässt sich auch vergleichsweise leicht umgehen), aber er schützt die persönlichen Daten.

Greetz

 

[Punk9216]

Okay danke für die Infos!

Verstehe ich das aber richtig, dass jemand ohne meinen PIN auf kritische Dinge zugreifen könnte, aber zumindest physischen Zugriff dafür braucht?

 

[@Lhotze]

Verstehe ich das aber richtig, dass jemand ohne meinen PIN auf kritische Dinge zugreifen könnte, aber zumindest physischen Zugriff dafür braucht?

Im Falle eines offenen Bootloaders theoretisch schon. Denke aber da gehört auch einiges an Knowhow und Aufwand dazu. Darüber müsste man sich meines Erachtens nur Sorgen machen wenn man Pablo Escobar oder Paranoid ist.
Immerhin muss so eine Schwachstelle im System erstmal bekannt sein, und nur mit einer Veränderung des Systems oder des Kernel bekäme man die Verschlüsselung wahrscheinlich auch nicht geknackt um hier mal einen der Shift-Developer zu einem neulich erst erwähnten Post zum Thema "trusted environment" und somit der Verschlüsselung zu zitieren.

Greetz

 

[Punk9216]

Dann kann ich ja relativ bedenkenlos doch wieder komplett auf mein Shift switchen!
Danke dir!

 

[fliegerjohn]

Funktioniert es auch den Bootloader wieder zu schließen, wenn ich Lineageos installiert habe?

Ich habe per "flashrom flash recovery_a" und "recovery_b" das Recovery von Lineageos in Beide Slots gespielt und auch das System zweimal, jeweils in Slot a und b installiert.
Somit müsste ja die Vorraussetzung die selbe sein, wie wenn ich ShiftOS mit passendem Recovery installiere!?

 

[amartinz]

Funktioniert es auch den Bootloader wieder zu schließen, wenn ich Lineageos installiert habe?

Ich habe per "flashrom flash recovery_a" und "recovery_b" das Recovery von Lineageos in Beide Slots gespielt und auch das System zweimal, jeweils in Slot a und b installiert.
Somit müsste ja die Vorraussetzung die selbe sein, wie wenn ich ShiftOS mit passendem Recovery installiere!?

Dazu müsstest du den AVB Public Key von Lineage bekommen und diesen dann als Custom Key flashen.

Das ist (soweit ich weiß) noch nicht möglich, da Lineage den Key nicht bereitstellt und dazu Änderungen in der Infrastruktur notwendig wären.
Aber ich hab schonmal ein Gespräch dazu mit paar Leuten angestoßen.

 

[Punk9216]

Heyho zusammen, da ja nun etwas Zeit vergangen ist wollte ich zum UBPorts-Installer und dem offenen Bootloader nochmal nach dem neuesten Stand fragen.

Hintergrund:
Ich habe vor etwa einem halben Jahr mit dem UBPorts-Installer auf Shift-OS-L gewechselt zum Testen und wieder zurück (war vielleicht nicht die beste Idee aber hat ja irgendwie geklappt im Gegensatz zu meinen anderen Versuchen ). Am Ende der Installation mit dem Installer kam dann die Nachricht, dass alles soweit erfolgreich war aber ich den Bootloader noch nicht schließen soll, da das noch nicht implementiert wurde.

Frage:
Wurde das mittlerweile implementiert und kann man damit die Versionen wechseln + Bootloader dann wieder schließen?
Falls nicht, ist eine Implementierung noch geplant?

LG Tobias

 

[NoG....eFan]

.

 

[peterparker]

Hallo,
ich verstehe die Terminologie hier noch nicht besonders gut und benötige Hilfe um den Bootloader schließen zu können.
Ich habe ein Shift6mq, welches damals mit der Google-Version des ShiftOS ausgeliefert wurde. Ich habe vor Jahren dann ShiftOS-L installiert, dafür den Bootloader geöffnet und heute dann das Upgrade (samt Factory-Reset und nun nicht funktionierendem adb restore, seufz....) von Android10 auf Android15 a.k.a ShiftOS-L 7 gemacht (Edit: Danke für den Hinweis zu den Versionen Dwain Zwerg!)
Kann ich den Bootloader schließen oder welche Schritte müsste ich vorab machen?
Danke für alle Tipps!

 

[Dwain Zwerg]

@peterparker Android 15 = OS-l 7.0; Android 13 = OS-l 5.x

 

[@Lhotze]

Kann ich den Bootloader schließen oder welche Schritte müsste ich vorab machen?

Zur Kurzerklärung:

Wenn im System alles zueinander stimmt (überwiegend boot.img, recovery.img und system mit gleichem Signierungsschlüssel) und das auf beiden Partitionen so ist, dann kann ein offener Bootloader wieder geschlossen werden.

Mit jeder Softwareaktualisierung (des Herstellerroma) wird auf der zu diesem Zeitpunkt nicht genutzten Partitionen die komplette Integrität wiederhergestellt.

Wenn du also seit dem öffnen des Bootloaders mehrere Software-Updates hinter dir hast und hierbei jedesmal der Slot gewechselt wurde und du auch seitdem keine Anpassungen am System (wie das manuelle flashen eines Images) mehr vorgenommen hast (dazu gehört auch die Verwendung des UB-Port installers), dann sollte der Bootloader gefahrlos zu schließen sein (du verlierst dabei alle Daten).

Wenn du auf Nummer sicher gehen willst, stoße noch zwei Mal das aktuelle Betriebssystemupdate aus dem Recovery oder der Update-App an, so dass beide Slots noch mal komplett neu ünerschrieben werden.

Greetz

 

[Dwain Zwerg]

In der Update-App, indem du das OTA zweimal manuell einspielst.

 

[Oliver500]

Hallo zusammen,

Spoiler: Die lange Vorrede 😊

Ich bin mit den ganzen Hintergründen was Systeme, Bootloader, rooten etc. auf Smartphones angeht nicht im Detail vertraut, habe aber damals mein Shift6mq nach Hilfestellung in diesem Forum erfolgreich gerootet, es aber beim ShiftOS-G belassen, später dann nach lokal über die OTA-App installierten Updates immer wieder mittels Magisk vor dem Neustart das Root wiederhergestellt, um es "nicht zu verlieren" (ich sag's mal so laienhaft, da ich mich da eher als Laie sehe, da ich nicht besonders tief im Thema drin bin). Jetzt mal eine Rückfrage zu den in diesem Thread beschriebenen Informationen in Verbindung hierzu:

Wenn ich es richtig verstanden habe, kann niemals ein Bootloader wieder geschlossen werden, wenn dieser (die boot.img?) nachträglich gerootet wurde - also in der Auslieferung kein Root hatte, ganz egal um welches Android-Betriebssystem es sich handelt. Ist das richtig? Wieder geschlossen werden könnte er inklusive Root nur dann, wenn Root schon bei der Auslieferung des Systems vorhanden war. Korrekt?

Wenn dem so ist, und vor dem Hintergrund, dass ich überlege, mir ein Shiftphone 8 zuzulegen, und dieses auch wieder gerootet werden soll, dann mal folgende Frage: Welchen Weg sollte man da eher gehen - besonders im Hinblick dessen, dass ich in diesem Bereich wirklich gefühlt nur an der Oberfläche kratze und die Informationen, die ich habe, mehr oder weniger ausschließlich aus diesem Forum stammen (habe übrigens auch schon stundenlang andere Threads in diesem Forum "durchgearbeitet", dabei aber vieles mangels Hintergrundwissens nicht verstanden): Sollte man ein ShiftOS-G (oder -L) nehmen, dies rooten und den Bootloader einfach offen lassen, oder sollte man ein anderes System installieren, was Root gleich mitbringt, und wo dann den Bootloader (vermutlich durch einen selbst?) wieder geschlossen wird? (Die Experten würden sich wohl eher für letzteren Schritt entscheiden, aber die Frage wäre, ist es auch für jemanden auf einem geringeren "Kenntnis-Level" mit verhältnismäßigem Aufwand machbar, "einfach" ein anderes System zu installieren, ohne dafür das Thema studiert haben zu müssen). Ich würde mich ja fast (wieder) dafür entscheiden, eher das vorinstallierte ShiftOS-G zu belassen, es zu rooten und mit offenem Bootloader zu nutzen. Schon allein deshalb, weil ich da schon so in etwa weiß, wie ich dann mal ein Update installieren muss, worauf ich zu achten habe, und wie ich Root und vor allem meine Daten behalte. Und nichts wäre schlimmer, als zum Schluss mit einem Smartphone da zu stehen, was zwar das gewünschte System hat, aber gebrickt ist.

Übrigens an dieser Stelle einmal mehr wirklich meinen ausdrücklichen Dank an @Lhotze. Deine Beiträge und Informationen in diesem Forum waren für mich immer wieder von extrem großem Wert, an zahlreichen Stellen. Vielen herzlichen Dank dafür! Du hattest in dem Thread https://forum.shiftphones.com/threads/custom-rom-recovery-root-und-co-furs-shiftphone-8.5424 auch von einer Methode berichtet, den Fingerabdrucksensor ohne ein zusätzliches Tool (Hardware) wieder zu kalibrieren, nachdem der Bootloader geöffnet wurde. Was ich nicht ganz verstanden habe: Sprichst du ausschließlich von dieser Methode (https://xdaforums.com/t/guide-for-calibration-finger-print-after-loss-data-calibration.4132961/) und funktioniert sie mit Sicherheit? Oder ist es eher eine Methode, bei der der Erfolg nicht garantiert ist? Hattest du ein Hardware-Tool verwendet (https://fixshop.at/werkzeuge-mess-und-prufgerate-1/relife-rl-071b-fingerabdruck-kalibriergera/), oder eine bzw. diese Software-Methode? Denn den Fingerabdrucksensor bräuchte ich letztendlich auf jeden Fall auch wieder.

Sorry für diesen Roman, aber für mich sind da noch viele offene Fragen, und man möchte ja möglichst gleich am Anfang alles richtig machen, anstatt hinterher dumm auf's Display zu gucken.

 

[@Lhotze]

Moin Olli,

ich versuche knapp und übersichtlich auf gewohnt hohem Niveau zu antworten (vielen Dank für das Lob )

1. Out-of the Box wirst du den Bootloader eines nachträglich gerooteten Android nicht schließen können ohne Probleme zu bekommen. Das Rooten ändert die Signatur des Boot Image. Der Bootloader prüft diese Signatur und vergleicht sie mit dem Rest des Betriebssystems. Wenn es nicht passt, dann basta...

Aber:

Wenn du die Expertise hast, kannst du dir selbst ein System kompilieren in dem das Bootimage bereits gerootet ist. Da kann man dann die entsprechende Signatur in den Check aufnehmen. Dann würde es klappen. Dann müsste aber für jedes Betriebssystem Update und jedes Update des Bootimage (bspw. durch eine höhere Version Magisk/Apatch/KSU) eine neue Version deines Betriebssystems kompilieren / signieren, da sich dadurch ja auch die Signatur ändert.

2. Ich habe mal ne sportliche Nachtschicht darauf verwendet den Sensor zu kalibrieren. Mit unterschiedlichen "Hilfsmitteln" wie Einweghandschuhen, schwarzem Stoff etc... mit teils unterschiedlichen Ergebnissen.
Da die einzelnen Helligkeitswerte scheinbar miteinander abgeglichen werden und demnach exalt zueinander passen müssen habe ich es mal nur bis zum ersten Schritt, mal bis zum letzten aber nie erfolgreich abgeschlossen.

Ich bin überzeugt, mit den richtigen Gegenständen und Zeitansätzen kann man den Sensor tatsächlich bis zum Ende des Abschlusses kalibrieren. Da ist aber jeder Versuch ein Schuss ins Blaue ob es auch bis zum Ende durchläuft.

Nach 6 Stunden hatte ich auch keine Lust mehr und hab mir den Kalibrator geholt, mit dem es auf Anhieb funktionierte. Ich musste bei ShiftOS-L allerdings noch die entsprechenden App hinzugefügen, da dich nicht von Anfang an enthalten war.

Greetz

 

[Dwain Zwerg]

und dieses auch wieder gerootet werden soll

Wofür brauchst du denn Root?

• Mittlerweile gibt es ungerootete CustomOS, die Firewall-Apps mitbringen, die auf ungerooteten Betriebssystemen laufen und nicht die VPN-Verbindung ausnutzen: iodéOS (kostenpflichtiges Abo oder Einmalkauf; umfangreich) & /⁠e⁠/⁠OS (kostenlos).
• Mittlerweile gibt es mit Seedvault ein ADB-Backup basiertes Backup-Tool, das auf allen CustomOS (inklusive ShiftOS-l) interoperabel läuft und viele Apps sichern kann (Banking-Apps gehören natürlich nicht dazu).

Root bringt ja viele Probleme mit, sodass eine Vielzahl von Apps nur wiederwillig laufen.

Wenn du die Expertise hast, kannst du dir selbst ein System kompilieren in dem das Bootimage bereits gerootet ist.

Oder du nutzt AXP OS Pro. Das einzige CustomOS, dass es für das SHIFTphone 8 geben soll, bei dem das Bootimage bereits gerrotet ist (somit kann man den Bootloader nach dem Flash schließen). Leider dauert es mit AXP OS Pro bestimmt noch ein Jahr.