Erfahrungsbericht Pixel 4a – adb, fastboot, root und boot.img flashen

Seit meinem ersten Smartphone, einem Galaxy S I9000, bin ich bei Android geblieben. Und mit diesem ersten Smartphone kam auch das Interesse daran, mehr als nur Facebook zu nutzen. Zwar war das rooten bei Samsung damals noch verhältnismäßig einfach im Vergleich zu späteren Modellen. Mich zog es nach dem Galaxy dann direkt zu Google. So legte ich mir ein Nexus 4 zu. Seit dem bin ich bei den Google-Geräten geblieben. Die haben einfach den unschlagbaren Vorteil, dass man ohne große Verlustängste bezüglich Garantie den Bootloader freischalten und Custom-Kram installieren kann, bis der Arzt kommt. Das alles setzt natürlich voraus, sich in die Materie einzuarbeiten.

Nun bin ich seit einigen Tagen Besitzer eines Pixel 4a und kaum lag es auf dem Tisch, habe ich mich mit den Möglichkeiten von adb und fastboot näher auseinander gesetzt. Beim Nexus 4 und meinem Nexus 5X hab ich beim Rooten noch mit diversen Tools (Nexus Root Toolkit) gearbeitet. Das ist nur leider mit dem Start der Pixel-Reihe mit diesen wohl nicht kompatibel, weshalb ich mich nun mit dem Pixel 4a doch etwas näher damit beschäftigen musste, möchte mein Geräte entsprechend administrieren.

Ziel war, TWRP als custom recovery zu installieren, um Magisk und Xposed zu flashen. Seit Google diesen Mist namens SafteyNet eingeführt hat, hat sich bei den beiden letztgenannten Positionen auch etwas getan. Magisk ist systemless, was bedeutet, dass die Installation ohne Veränderungen an der Systempartition von Android auskommt. Die Veränderungen werden im boot.img vorgenommen und manipulieren quasi live beim Boot des Geräts. Das sorgt dafür, dass der SaftyNet-Status weiterhin als bestanden erhalten bleibt. Xposed wurde leider offiziell vom Entwickler schon vor geraumer Zeit eingestellt und wird scheinbar nur noch lose von einigen XDA-Mitgliedern hier und dort gepflegt. Das hat zur Folge, dass es keine offizielle Systemless Xposed-Version gibt. Der Entwickler von Magisk war allerdings so überaus eifrig und freundlich, für Magisk ein Xposed Modul zu erstellen, so dass man dieses verwenden kann.

Der übliche Weg, beide Tools in vollem Funktionsumfang nutzen zu können, setzte voraus, dass sie über ein custom recovery geflasht wurden. Bei Magisk gibt es zwar mittlerweile durch die Manipulation eines aus den Factoryimages extrahierbarem boot.img auch eine andere Möglichkeit, nur will die bei meinem Nexus Pixel nicht so recht funktionieren. Aufgrund eines Fehlers meinerseits hab ich mir direkt nach der Einrichtung aller neuen Spielerein von Google die Boot-Partition mit einem nicht passenden boot.img zerschossen. Folge: Bootloop. Nun ja, wer so lange schon mit derartigen Funktionen tüftelt, weiß, dass in dem Zustand noch was zu retten ist. Zugegeben, einen Schreckmoment hatte ich in dem Moment erst schon.

Das war dann auch der Moment, wo ich mir einer der wesentlichen Funktionen des Partitionssystems der Pixel-Geräte bewusst wurde, bzw. darüber erfuhr. Die Pixel verfügen über zwei Boot-Partitionen. Der Nutzer befindet sich in der aktiven Boot-Partition – slot genannt – und spielt die Updates im Hintergrund auf den inaktiven slot auf. Beim Neustart nach dem Update wird beim Bootvorgang auf die aktualisierte Boot-Partition gewechselt. Der Nutzer merkt davon nichts, weil seine persönlichen Daten und Apps nicht auf der Boot-Partition liegen und nicht von einem Systemupdate betroffen sind.

Der Vorteil der Geschichte:
Man hat quasi Dualboot. Geht bei einem Update etwas schief, wird einfach weiterhin die unbeschädigte Installation verwendet. Ich habe noch nicht recherchiert, was Google in dem Fall für eine Maßnahme in Android implementiert hat, was mit dem nicht bootbaren slot geschieht. Ich tippe jetzt einfach mal darauf, dass beim nächsten Updateversuch wieder dieser (inaktive) slot verwendet wird, oder irgendwie ein Rollback stattfindet. Jedenfalls sind die slots keine Eintagsfliegen.

Mir war es jedenfalls passiert, dass ich im Bootloader via fastboot flash boot magisk_patched.img ein nicht passendes img auf meine Boot-Partition geflasht hatte. Und zwar auf den aktiven slot, wie mir scheint. Genau sagen kann ich das nicht. Es gibt übrigens fastboot-Befehle, mit denen man explizit einen slot zum Flashen definieren kann. Egal welcher slot in dem Moment aktiv ist. Ich kam jedenfalls nach einer entsprechenden Meldung, mein System sei beschädigt, nicht mehr ins Android. Zu dem Zeitpunkt war mir nicht klar, welche Bedeutung die Anzeige des aktiven slots im Bootloader zu bedeuten hatte. Mein Pixel versuchte jedenfalls einige Male zu booten, was jedes Mal in dieser netten Fehlermeldung resultierte. Aus dem Bootloader sprang das Gerät automatisch sehr schnell dort hin. Von dort war über adb/fastboot nichts zu machen. Ich habe dann den richtigen Zeitpunkt abgepasst und konnte wieder in den Bootloader booten via adb. Anschließend habe ich versucht, das ungepatchte boot.img zu flashen. Offen gestanden habe ich keine Ahnung, welches img dabei auf welchem slot gelandet ist. Jedenfalls wollte auch hiernach Android nicht booten, weshalb ich dann kurzerhand das vollständige Factory Image von Google über deren Skript habe flashen lassen.

Seit dem bin dran, mich über die Funktionsweise der zwei Boot-Partitionen detailliert zu informieren. Die Recherchen dauern noch an. Denn wie ich erwähnte, ist mir noch nicht klar, was mit der fehlerhaften Boot-Partition passiert. Ich weiß bisher nur, dass jeweils ein Flag existiert, welches entweder eine funktionale oder defekte Boot-Partition markiert. Ob man das über fastboot resetten oder zumindest anzeigen lassen kann, wäre hilfreich.

Ach ja, in dem Zusammenhang habe ich auch das erste Mal etwas ausführlicher über adb mit Backups experimentiert. Bisher hab ich dazu mit TWRP für Vollbackups und mit Titanium Backup für vollständige App-Backups inkl. Benutzerdaten gearbeitet. Beim ersten Backup hab ich wohl nur die doofen Google-Apps gesichert, die Google klammheimlich für das ach so tolle Nutzerlebnis nachinstalliert. Jedenfalls konnte ich daraus meine selbst aus dem Play Store installierten Apps nicht wieder herstellen. Das war dann auch Anlass, zu recherchieren, welche Befehle es für adb generell gibt. Ich denke, dieser Thematik werde ich dann weitere Blogs widmen, um den Rahmen nicht zu sprengen. Kurze Berichte scheiben sich auch schneller, als lange Berichte.

Dazu werde ich noch etwas Recherche betreiben und dem Ganzen dann eine Struktur geben müssen. Denn irgendwie greifen meine Erkenntnisse da alle ineinander, dass ich das spontan nicht trennen könnte.

Daher belasse ich es auch erst einmal dabei und beende hier meinen ersten Erfahrungsbericht mit meinem Pixel 4a, Rootversuchen und Annährung an die adb.

Werbung