LineageOS mal wieder - nach langer Zeit

Lange Zeit war es still um die Installation von Custom ROMs auf meinen Handys ... jetzt hatte ich mal wieder Lust und Gelegenheit und ein abgelegtes Handy, für das es ein offizielles LineageOS-ROM gibt.

Vor langer Zeit war Motorola mal im Besitz von Google, und aus dieser Zeit resultieren immer noch einige erfreuliche Leistungen und Features, die die Handys von Motorola auszeichnen. Zugegeben, die Update-Politik könnte besser sein. Ob das mit dem späteren Verkauf an Lenovo zusammenhängt und Lenovo dadurch sparen will, ist schwer zu sagen. Die Geräte bekommen derzeit im Schnitt nur alle zwei Monate ein Update und nicht jeden Monat pünktlich am 5. wie die Google-Pixel-Modelle. Mein letztes Update ist das vom Juli, und ich erwarte das September-Update so ungefähr zu meinem Geburtstag :-)

Trotzdem gefallen mir die Modelle von Motorola ziemlich gut - ich habe mich auf die Mittelklasse eingeschossen, die "G"-Modelle (ich liebäugele aber durchaus als nächstes mit einem Edge 30 Ultra ...). Derzeit verwende ich ein "G200 5G" (auch wenn es in Berstadt derzeit noch kein 5G gibt), das es bei Amazon als B-Ware-Schnäppchen gab. Das vorherige Modell war ein "G 5G plus" und hatte nur 4 GB RAM. Das machte sich bei der Benutzung deutlich bemerkbar. Beim Wechseln zwischen Apps hakte es deutlich, und die Speicherverwaltung hat sehr oft Apps komplett aus dem Speicher entfernt, so dass beim Wechseln ein Neustart der App nötig war. Die Kamera ist bei allen Modellen ziemlich gut, auf jeden Fall ausreichend für meine Schnappschüsse. Die Bedienung und die zusätzlichen Gesten, die die Motorola-Geräte anbieten, finde ich enorm praktisch, und das Android ist nahezu identisch zum Original von Google - es gibt keine aufgeblähten Aufsätze wie bei Samsung oder Xiaomi oder zwangsinstallierte Software von Facebook, LinkedIn o.ä., die man nicht entfernen kann, ohne das Gerät zu "rooten" und dadurch die Gewährleistung zu riskieren.

Für das G 5G plus ("nairo") ist a) der Update-Support abgelaufen und b) es gibt ein offizielles LineageOS-ROM für dieses Modell. Was also liegt näher, als es mal wieder zu wagen?

Im Nachhinein bin ich etwas verärgert, dass Motorola keine Updates mehr für dieses Modell liefert. Da ich selbst als Software-Entwickler mit ziemlich modernen Werkzeugen arbeite und insbesondere viel mit automatischer Erstellung und Prüfung von Softwarepaketen zu tun habe, verwundert mich die Entscheidung, keine Updates mehr zu liefern. Die meisten Updates für Android werden von Google zugeliefert und können nahezu vollautomatisch integriert werden. Danach ein Update-Paket zu erstellen und auszuliefern, ist dann nur noch eine Sache von wenigen Minuten. Seit Jahren geht durch die Presse, wie gefährlich Cyber-Angriffe sind, und dass Updates die wichtigste Gegenmaßnahme sind - und trotzdem beharren Hersteller auf absurd kurzen Zeiträumen für die Bereitstellung von aktuellen Updates gegen Sicherheitslücken.

Es gibt ein paar wenige Situationen, in denen es plausibel ist, dass keine Updates mehr geliefert werden. Ein solcher Fall ist, dass sich ein Hardwarehersteller aus dem Geschäft mit Chips für Smartphones vollständig aus dem Geschäft zurückzieht. So geschehen bei Texas Instruments, die den CPU-Chip für das Samsung Galaxy Nexus geliefert haben. Danach gab es keine Updates mehr für die integrierten Module wie Bluetooth, WLAN, Kamera etc., die alle als Binärpakete von TI zugeliefert wurden.

Aber zurück zum eigentlichen Thema :-)

Spoiler: alles lief wunderbar geschmeidig - einfach der Schritt-für-Schritt-Anleitung bei LineageOS folgen. Jetzt hat das G 5G plus ein neues Leben mit Android 13 und monatlichen Updates :-)

1. Entwicklereinstellungen freischalten (7x auf "Build Datum" tippen)
   
2. Bootloader in den Entwicklereinstellungen entsperren ("OEM unlock")
   
3. USB-Debugmodus einschalten und "vertrauenswürdiges Gerät" bestätigen
   
4. Gerät mit USB-C-Datenkabel an den PC anschließen (sowohl Linux als auch Windows auf dem PC sind möglich)
   
5. Im Fastboot-Modus den Code mit dem Befehl "fastboot oem get_unlock_data" abfragen
6. Den Code auf dieser Motorola-Webseite eingeben. Nicht die Weiterleitung nach Deutschland anklicken, sondern die US-Seite verwenden (man muss sich dazu mit einer Emailadresse als Benutzer registrieren oder das Login mit Google verwenden)
   
7. Auf die Email von Motorola warten (10 min.)
   
8. Im Fastboot-Modus das Handy mit dem Befehl "fastboot oem unlock <Code>" und dem Code aus der Email entsperren
9. Immer noch im Fastboot-Modus das LineageOS-Recovery installieren
10. Bootloader neu starten
11. Kopierskript für die A/B-Partitionen mit "adb sideload" starten
    
12. Recovery starten (Bedienung mit Touchscreen möglich, nicht nur mit den Tasten)
    
13. Speicher formatieren
14. LineageOS-ROM mit "adb sideload" installieren (die Datei mit "-nairo-signed.zip" am Ende)
    
15. MindTheGApps mit "adb sideload" installieren (die OpenGApps werden nicht mehr gepflegt)
    
16. Neu starten
17. Handy einrichten wie üblich
    

Das war kompliziert ... LineageOS 16.0 auf dem LG G3

Das war ein hartes Stück Arbeit diesmal! Bei ebay Kleinanzeigen habe ich ein LG G3 gesehen, das nicht mehr booten wollte. Der Verkäufer wollte nur ein Taschengeld dafür haben, deswegen konnte ich nicht nein sagen ...

"Nicht richtig starten" klingt nach einem größeren Hardwareproblem, d.h. die Hauptplatine des Geräts wird getauscht werden müssen. Bei solchen winzigen Bauteilen (noch dazu Spezialbauteilen ...) ist es nahezu aussichtslos, mit dem Lötkolben irgend etwas reparieren zu können.

Vor dem Kauf hatte ich bei ebay nachgeschaut, ob es Mainboards zu erschwinglichen Preisen gibt, und konnte ein Ersatzteil für ebenfalls wenig Geld in der "großen" 32 GB-Version bestellen. Es gibt Händler, die defekte Smartphones zerlegen und Einzelteile verkaufen. Auch Displays, Kameras, sogar einzelne Folienkabel kann man kaufen, wenn man ein entsprechendes Bedürfnis hat ;-)

Als das Telefon ankam, probierte ich zuerst, es einzuschalten. Das ging von etwa 20 Versuchen etwa einmal, und auch da nur bis zum "LG Life's good" Startbildschirm, danach war tote Hose. Also war tatsächlich Mainboard tauschen angesagt.


Die Geräte von LG (G3 und G4) sind sehr wartungsfreundlich. Man kann die Rückwand abnehmen, den Akku wechseln, und es ist nichts geklebt, sondern nur geschraubt. Nach dem Entfernen von gut 10 Schrauben rundherum konnte ich zwei Plastikführungen entfernen, die Folienkabel abklipsen und das Mainboard einfach herausheben und gegen das neue austauschen.

Insgesamt ist das LG G3 auch heute noch ein brauchbares Gerät. Beim Erscheinen war es die damalige Oberklasse, und auch heute kann man mit Snapdragon 800, 2.5 GHz, 4 Kernen, 3 GB RAM, 32 GB Speicher, 13MP-Kamera und einer Auflösung von 2500x1400 sehr gut leben. Außerdem kann man eine SD-Karte dazustecken, und meine testweise eingesteckte 64 GB-Karte hat es sofort benutzen können.

Das LG G4, das meine Frau bis vor einiger Zeit benutzte, ließ sich problemlos im fastboot-Menü entsperren, deswegen war ich zunächst ohne Bedenken, dass das G3 irgendwelche Probleme machen könnte.

Weit gefehlt!

So einen komplizierten Recherche- und Lernprozess hatte ich noch bei keinem der Handys, auf die ich LineageOS oder ein anderes Custom ROM installieren wollte.

Zum Ersten hat das Handy keinen fastboot-Modus. Das empfohlene Vorgehen ist, das Gerät zu "rooten", sich also mit Hilfe einer Sicherheitslücke in der Originalsoftware Administratorzugang (unter Unix eben "root") zu verschaffen, und danach direkt mit dem lowlevel-Befehl "dd" die Recoverypartition mit dem Custom Recovery TWRP zu überschreiben.

Schon das Rooten war nicht einfach: ich habe mehrere Tools ausprobieren müssen, bis eines erfolgreich war. Das Telefon bzw. das Ersatzmainboard kam mit Lollipop, also Android 5.0, und erst eine relativ neue Fassung von KingRoot hat es geschafft, mir Rootrechte zu geben. Die Installationsversuche mit Towelroot, Kingroot und ähnlichen Tools hat übrigens zuverlässig dazu geführt, dass Android mir erklären wollte, dass ich Schadsoftware auf dem Handy hätte, und bot gleich an, sie zu entfernen. Immerhin wurde ich trotzdem nicht daran gehindert, sie zu installieren und zu benutzen.

Das Flashen von TWRP war dann problemlos, aber beim Einschalten mit der Tastenkombination kam eben nicht das Customrecovery auf den Bildschirm, sondern ich bekam nur eine abwechselnd rot und blau leuchtende LED. Wie ich später herausfand, ist dies das Warnsignal, dass der "Secure boot" kein valides Recoveryprogramm gefunden hat. Aus diesem Fehlermodus kommt man nur durch Entfernen des Akkus wieder heraus.

Danach hatte ich noch mehrere erfolglose Versuche, mit anderen Versionen des TWRP-Images ein Custom Recovery auf das Gerät zu bringen. Jedes Mal wieder nur die lustig blinkende LED ...

Dann fragte ich auf Reddit im LG G3-Forum und bekam dort einen Hinweis, dass die "früheren" Bootloader noch nicht dieses Sicherheitsfeature hätten, und ich sollte mit dem Factoryimage (also die Originalfassung von LG) ein Android 4.4 installieren. Ich hätte nun beinah tatsächlich 1 GB heruntergeladen, aber zwischendrin stieß ich auf einen Artikel bei XDA, dass es reicht, nur den Bootloader zu ersetzen, ohne das gesamte Telefon mit einem noch älteren Android neu zu bespielen.

Freundlicherweise gibt es dafür ein Hilfswerkzeug, das ich im selben Artikel auch noch fand: es nennt sich AutoRecMM und überschreibt sowohl den Bootloader als auch das Recovery des Geräts mit passenden Versionen. Damit konnte ich tatsächlich in ein TWRP Custom Recovery booten, wenn auch in einer älteren Version 2.8.7.

Naja, das wär's dann eigentlich gewesen ... aber dann ist noch ein weiterer Fehler dazwischen gekommen: das LineageOS-zip ließ sich nicht flashen, weil das Gerät nicht mehr von sich selbst wusste, dass es ein G3, Modell d855 ist. Dieses Problem konnte ich beheben, indem ich mit TWRP selbst ein neueres TWRP installierte, diesmal 3.3.1. Wohlweislich hatte ich nämlich vor dem Flashen mit adb noch ein paar nützliche Dateien in den Speicher des Telefons überspielt, darunter auch die aktuelle twrp.img-Datei. Beim Flashen dieser Datei "lernt" das Handy wieder, dass es ein G3, d855 ist. Die Fehlermeldung dazu lautete sinngemäß "This installation requires a d855, your model is a .", d.h. die Kennung für den Typ des Smartphones war leer.

Wichtig: bei der ersten Installation unbedingt vor dem Booten auch gleich noch die Open GApps (stock, 32 bit) installieren. Nur wenn beide Dateien zusammen vor dem Booten geflasht wurden, passen alle Berechtigungen. Wenn LineageOS ohne die Open GApps gestartet wurde, lässt sich das nicht mehr nachholen und man muss einen Factory Reset machen und erneut beides (diesmal zusammen) flashen! Wenn man Krams wie Duo oder Hangouts nicht haben will, muss man mit einer handgeschnitzten gapps-config.txt nachhelfen, so dass die unnötigen Apps gleich entfernt werden. Es ist aber trotzdem sinnvoll, ein "großes" GApps-Paket zu installieren, damit die Apps, die man haben möchte, in der Systempartition und nicht im Benutzerspeicher installiert werden.

Und nun endlich konnte ich das aktuelle LineageOS 16.0 (mit Sicherheitsstand 09/2019) flashen! Und natürlich auch gleich Magisk zum Rooten :-)

Die Geschichte geht noch ein kleines Stücken weiter: die LineageOS-Version hat wunderbar funktioniert bis auf einen Haken: die Funktion "lange drücken" ging nicht. Beim Versuch, ein Widget auf dem Startbildschirm (ich mag die "analog clock") einzurichten, kam immer nur der Hinweis, dass ich lang drücken soll. Über das Update-Menü habe ich mir dann die 2 Tage neuere LineageOS-Version direkt auf das Gerät heruntergeladen und installieren lassen, und dann lief alles, so wie es soll ;-)

Zum Schluss noch eine Bemerkung, weil ich oben schon mal das LG G4 meiner Frau erwähnte:
es wurde dann abgelegt, weil es kein offizielles LineageOS mehr dafür gab, und durch ein Moto Z ersetzt, aber das ist eine andere Geschichte. Mittlerweile gibt es übrigens wieder "unofficial" Builds für das G4, und es läuft sehr gut damit. Aber auch das ist eine andere Geschichte ;-)

Motorola Moto X (2014) auf Android 9 updaten

Nach längerer Zeit wollte ich mal wieder ein älteres Smartphone, das bei mir noch im Regal lag, mit einem aktuellen Custom ROM versehen. Das Moto X in der 2. Generation ist für mich immer noch ein tolles Gerät - es hat 32 GB Speicher, einen guten Bildschirm mit AMOLED und HD-Auflösung (1920x1080) und ist selbst für heutige Verhältnisse sehr schnell und somit für alle Alltagszwecke gut nutzbar. Die Kamera schießt gute Fotos mit 13 MP. Es wird angetrieben von einem Snapdragon 801 mit 2.5 GHz, hat einen Adreno 330 Grafikchip, 2 GB Arbeitsspeicher, den aktuellen WLAN-Standard 11ac, sowie alle LTE-Bänder für Deutschland (800, 1800, 2600 MHz).

Leider ist die Organisation hinter LineageOS recht rabiat geworden, was den offiziellen Status für bestimmte Smartphones angeht. So ist z.B. mein nach wie vor geliebtes Samsung Galaxy Nexus schon mit Android 6 entfernt worden, und auch beim Moto X sieht es nicht besser aus. Sobald ein Fehler beim Erstellen des Pakets oder bei der Benutzung gemeldet wird und der "Maintainer", d.h. der offizielle Betreuer dieses Modells, den Fehler nicht innerhalb kürzester Zeit behebt, wird das Gerät aus der Liste der offiziellen Modelle entfernt.

So auch geschehen beim LG G4, bei dem die Verschlüsselung nicht (mehr) richtig funktioniert, weil LG ein notwendiges Firmwareupdate für dieses alte Modell nicht mehr liefern will oder kann. Selbst wenn man willens wäre, das Gerät ohne Verschlüsselung zu benutzen (z.B. zuhause als Media Player), gibt es keine Chance, hier ein offizielles signiertes LineageOS-Paket zu bekommen. Oder beim Nexus 5, bei dem es ein Problem mit Telefonieren über Bluetooth gibt, das die Maintainer nicht in den Griff bekommen.

In diesem Fall muss man leider auf "unofficial builds" ausweichen und hoffen, dass das Vertrauen in den Ersteller des Pakets nicht missbraucht wird, und man sich vielleicht einen Trojaner einfängt.

Nun denn, ich war mutig, und eine kurze schnelle Google-Suche brachte zutage, dass es wirklich für das Moto X (Codename "victara") ein inoffizielles Paket des aktuellen Android 9 "Pie" gibt.

Update: Lineage hat einen offiziellen Betreuer gefunden und die aktuelle Version 9 "Pie", also LineageOS 16.0, ist für das Moto X2 "victara" wieder von der Website der Organisation verfügbar. Das verbessert die Situation natürlich beträchtlich.

Das Custom Recovery "TWRP" wird für dieses Modell ebenfalls noch gepflegt, man kann also nach dem Entsperren über die Motorola-Website problemlos mit Fastboot ein Custom Recovery aufspielen und danach ein Custom ROM. Wenn man sich mit Google ins Bett legen will, kann man natürlich auch die Open GApps noch mit installieren (die 9.0 ARM 32 Bit Variante "stock" herunterladen). Für das Rooten des Geräts bietet sich mittlerweile "Magisk" an, das sich auch vor kritischen Apps wie Pokemon GO oder Banking-Apps verbergen kann.

Wenn man die GApps haben will, muss man sie direkt nach dem Flashen des Custom ROMs installieren, bevor man zum ersten Mal neu mit LineageOS bootet. Tut man das nicht, fehlen den Google Apps einige Berechtigungen, was man daran erkennt, dass die "Play Services" sich permanent beenden und nicht richtig funktionieren. Falls das passiert ist, muss man im Recovery mit "Wipe" alle Nutzerdaten löschen, ROM und GApps hintereinander in einem Rutsch flashen und das Telefon nochmals neu aufsetzen.

Bei den GApps gibt es verschieden große Varianten mit mehr oder weniger Inhalt. Das Minimalpaket ist "pico" und enthält nur den Zugang zum Playstore. Jede "größere" Variante enthält mehr und mehr Google Apps, auch solche, die man vielleicht nicht haben will oder gar nicht benötigt. Es ist trotzdem sinnvoller, eines der "großen" Pakete wie "stock" zu verwenden und mit einer Konfigurationsdatei die Apps zu entfernen, die man nicht haben will. Wenn man die Apps über den Playstore einzeln installiert, belasten sie den Benutzerteil des Speichers; wenn man sie mit dem GApps-Paket installiert, landen sie in der Systempartition und man hat mehr Speicherplatz für Bilder und Musik frei.

Bevor man das ROM überspielt, sollte man aber tunlichst noch das letzte offizielle Paket der Motorola-Android-Version herunterladen, das sogenannte "factory image". Das Moto X ist bei Marshmallow, Android 6.0, stehen geblieben, und es gibt einige Seiten, auf denen man das "RETDE"-Paket ("retail german") herunterladen kann. Mit diesem Paket kann man das Smartphone wieder in den Originalzustand versetzen, falls man es doch noch weggeben will und der Käufer kein Custom ROM haben will. Das Moto X (2014), das ich verwende, ist das Modell XT1092 und das letzte aktuelle Paket trägt die Nummer "XT1092_VICTARA_RETDE_6.0_MPES24.49-18-7".

Das erste Starten des Custom ROMs dauert recht lang, weil viele Grundeinstellungen eingerichtet werden müssen. Man sieht also die Bootanimation von LineageOS ca. 5 min. lang, bevor der Einrichtungsassistent loslegt - keine Panik!

Bei mir war der Einrichtungsassistent recht zickig und hat sehr lang gebraucht, um zu erkennen, dass derzeit keine offiziellen Updates vorhanden sind (wie auch). Ich musste das Telefon mehrfach neu starten und es immer wieder probieren. Vielleicht war aber auch nur zu der Zeit mein Internet zu wackelig.

Danach gab es eine unangenehme Überraschung, nämlich, dass die SIM-Karte nicht mehr erkannt wurde. In den Android-Einstellungen war bei den Telefondaten die "IMEI" als "unbekannt" deklariert, d.h. das Telefon wusste nicht, welche Seriennummer es dem Mobilbetreiber nennen müsste, und konnte deshalb auch die SIM-Karte gar nicht benutzen.

Dieses Problem lässt sich aber bei Motorola-Smartphones leicht lösen: man benötigt aus dem Factory-Paket die Dateien für "modem" und "fsg" und mit einigen weiteren Fastboot-Befehlen kann man die IMEI wiederherstellen.

fastboot flash modem NON-HLOS.bin
fastboot erase modemst1
fastboot erase modemst2
fastboot flash fsg fsg.mbn

Diese Befehle sollte man nach dem Überspielen von Custom ROM, GApps und ggfs. Magisk (zum Rooten) im Bootloader (also Fastbootmodus) durchführen, bevor man neu ins Android startet, d.hj. man sollte im TWRP-Recovery nicht "reboot system" auswählen, sondern zuerst ins Hauptmenü wechseln und von dort "Reboot Bootloader" auswählen. Dann kann der Einrichtungsassistent auch die SIM-Karte erkennen und ggfs. über Mobilfunk die Einrichtung beginnen. Alternativ kann man die Befehle jederzeit auch später nachholen, es kann nichts kaputt gehen.

Lies die Anleitung bis zum Ende!

Eigentlich sollte das eine Selbstverständlichkeit sein, aber manchmal vergisst man solche Grundsätze oder überfliegt die Anleitung nur flüchtig.

So ist es mir kürzlich passiert, als ich ein "unofficial" LineageOS auf dem Smartphone eines Freundes installieren wollte. Ich hatte ihm Motorola empfohlen und er war begeistert von den "Moto Mods" - magnetischen Modulen, die man an die Rückseite anklipsen kann.

Ich selbst verwende ein Moto Z von 2016 (XT1650), weil mich das Kameramodul von Hasselblad fasziniert hat, und mein Freund ist ein HiFi-Fan, der das Modul mit JBL-Stereolautsprecher haben wollte. Daneben gibt es noch verschiedene Zusatzakkus, einen Drucker oder einen Beamer. Motorola garantiert bei der "Z"-Baureihe, dass die Module mindestens drei Smartphonegenerationen lang benutzt werden können, dass man also ein neueres Telefon der Baureihe kaufen kann und die Module können weiter verwendet werden. Das klappt wirklich: mein Akkumod - zusammen mit dem Moto Z gekauft - passt auch an das Z2 meines Bekannten.

Dummerweise hat er das Modell "Z2 Play" gekauft, das derzeit nicht offiziell von LineageOS unterstützt wird, d.h. es ist nicht über die Downloadseite zu bekommen. Der Entwickler bietet es quasi "privat" als Download bei Google Drive an. Bei meinem eigenen Telefon hatte ich als erstes Kriterium die Verfügbarkeit eines offiziellen LineageOS, und als zweites Kriterium wollte ich einen Bildschirm mit mehr als HD-Auflösung, also besser als die üblichen 1920x1080. Die "Play"-Modelle von Motorola haben aber nur diese Bildschirmgröße, deshalb fiel das bei mir durch's Raster.

[Update 20181017] Das Motorola Z2 Play "albus" ist mittlerweile offiziell.

Der erste Schritt war der Start des Telefons, weil man in den Entwickleroptionen erst das Entsperren des Bootloaders erlauben muss - das findet sich bei immer mehr Herstellern, nicht nur Motorola, sondern z.B. auch LG. Danach konnte ich das Smartphone mit dem PC verbinden und im Debugmodus mit adb die nötigen Dateien kopieren. Nach dem Wechsel in den Fastboot-Modus mit dem Befehl "adb reboot bootloader" konnte ich dann den Entsperrcode benutzen, den Motorola mir in einer Email geschickt hatte.

Der erste Installationsversuch von LineageOS schlug fehl, weil nach der Installation des (durchaus funktionsfähigen) TWRP-Recoverys das LineageOS-Zip sich mit "ERROR 255" nicht installieren ließ. Beim ersten Mal dachte ich, dass die Zip-Datei beschädigt ist und ließ sie mit "unzip -t" auf dem NAS prüfen, aber die Datei war in Ordnung.

Etwas Recherche ergab, dass für dieses Smartphone ein spezielles "64 bit" TWRP verwendet werden muss, das auch nicht offiziell von TWRP angeboten wird. An dieser Stelle wurde ich dann doch etwas unsicher über das ganze "inoffizielle" Gedöns ... aber mein Kumpel war zuversichtlich und wir machten weiter.

Der zweite Versuch schlug schon viel früher fehl: das neu geflashte Recovery startet bis zum Bildschirm, auf dem man "Install", "Wipe" usw. aufrufen kann, aber der Touchscreen war nicht funktionsfähig.

An dieser Stelle brachen wir die Installation dann doch ab und ich restaurierte auch das originale Recovery von Motorola wieder. Nach einem Neustart des Smartphones mit dem "hello moto" zeigte sich beruhigenderweise wieder das vertraute Bild der Motorola-Version von Android 7.1 Nougat.

Trotzdem ließ mir dieser Fehlschlag keine Ruhe - ich wollte das nicht auf mir sitzen lassen! Alle bisherigen Telefone ließen sich problemlos entsperren und mit CM bzw. LOS bespielen, warum also nicht dieses?

Beim erneuten Durchlesen der Beschreibung fiel mir auf, dass ich einen entscheidenden Satz überlesen hatte: "Bugs: Need to press power button two times for touch to work". Also einfach mal den Bildschirm ausschalten und wieder einschalten!

Das hat dann tatsächlich geklappt, es kam das übliche "Swipe to unlock", und danach konnten wir weiter machen. Die Installation von LineageOS, Google Apps und dem addon-su-Paket lief dann schmerzfrei, und nach der Freischaltung in meiner Firewall konnte mein Kumpel auch das Telefon fertig einrichten, Apps herunterladen usw. Den genauen Ablauf habe ich oft genug beschrieben, deshalb werde ich das hier nicht noch mal wiederholen ;-)

Eine kleine Besonderheit gibt es: nach dem Entsperren des Bootloaders wird das Einschaltbild ("boot logo") durch einen Hinweistext ersetzt, dass das Telefon entsperrt ist. Dieses Bootlogo kann man natürlich problemlos durch ein schöneres Bild ersetzen, es finden sich genügend fertige zum Downloaden, und mit dem "Motorola Bootlogo Maker" kann man sich auch eigene Bilder zurecht basteln.

Also am Ende alles gut ;-)

Da fiel mir dann der alte Spruch auch gleich wieder ein: "if all else fails, read the instructions".

[Update 20190924] Nachdem wir feststellten, dass LineageOS die meisten Mods nicht vernünftig unterstützt, weil man dazu proprietäre Softwaremodule benötigt, die die LineageOS-Entwickler nicht verteilen dürfen, haben wir das originale Android von Motorola wieder zurückgespielt. Der Akkumod funktioniert, aber der JBL-Lautsprecher leider nicht.

LineageOS ist eine tolle Sache

Ich habe ja schon einige Beiträge dazu geschrieben, wie toll ich es finde, dass alte Smartphone-Modelle immer noch Software-Updates bekommen, wenn man vom Original-ROM des Herstellers auf ein sogenanntes "Custom ROM" wechselt.

Diese Beiträge (für Modelle von Samsung, Motorola, LG und Google) waren bislang eher technisch. Ich möchte aber auch gern mal eher prinzipiell über die Vorteile eines aktuellen Custom ROMs schreiben.

Ich gebe zu, dass ich eher ein paranoider Mensch bin, der die Nachrichtenmeldungen über Datenverluste, Trojanerangriffe, Virusausbreitung usw. beunruhigt zur Kenntnis nimmt. Deswegen bin ich auch immer sehr bemüht, meine Software aktuell zu halten und alle Updates einzuspielen. Mit aktueller Software kann man das Risiko, Opfer eines Angriffs zu werden, enorm verringern. Diese Tatsache kann man gar nicht oft genug aussprechen!

Das Besondere an diesen Custom ROMs ist: sie sind fast immer fast genauso aktuell wie Google die neuen Android-Versionen und die Sicherheitsupdates veröffentlicht. Nach einer neuen Android-Version dauert es vielleicht ein paar Wochen und auch nicht für alle Modelle gleichzeitig, aber mit ein bißchen Geduld hat man dann wieder das allerneueste Android auf seinem Smartphone. Die einzige derzeitige Ausnahme ist das Samsung Galaxy Nexus. Für dieses Modell gibt es nicht LineageOS 14.1 "Nougat" (Android 7), sondern "nur" 13.0 "Marshmallow" (Android 6). Aber selbst das ist bemerkenswert, wenn ich überlege, dass es von Google nur bis Jellybean (4.3) offiziell mit Software versorgt wurde. Man muss nicht immer das allerneueste Betriebssystem haben - aber die Sicherheitsupdates sind enorm wichtig, und die liefert LineageOS auch bei diesem Modell.

[20171023] Aktueller Nachtrag: LineageOS hat die Patches für KRACK am 16. Oktober integriert.

Die meisten Smartphones gehören mittlerweile ins Billig- und Discounter-Segment. Ich will damit nicht die Qualität des Geräts schlechtreden, aber der Hersteller spart dann bei der Softwarequalität und vor allem in der Pflege des Geräts nach dem Kauf. Bei einem Handy für 99€ kann man nach dem Kauf keinerlei Software-Updates mehr erwarten. Generell sollte man lieber etwas mehr investieren und darauf achten, dass der Hersteller die Dauer der Updates nach dem Kauf ausdrücklich erwähnt. Nokia ist hier mit den neueren Geräten (Nokia 3, 5, 6 und 8 mit Android) eine rühmliche Ausnahme, genau wie Google selbst mit den (früheren) Nexus- und jetzigen Pixel-Geräten. Hier weiß man, dass es Updates geben wird. Bei anderen Herstellern hängt der Preis unmittelbar mit der Updatelieferung zusammen: die Top-Geräte bekommen vermutlich noch das eine oder andere Update (z.B. Galaxy S7, S8), die billigeren oder älteren Geräte dann schon wieder nicht mehr.

Eine weitere Möglichkeit, die nebenbei auch noch gut für die Umwelt ist, könnte sein, dass man auf ein Neugerät verzichtet und bei einem Händler ein gebrauchtes Gerät sucht, für das es ein Custom ROM gibt. So mache ich es seit langem: erst überlege ich, welche Eigenschaften mein zukünftiges Smartphone haben soll (Speicher, Displaygröße, Displayauflösung in Pixel, Kamera), und dann informiere ich mich bei download.lineageos.org, für welche Geräte es dort ein ROM gibt. Danach suche ich bei Händlern wie rebuy.de oder bei ebay.de ein solches gut erhaltenes Gerät.

Kauf bei einem (deutschen) Händler hat den Vorteil, dass man auf das gebrauchte Gerät immerhin noch 12 Monate Gewährleistung bekommt, die der Händler auch nicht wegdiskutieren kann. Auf diese Weise habe ich kürzlich ein Google Nexus 5 für mich und die Schwiegermutter gekauft, ein Nexus 6 für Kind 2, und ein LG G4 für die beste Ehefrau von allen. Ein gern verwendetes Argument gegen gebrauchte Handys kann ich empirisch von meinen eigenen gekauften Geräten nicht bestätigen: die Akkus sind alle akzeptabel gewesen. Für das G4 mit wechselbarem Akku habe ich einen Ersatzakku gekauft, aber mehr aus Bequemlichkeit.

Nur Kind 1 fällt vollkommen aus dem Rahmen: sie will Geräte von Apple. Technisch finde ich das ok, weil sowohl die Geräte konstruktiv gut sind, als auch Updates für lange Zeit gesichert sind. Auf dem Retina-MacBook läuft das aktuellste OS X, und das iPhone erhält immer noch die iOS-Updates. Über die Geschäftspolitik von Apple und die Steuervermeidungsstrategien kann ich nur den Kopf schütteln, aber technisch habe ich wenig auszusetzen. Die Reparaturmöglichkeiten bei Apple sind laut iFixit.com durchwachsen: manche Geräte lassen sich sehr gut reparieren, andere sind verklebt und gelötet, so dass Aufrüsten oder Instandsetzen nur schwer möglich sind.

Zurück zu Android: an diesem Punkt angelangt und ein Modell ausgesucht und gekauft. Nun hat man also ein Gerät, für das es ein Custom ROM gibt, und dann kann man loslegen, das Hersteller-ROM durch ein Custom ROM zu ersetzen. Darauf will ich jetzt an dieser Stelle nicht mehr eingehen, es gibt ein paar ältere Beiträge, in denen ich das Entsperren und Flashen eines Custom ROMs beschrieben habe (Samsung Galaxy S, Galaxy S+, Galaxy S2, Galaxy Nexus, LG G4). Ich finde es einfach großartig, dass es Software-Entwickler gibt, die in ihrer Freizeit die von Google freigegebene Android-Software auf andere Smartphone-Modelle anpassen und weiter pflegen.

Insbesondere bekommt man auf diese Weise die Android-Security-Updates, die Google seit den schwerwiegenden Fehlern in den Medienbibliotheken monatlich entwickelt und im "Android Open Source Project" (AOSP) veröffentlicht. Erwähnenswert ist auch noch, dass die reinen Android-Updates auch für alte Versionen bis zurück zu 4.4 dort abgelegt werden. Was leider nicht gemacht wird: Google erstellt selbst keine installierbaren Pakete mehr; deshalb gibt es für das Nexus 5 z.B. auch keinerlei Updates mehr (das sogenannte "end of life" bei Google-Geräten bedeutet, dass man zwei Jahre lang alle Updates bekommt, auch neue Androidversionen, und danach noch ein weiteres Jahr Security-Updates).

Und was auch nicht gemacht wird: für jedes Smartphone-Modell müsste man neben dem eigentlichen Android noch höchst spezifische Linux-Kernelupdates pflegen, und das macht Google leider nicht für alte Geräte. Außerdem kann es passieren, dass ein CPU-Hersteller den Support für einen CPU-Chip einstellt. Dann kann sich Google auf den Kopf stellen, aber es ist nicht mehr möglich, Updates für den Kernel zu erstellen.

So ist das leider beim Galaxy Nexus geschehen: es hat eine CPU von Texas Instruments (OMAP), und TI hat sich aus dem Geschäft mit Smartphone-CPUs komplett zurückgezogen. Dummerweise sind die Unterlagen nicht öffentlich, so dass auch niemand sonst die Arbeit übernehmen kann. Das ist schlecht, weil üblicherweise in diesen CPU-Chips auch WLAN, Bluetooth, LTE oder andere Funktionen integriert sind, die eigene Software enthalten, die sogenannte Firmware. Genau wie jede andere Software können auch hier Programmierfehler und Sicherheitslücken enthalten sein!

Um Mißverständnissen vorzubeugen: die öffentlichen Updates für den Linuxkernel kann man natürlich bekommen oder selbst einpflegen. Falls aber ein Fehler in der Firmware bekannt würde, könnte man den nicht beheben. Diese Firmware wird in Form von Binärpaketen beim Starten vom Kernel in den Spezialchip geladen (für WLAN, Bluetooth, LTE, Kamera, was auch immer), und neue Binärpakete gibt es vom Chiphersteller leider nicht. Nebenbei gibt es eine nicht ganz vollständige Liste als Überblick, welche Android-Version mit welcher Kernelversion ausgeliefert wird. Google macht hierzu seit einiger Zeit sogar bestimmte Vorgaben, welche Kernelversion es mindestens sein muss.

Wenn aus Gründen gar kein Software-Update (mehr) möglich ist, ist die letzte Konsequenz dann eben, dem Gerät den Internetzugang zu sperren. Letzteres passierte bei uns 2014, nachdem Microsoft die Updates für Windows XP einstellte - die PCs, auf denen eine spezielle Software für die Tierarztpraxis läuft, dürfen jetzt einfach nicht mehr ins Internet und damit gibt es auch keine Infektionsgefahr mehr. Die Software läuft gut, sie würde auf einem neueren Windows nicht mehr laufen, und die PCs wären auch nicht wirklich gut gerüstet für eine neuere Windowsversion - warum also sollte ich Windows updaten? Für den Internet-Zugang gibt es seitdem einen PC mit Linux, für den es - natürlich - Updates gibt.

Ältere Smartphones ohne Updatemöglichkeit kann man dann immer noch als lokale Medienspieler oder für andere Zwecke einsetzen oder selbst gebraucht verkaufen. Internetzugang für ein Smartphone sperren ist in meiner kleinen Welt ganz einfach: ich entferne die private WLAN-IP-Adresse des Geräts aus meinem Firewall, und wenn keine SIM-Karte drinsteckt, war's das mit dem Internetzugang. Bei weniger paranoiden Menschen müsste man umgekehrt die Nummer des Geräts aktiv in der Fritzbox (o.ä. Router ...) sperren. Vor der finalen Sperre sollte man natürlich alle Apps installieren, die man auf dem Gerät weiterverwenden will.

Ich habe eigentlich gar nicht die Befürchtung, dass ich persönlich von bösen Menschen von irgendwoher angegriffen werde - die Gefahr ist einfach, dass ein breit gestreuter Angriff mich auch erwischt. Die bösen Buben haben es darauf abgesehen, entweder Drohnen einzufangen, mit denen dann Denial-of-Service-Angriffe (Lahmlegen des angegriffenen Ziels) getätigt werden, oder die Opfer zu erpressen, indem ihr Gerät verschlüsselt wird und für die vermeintliche Entschlüsselung Geld verlangt wird. Die Wahrscheinlichkeit, dass mich persönlich irgend jemand angreift, ist verschwindend gering - dazu bin ich nicht wichtig genug.

Angriffe geschehen häufig über Schwachstellen im Browser, durch die eine Schadsoftware "ausbrechen" und mit Hilfe einer weiteren Sicherheitslücke im Betriebssystem böse Dinge tun kann - entweder unmittelbar oder indem sie sich dauerhaft einnistet. Deshalb ist es besonders wichtig, das Betriebssystem, den Browser und eventuelle Hilfspakete im Browser ("Addons", "Extensions", "Plugins"), z.B. Flash, immer aktuell zu halten. Dazu sollte man das "automatische Update" einschalten, sofern vorhanden, oder zumindest regelmäßig nach Updates suchen. Dabei ist es wichtig, das Update nur direkt vom Hersteller herunterzuladen und nicht von irgendwelchen Downloadseiten. Dort kann man weder sicher sein, dass es wirklich die aktuellste Version ist, noch, dass nicht jemand das Update manipuliert hat und man sich gerade mit dem Update eine Schadsoftware einhandelt.

Solche Schadsoftware wird auch gern mal als Werbung im Browser-Fenster ausgespielt. Mittlerweile halte ich einen Adblocker (Werbeblocker) im Browser für unverzichtbar (ich verwende "uBlock origin"). Die Website-Betreiber haben die Kontrolle über die ausgespielte Werbung vollkommen abgegeben - es gibt Dienstleister, die dann wiederum an Subunternehmer Aufträge vergeben oder die Werbefläche sogar in automatisierten Auktionen "live" versteigern.

Noch relativ selten nehmen auch die Angriffe über Office-Dokumente wieder zu. Das war vor 10-15 Jahren ein großes Problem, weil in den üblichen Office-Programmen auch eine Programmiersprache enthalten ist, die nicht nur Dokumente automatisieren kann, sondern auch das Betriebssystem ansprechen kann (Visual Basic und Office-Makros mit Autostart-Funktion). Mittlerweile muss man diese Makros ausdrücklich einschalten, wenn man sie benötigt. Manche Angriffe bitten den Anwender deshalb genau darum - "Bitte erlauben Sie Makros, damit ich als Virus meine Arbeit erledigen kann. Vielen Dank!".

Eine weitere Angriffsmöglichkeit sind echt aussehende gefälschte Emails, in denen man auf einen Link klicken soll. Gern genommen werden hier Emails mit einem Drohpotenzial, z.B. indem mit der Sperrung des Bankkontos oder Nutzerkontos gedroht wird und Zeitdruck erzeugt wird. Entweder wird dann die Eingabe von persönlichen Daten auf einer Webseite verlangt, oder allein durch das Anklicken des Links in der Email hat man sich schon infiziert. In diesen Mails wird häufig behauptet, dass man nur sehr wenig Zeit habe zu reagieren, bevor das Konto ganz gesperrt wird, oder ähnlich vermeintlich empfindliche Konsequenzen. Damit soll verhindert werden, dass man sich die Mail genauer anschaut oder recherchiert, z.B. dort anruft und direkt nachfragt.

Gefälschte Emails stammen dann angeblich vom Emailprovider wie GMX, 1&1, web.de, oder von einem Internetversandhändler, z.B. Amazon, oder von einer Bank, in letzter Zeit hatte ich z.B. häufig solche "Phishing"-Mails von der Deutschen Bank, aber auch von diversen Sparkassen und Volksbanken. Diese Mails sind natürlich durchschaubar, wenn man dort gar nicht Kunde ist. "Phishing" ist übrigens ein englisches Kunstwort, das aus den Worten "Password" und "fishing" zusammengesetzt ist, d.h. jemand versucht dort mit Tricks, ein Passwort zu ergaunern.

Man kann solche Mails i.a. erkennen, indem man mit dem Mauszeiger über den Link fährt (aber natürlich nicht anklickt!) und üblicherweise erscheint dann in der Fußzeile des Emailprogramms der volle Name des Links, zu dem man gehen soll. Wenn dort nicht der richtige Name der Firma erscheint, sondern irgend etwas ähnliches (manchmal auch nicht mal das) oder ein Abkürzungsdienst wie bit.ly, goo.gl etc., dann ist es zu 120% eine Phishing-Mail, auf die man nicht reagieren sollte.

Manche Firmen haben mittlerweile eine eigene Schädlingsbekämpfungsabteilung eingerichtet, an die man solche Mails weiterleiten kann. Wenn gefälschte Emails angeblich von amazon kommen, kann man diese Email an spoof@amazon.com weiterleiten. Andere Firmen haben eine Emailadresse der Form abuse@firma.com ("abuse" = "Mißbrauch") eingerichtet. Leider ist das nicht einheitlich, und es funktioniert auch nicht bei allen Firmen. Aber es kann einen Versuch wert sein, hier aktiv zu werden und wenigstens im Kleinen etwas zu unternehmen.

Mittlerweile schlagen auch Spam- und Phishing-Nachrichten in Messenger-Apps auf dem Smartphone auf. WhatsApp ist mittlerweile sehr beliebt bei bösen Buben. WhatsApp weist zwar darauf hin, dass der Absender nicht im Adressbuch ist, aber der Link in der Nachricht ist trotzdem anwählbar, wenn man die Nachricht anschaut. Leider gibt es Schadsoftware, die extrem ausgefeilt ist und sich dann dauerhaft im Smartphone einnistet. Dabei werden dieselben Tricks verwendet, die man auch zum "Rooten" oder "Jailbreak" des Handys verwendet - die Schadsoftware hat dann volle Administratorrechte, was manchmal mehr ist als der Besitzer selbst ...

Nach diesem etwas ausführlicheren Exkurs in die Welt der Schädlinge nochmals mein Fazit: auch mit einem Smartphone-Modell vom Vorjahr kann man gut leben. Die Geräte sind mittlerweile genau wie PCs so leistungsfähig, dass man nicht mehr das Topmodell haben muss, um vernünftig damit zu arbeiten. Software-Updates sind enorm wichtig, gerade weil diese Sorte Geräte dafür konzipiert sind, immer online und aktiv zu sein. Mit UMTS oder LTE sind sie recht breitbandig angebunden, d.h. ihr Internetzugang ist ziemlich schnell, und das alles in Summe ist ein sehr attraktives Ziel für Bösewichte, aus diesem "Internet in der Hosentasche" eine ferngesteuerte Drohne mit schädlicher Nutzlast zu machen. Ein Custom-ROM wie LineageOS kann hier Wunder wirken und das Gerät noch über Jahre hinweg aktuell halten.

Cyanogenmod auf dem Samsung Galaxy Nexus i9250 installieren

[Der Artikel ist schon älter. Ich habe Stichworte geändert, deswegen sieht das leider wieder wie ein neuer Beitrag aus]
Aus aktuellem Anlass musste ich mal wieder ein Telefon updaten.

Meine Frauen sind sehr destruktiv, was die Handys angeht: meine Tochter fällt mit Handy ins Wasser, oder fällt so unglücklich, dass das Display bricht, oder verliert das Handy im Kino, und meine Frau steckt das Handy in die Jackentasche und setzt sich dann drauf.

Fazit: ich kaufe nur noch gebrauchte Handys, bei denen es nicht so arg schmerzt, wenn sie kaputtgehen. Das zum Sitzkissen mutierte Handy, ein Galaxy S2, hatte mich keine 30 Euro gekostet, weil ich es aus Einzelteilen zusammensetzen konnte. Natürlich tut es trotzdem weh ;)

Diesmal habe ich mir ein Galaxy Nexus i9250 ausgesucht. Das ist ein immer noch sehr brauchbares Gerät, und man bekommt es sehr günstig. Die technischen Daten entsprechen in etwa dem Galaxy S3. Wie üblich bei Nexus-Geräten hat es keinen SD-Slot und ist damit auf 16 GB festgelegt. Macht aber nix, reicht für meine Frau voll und ganz, die sammelt keine Bildchen von Boy groups, bis der Speicher platzt ;-)

Das Installieren eines Custom ROMs ist bei Nexus-Geräten sehr schlicht. Man muss nicht "rooten", indem man eine Sicherheitslücke ausnutzt, sondern es gibt einen dokumentierten Weg, um das Telefon zu entsperren und wie üblich zuerst ein alternatives Recovery und dann ein alternatives ROM zu flashen.

Da die Nexus-Geräte ursprünglich als Geräte für Software-Entwickler geplant waren, die zügig die neueste Android-Version bekommen, stützt sich das Verfahren auf Tools, die im Android SDK enthalten sind. Man bekommt sie aber auch einzeln als Download; es ist nicht nötig, die neueste Version zu verwenden oder das volle SDK zu installieren.

Wenn man von Custom ROMs die Nase voll hat, kann man übrigens bei Google auch die Originale herunterladen und wieder flashen, z.B. wenn man das Handy mit dem Google-ROM weiterverkaufen will.

Die nächsten zwei Absätze sind nur von Belang, wenn man mit Windows geplagt ist. Für Linux- und Mac-Benutzer ist das nicht nötig, man muss nur evtl. dafür sorgen, dass das USB-Gerät 18D1:4E30 (Galaxy Nexus Fastboot-Interface) erkannt wird.

Das Galaxy Nexus hat leider eine Sonderstellung unter den Nexus-Geräten: die USB-Treiber für Windows werden von Samsung bereitgestellt und nicht von Google, und die Samsung-Treiber sind manchmal etwas zickig. Mein eigenes Gerät wurde auf Anhieb von Windows erkannt, das neu gekaufte erst beim dritten Anlauf, und ich musste ein paar Mal am Gerät zwischen PTP/MTP und USB-Debugging hin- und her schalten.

Wenn die Hürde mit dem USB-Treiber genommen ist, gilt es wieder, in mehreren Schritten zunächst ein alternatives Recovery-System zu installieren und mit Hilfe dessen dann das Custom ROM zu flashen.

Zunächst wird das Telefon entsperrt, damit das neue Recovery-System akzeptiert wird. Dieses Entsperren ist mit einem kompletten Löschen verbunden, also vorher alles sichern, auch die Bilder in DCIM  und alle anderen eigenen Daten! Ich empfehle Helium als Backupsoftware.

Auf dem PC nun die Images herunterladen, zum einen Clockwork Mod Recovery (es gibt zwei Varianten mit und ohne Touchscreen-Funktion) und zum Anderen Cyanogenmod mit den passenden Google-Apps (wenn gewünscht). Ich bevorzuge im Moment noch Android 4.3, die Optik von 4.4 gefällt mir eher weniger gut. Die Google-Apps starten zwar sofort ein Update, aber es ist trotzdem wichtig, dass die Grundversion genau zur installierten Android-Version passt.

Beide Lautstärketasten drücken und einschalten. Das Telefon startet nun im "Fastboot"-Modus, in dem es Flash-Inhalte entgegennimmt.

fastboot oem unlock

Nun am Handy bestätigen, dass es gelöscht werden kann.

Zum letzten Mal das alte Android-System starten und die beiden ZIP-Dateien für CM und Apps auf die "Interne SD-Karte" überspielen. Um die Sache zu beschleunigen, kann man auf das Anlegen von Google-Account etc. verzichten; es geht nur darum, die beiden Dateien auf das Telefon zu befördern.

Statt das alte Android nochmals zu starten, könnte man auch direkt nach dem Unlocken und Flashen des Recovery den Menüpunkt "install from sideload" anwählen. Dazu braucht man am PC dann den Befehl "adb sideload". Darüber schreibe ich ein anderes Mal.

Nun geht es daran, das neue Recovery zu flashen. Nochmals ausschalten  und in den Fastboot-Modus starten.

 fastboot flash recovery recovery-clockwork-6.0.4.7-maguro.img

Nun am Handy mit den Lautstärketasten anwählen "Reboot Recovery" und mit dem Einschaltknopf ausführen.

Im CWM-Recovery nun "wipe data" und "advanced -> wipe dalvik cache" anwählen - wie üblich.

Jetzt geht es zum Endspurt: "install zip" anwählen, dann "zip from internal SD card". Wenn das Nexus schon das Update auf 4.2 oder 4.3 hatte, wurde es intern mehrbenutzerfähig, d.h. es gibt Unterverzeichnisse "0" und "legacy". Falls die Zip-Dateien also nicht sichtbar sind, nochmals ein Verzeichnis tiefer gehen, dann sind sie nämlich unter "0" zu finden.

Zuerst das CM.zip und direkt danach die Google-Apps flashen lassen. Als letzten Befehl "reboot system" anwählen und die übliche Einrichtungsprozedur durchlaufen, dabei kann man einen Account bei Cyanogenmod einrichten oder es bleiben lassen. Wenn man einen Account dort hat, kann man ebenso wie beim Google Gerätemanager das Gerät bei Verlust "fernlöschen". Das ist Geschmackssache.

Das war's! Viel Spaß mit einem praxistauglichen Android auf einer immer noch richtig guten Hardware: Dualcore, 1.5 GHz, 4.65 Zoll mit 1280x720, 16 GB, davon ca. 13 GB nutzbar.

LineageOS 14.1 auf dem LG G4 (H815)

Die beste Ehefrau von allen wollte ein anderes Handy haben. Also hab ich mich auf die Suche gemacht mit den üblichen Auswahlkritieren, die ein paranoider Mensch halt so hat: es muss ein Custom-ROM unterstützen, das absehbar länger noch Updates bekommt. Die Alternative wäre ein aktuelles Google-Modell gewesen, also die letzte Generation Nexus oder eben ein Pixel. Nexus 5X oder 6 wären ok gewesen, das 6P und die Pixel-Varianten sind (noch) zu teuer.

In die engere Wahl kamen Motorola G4 Plus (ich bin mit meinem Moto G "falcon" der 1. Generation als Handy für die Firmen-SIM-Karte immer noch sehr zufrieden), Nexus 5X, Nexus 6 und in letzter Minute LG G4.

Wie man aus der Überschrift erkennen kann, ist es das LG G4 geworden. Das Motorola ist in der gewünschten Farbe und Speicherausstattung nur sehr schwer zu bekommen (32 GB weiß), das Nexus 6 wurde in der Hosentasche getestet und für zu groß befunden, und dann war es eigentlich eher Zufall, dass es nicht das Nexus 5X geworden ist.

Die Ausstattung ist ziemlich gut: 32 GB Speicher, 16 MP-Kamera und ein Bildschirm mit 2560x1440. Dazu 3 GB Arbeitsspeicher, eine Snapdragon 808-CPU mit 2 schnellen Kernen mit 1.8 GHz, 4 etwas langsameren mit 1.4 GHz und dazu ein Adreno-Grafikchip 418. Ich machte zuerst einen halbherzigen Versuch, das Original-Android von LG auszuprobieren. Aber nach der Grundeinrichtung stellte ich fest: die Icons sehen hässlich aus und Version 6.0 mit dem Security-Level Juli 2016 sind nicht akzeptabel. Also zack! Entsperren und LineageOS drauf. Etwas gewöhnungsbedürftig ist beim ersten Mal, dass der Einschaltknopf und die Lautstärketasten auf der Rückseite unter der Kameralinse liegen. Aber das ist gar nicht mal so unpraktisch, wie es sich zuerst anhört.

Installation von Custom-ROMs ist ähnlich umständlich wie beim Moto G: man muss auf einer Website die IMEI-Nummer und einen Gerätecode eingeben, den man im fastboot-Menü des Geräts abfragen muss, sich mit einer Emailadresse registrieren und dann bekommt man eine Binärdatei zugeschickt, die mit dem fastboot-Programm in einen speziellen Speicherbereich "unlock" des Geräts geflasht werden muss. Das Flashen ist aber auch erst möglich, wenn man den Entwicklermodus freigeschaltet hat und dann im dortigen Menü das Entsperren erlaubt hat. Dabei muss man mehrfach abnicken, dass man auf die Garantie verzichtet. Nicht weiter schlimm, das Gerät war sowieso schon knapp 'raus aus der Herstellergarantie.

Achtung: beim Unlock wird das Gerät komplett gelöscht, genau wie bei den Nexus-Geräten. Man sollte diesen Schritt also entweder sofort nach dem Kauf durchführen oder nach einem Backup aller Lieblingsdaten.

Ziemlich cool gelöst: wenn der Windows-PC, an dem man das G4 zum Entsperren anschließt, die USB-Treiber noch nicht installiert hat, mutiert das G4 für kurze Zeit zu einem CD-Laufwerk am USB-Port und Windows kann sich die MSI-Datei direkt vom Gerät holen. Nach der Installation verwandelt sich das G4 wieder zurück in das übliche MTP-Gerät. Auf dem einen verbliebenen Windows-PC in unserem Haushalt (mit Windows 7) ging das problemlos.

Die Installation von TWRP geht problemlos, die Anleitung auf twrp.me ist eine einfach geschriebene Schritt-für-Schritt-Anleitung. In einem ersten Schritt wird das Image von TWRP verwendet, um in das Recovery zu booten. Danach muss man dasselbe Image nochmals mit "adb push" auf das Gerät schieben und mit der Option "Image" ins Recovery flashen. TWRP empfiehlt, an dieser Stelle, nochmals das alte Android zu booten, um zu testen, dass das Recovery korrekt installiert wurde.

Allerdings dauert dieser Schritt recht lang, denn - wie oben bereits erwähnt - wird das Gerät komplett gelöscht und durchläuft damit erneut die Grundeinrichtung. Man muss erneut die Debugoptionen freischalten, den Key des PCs für den adb-Zugang erlauben und dann kann man erneut mit "adb reboot recovery" ins TWRP booten.

Nun ist es soweit: ein aktuelles LineageOS-zip und die (arm64!) OpenGApps mit "adb push datei /sdcard" auf das Gerät verfrachten, "Wipe" und danach "Install" aufrufen und die beiden zip-Dateien in einem Rutsch flashen. Wer möchte, kann auch gleich die root-Freischaltung durchführen und das entsprechende Extrapaket von LineageOS flashen, aber das muss jeder für sich selbst entscheiden. Pokémon z.B. droht immer mal wieder, gerootete Geräte vom Spiel auszuschließen. Auf jeden Fall ist es wichtig, Android und Google Apps direkt hintereinander zu flashen. Nur beim allerersten Systemstart bekommen die System-Apps alle Berechtigungen, die sie benötigen. Wenn man Android bootet und die Google Apps erst später in einem zweiten Durchlauf im Recovery flashen will, geht das schief.

Kleiner Fallstrick: die Open GApps werden als 64-Bit-Paket benötigt, also beim Download aufpassen, "ARM64" und die gewünschte Variante auszuwählen. Ich bevorzuge immer die "pico"-Variante, die nur den Play Store enthält. Alles weitere will ich mir einzeln aussuchen, auch wenn es dann den allgemeinen Speicher belastet und nicht in die Systempartition gespeichert wird. Natürlich kann man ein Handy auch komplett ohne Google betreiben, wie z.B. die c't beschreibt. Dann muss man sich halt einen alternativen App Store und Apps aussuchen, aber es gibt außerhalb von Google genügend Auswahl.

Zweite Erfahrungen mit LineageOS 14.1

Nach dem ersten Bericht folgt hier noch ein kurzes Update zum Thema Update.

Nachdem Google das Security-Bulletin für März veröffentlicht hat, wollte ich natürlich auch gern mit den Custom ROMs aktuell sein und die eingebaute Update-Funktion testen.

Beim AOSP-Build für das Nexus 5 war ich bislang eher unglücklich mit den Updates, allerdings könnte dies auch mein eigener Fehler gewesen sein: nach Forenempfehlungen sollte man in einem Rutsch nach dem Flashen des neuen ROMs auch die Google-Apps unmittelbar hinterher flashen, ohne vorher neu zu starten. Damit würden dann alle Berechtigungen passend gesetzt. Die Update-Funktion im AOSP-ROM hat bis dahin nie Updates gefunden, deshalb der manuelle Weg.

Nun ja, wenn ein weit verbreitetes Custom ROM wie LineageOS eine Update-Funktion anbietet, dann sollte die auch funktionieren. Kurze Zusammenfassung: so halb und halb.

Beim Nexus 5 absolut problemlos. Zuerst im Update-Bildschirm auf "Download" und dann auf "Installieren" drücken, wenn der Download beendet ist. Zack, fertig! Build NOF27B, also der Stand März 2017. Der kleine Fehler, dass man kein Profilbild beim Nutzerkonto abspeichern kann, ist immer noch vorhanden.

Beim Moto G nicht ganz so problemlos. Download hat funktioniert, aber nach dem Druck auf "Installieren" startet zwar das TWRP-Recovery, führt aber kein Update aus. Ich habe dann manuell in den Ordner (/data/data/org.lineageos.updater/app_updates) navigieren müssen, in dem LineageOS das Update ablegt, habe die Zip-Datei und vorsichtshalber (s.o.) auch noch mal die OpenGApps-pico-7.1 ausgewählt und geflasht. Nach dem Booten war alles ok, auch hier Build NOF27B vom 05.03.2017.

Mal schauen, ob das nächste Update mit der neuesten Version von TWRP (3.1) besser funktioniert.

Alles gut ;)

Erste Erfahrungen mit Lineage OS 14.1

Ich gebe zu, ich bin spät dran ;)

Nach längerer Zeit hab ich nun also auch nicht nur ein, sondern gleich zwei Geräte mit LineageOS, dem Nachfolger von CyanogenMod, geflasht, um es mir mal genauer anzuschauen.

Die Opfer waren ein älteres Nexus 5 ("hammerhead") mit 16 GB, das hier noch herumlag, weil meine Frau ein Gerät mit mehr Speicher wollte, und ein noch älteres Motorola Moto G (1. Gen, "falcon"). Ansonsten ist ein Nexus natürlich optimal, weil es bei den allermeisten Custom ROMs ganz vorne mit dabei ist - eben weil alle nötigen Files von Google veröffentlicht werden und man es ohne Klimmzüge entsperren und flashen kann. Ähnlich entspannt funktioniert das Custom-ROM-Flashen bei Motorola. Die einzige kleine Hürde ist, dass man zum Entsperren einmalig eine Webseite von Motorola aufsuchen muss, dort einen Code vom Handy eingeben muss und dann einen Freischaltcode zurückbekommt.

Der erste Versuch auf dem Nexus 5 nach dem Download war wenig erfolgreich - das Flashen verlief ohne Fehlermeldung und ich bekam zwar die Bootanimation von LineageOS zu sehen, aber nach etwa einer Stunde dachte ich mir, dass da irgendein Problem sein muss, und habe abgebrochen. Das Nexus 5 ist immer noch ein ziemlich aktuelles und vor allem schnelles Gerät, nicht wie damals das Motorola Milestone 2, bei dem der erste Bootvorgang 30 Minuten gedauert hat.

Beim nächsten Versuch, ins Recovery zu booten, stellte ich fest, dass irgendwie auch das Recovery kaputt gegangen ist. Also im Fastboot-Modus erst mal ein neues Recovery geflasht (TWRP), und dann ging das schon mal wieder ;)

Im nächsten Schritt habe ich erneut im Recovery den Nightly Build vom 28.02. und die OpenGApps (pico) geflasht. Diesmal war ich aber noch etwas konservativer und habe die Frage von TWRP verneint, ob ich vor dem Reboot auch SuperSU installieren will. LineageOS liefert ein eigenes Addon für SU-Funktionalität mit, und ich wollte es erst mal ohne alle Veränderungen versuchen.

Bingo! Dieser Versuch klappte auf Anhieb, und wenig später erschien der Einrichtungsassistent von Android Nougat. Lineage ist auf dem aktuellen Stand 7.1.1, Build NOF26W, Sicherheitsstand 05.02.2017.

Beim Moto G war gleich der erste Versuch erfolgreich, und nach einigen Minuten hatte ich auch hier die übliche Ansicht.

Bei den OpenGApps kann man sich aussuchen, wie umfangreich das Google-Paket sein soll, das man als Basissystem installiert. "pico" ist das kleinste Paket und enthält eigentlich nur die App für den Play Store; somit kann man später gezielt aussuchen, welche weiteren Google-Apps man haben will. Die größeren Pakete enthalten dann immer mehr, was gleich als System-App installiert wird. Je nachdem, wie groß die Systempartition ist, kann man also gar nicht alles installieren, was zur Auswahl steht, sondern muss ein "kleines" Paket nehmen und nachinstallieren. Diese nachinstallierten Apps  werden dann in den "normalen" Speicher des Telefons installiert.

Viele Features der bisherigen CyanogenMod-Versionen hat Google ohnehin auf die eine oder andere Weise übernommen, so dringend ist es mit Nougat nicht mehr, eine "Bells and Whistle"-Version von Android zu installieren. Auffällig ist, dass die "Themes" von CM verschwunden sind, es ist also nicht mehr so leicht möglich, z.B. eine angepasste Bootanimation zu verwenden.

Der eine Punkt, der mir bei meiner vorherigen "Custom" ROM aufgefallen ist, war die unzuverlässige Update-Methode. Ich hatte bislang auf dem Nexus 5 einen AOSP-Build, d.h. ein Android, das aus den offiziellen Quelltexten von Google gebaut wird. Nach keinem der Flashvorgänge konnte ich problemlos weiterarbeiten, ich bekam immer Fehlermeldungen, dass Google Play Services abgebrochen wird. Erst ein Factory Reset, d.h. Rücksetzen und Neueinrichten des Telefons, konnte das beheben. Für ein täglich genutztes Werkzeug ist so ein Verhalten natürlich indiskutabel, deshalb hoffe ich, dass die Updates von LineageOS sich problemlos(er) einspielen lassen.

Ich hatte neulich im Nexus 5-Thread zu AOSP-Nougat auf xda-developers gefragt, und da kam doch gerade eben eine Antwort mit einem Vorschlag: man soll beim Update nicht nur das AOSP-ROM, sondern auch noch die OpenGApps in einem Rutsch mit flashen, damit die Berechtigungen der System-Apps korrekt gesetzt werden, das würde nämlich nur beim ersten Booten nach dem Flashen gemacht. Alles in allem trotzdem sehr unschön: ein inkrementelles Update wie beim Nexus-Android wäre natürlich die schönste Lösung, und insbesondere viel kleiner. Die Updates, die ich bislang beim Nexus 5 erlebt habe, waren mit 10-20 MB pro Monat erfreulich klein.

Bislang funktioniert LineageOS bei mir schmerzfrei. Aufgefallen ist mir ein kleiner Fehler sowohl beim Nexus als auch beim Moto G: ich kann zwar bei den Benutzerkonten ein Bild für den Benutzer aussuchen, aber das "Speichern" speichert nicht, ich habe nach wie vor nur das abstrakte Platzhalterbildchen. Das kann ich verkraften ;)

Beim Motorola gibt es noch einen merkwürdigen Effekt: nach der Grundinstallation hatte ich mir einige der Google Apps aus dem Play Store installiert, darunter die aktuellste Version von Kalender, Kontakte und Telefon. Die mitgelieferten Apps von LineageOS hatte ich bei den Apps-Einstellungen deaktiviert. Beim Telefonieren mit einem "Direktwahl"-Widget konnte ich zwar telefonieren, aber die App wollte mir den üblichen Telefonbildschirm nicht anzeigen; somit konnte ich die Zahlentastatur nicht benutzen, stumm schalten, Lautsprecher, etc. Deshalb habe ich die Telefon-App wieder deinstalliert und mit der Version, die mit LineageOS mitkommt, funktioniert alles so, wie es soll.

Was mir im Vergleich zum Vanilla-Android immer noch besser gefällt, ist die Möglichkeit, die Statusleiste, die Benachrichtigungen und die Schnelleinstellungen bequem(er) anzupassen und die Icons rauszuwerfen, die man persönlich nicht braucht. Ich benötige z.B. die Icons für "Hotspot" und "Übertragen" gar nicht. Aber selbst diese Anpassungen kann man mit den normalen Android erreichen. Wenn man nämlich lang auf das Einstellungen-Zahnrad drückt, kann man den "System UI Tuner" aktivieren, und mit dem kann man ebenfalls diese Icons bearbeiten.


Hingegen gefällt mir der Standardlauncher von CM und LO seit den letzten zwei Versionen gar nicht mehr, die Icons in Ordners extrem verkleinert anzuzeigen statt sie mit 3D-Effekt hintereinander zu stapeln. Deswegen ist der erste Handgriff dann auch, auf den Google Now-Launcher umzustellen - der ja leider nun auch eingestellt wird. Der Launcher3 des AOSP-Projekts sieht ziemlich gut aus, alternativ gibt es mittlerweile auch den Pixel-Launcher im Play Store, und jede Menge weitere Alternativen für jeden Geschmack.

Auf jeden Fall ist ein Custom ROM, egal ob es AOSP, LineageOS oder ein anderes ist, immer noch eine gute Möglichkeit, sein Schätzchen auf dem neuesten Sicherheitsstand zu halten, selbst wenn Google die Auslieferung von Updates im Dezember 2016 für dieses Modell eingestellt hat. Eigentlich ist das schade - die Patches werden von Google bis zurück zu 4.4 ins AOSP-Repository eingepflegt (soweit das technisch möglich ist), und die Build-Maschinerie könnte weiterhin das Nexus 5 mit Marshmallow-Updates auf dem aktuellen Sicherheitsstand versorgen.

Cyanogenmod 13 Marshmallow auf dem Galaxy S2

Seit einiger Zeit gibt es Nightlies, und kürzlich auch die Meldung über die ersten "echten" Releases von CyanogenMod Version 13, das auf Marshmallow, also Android Version 6, basiert.

Da ich immer noch ein paar alte Galaxy S2 zum Basteln und Experimentieren verwende, wollte ich mir die neueste Version natürlich gleich anschauen. Es gibt tatsächlich Enthusiasten, die für das S2 (i9100) noch neue Android-Versionen zusammen bauen.


Also ein Nightly heruntergeladen und gleich ganz mutig auf das Smartphone in den Ordner cmupdater geworfen. Danach in den Einstellungen "CyanogenMod-Update" angewählt, auf den Eintrag für CM 13 getippt, gewartet, und zack!, hatte ich CM 13 auf dem Gerät.

Das ging eigentlich ganz gut - ich war nur etwas überrascht, dass das fertig eingerichtete S2 plötzlich kein Google-Konto mehr hatte. Das Gerät war eigentlich vom letzten Update auf Lollipop noch mit einem Testkonto angemeldet, aber das war plötzlich weg.

Auch ein Factory Reset half nicht - danach hatte ich gar keine Google Apps mehr auf dem S2.

Generell denke ich mittlerweile, dass man bei einem Umstieg auf eine komplett neue Release-Version (5 -> 6) einen Factory-Reset machen sollte. Die internen Strukturen ändern sich so stark, dass man sich versteckte Probleme einhandelt, die man kaum selber finden und reparieren kann. Innerhalb einer Version (6.0 -> 6.0.1 etwa) funktioniert das Update problemlos ohne Neueinrichtung.

Etwas Forschen und Nachlesen brachte dann einige gravierende Veränderungen zutage, auf die ich prompt hereingefallen bin. Vielleicht sollte ich erst lesen und dann ausprobieren. Aber andersherum macht es mehr Spaß ;)

Eine der Veränderungen hatte ich mit Lollipop schon erledigt: die /system-Partition hatte ich damals schon mit Odin und einer .pit-Datei vergrößert, weil die vorhandenen 500 MB nicht mehr für CM 13 und die Google Apps ausreichen. Man sollte mindestens 1 GB vorsehen. Wenn man die komplette Google-Apps-Sammlung vorinstallieren will (in die Systempartition) sollte man 2 oder 4 GB einplanen. Das geht dann natürlich wieder zu Lasten des freien Speichers für Apps, Daten, Bilder, Musik etc. Kann man sich überlegen ;)

Aber eine andere Veränderung hat mir ein Bein gestellt: Cyanogenmod bringt jetzt ein eigenes Recovery mit, das bei jedem Update das bisherige Recovery ersetzt. Und das CM-eigene Recovery schafft es nicht, die Google Apps von opengapps.org zu installieren. Es erscheint eine sehr gut lesbare Fehlermeldung in dunkelblau auf schwarz (oder bin ich nur mittlerweile zu alt für sowas?), dass man TWRP als Recovery nehmen muss, um die opengapps zu installieren.

Erschwerend beim S2 und einigen anderen Galaxy-Modellen ist nun, dass es kein separates Recovery-Image zum Flashen gibt - das Recovery ist mit dem Linux-Kernel zu flashen. Es gibt zwar eine Recovery-Partition im Speicher des S2, aber die wird nicht verwendet. Alles ein wenig seltsam, aber damit muss man wohl leben ...

Der Ablauf, um ein funktionsfähiges S2 mit CM 13 zu erhalten, sieht also so aus:

Herunterladen und Flashen eines Linux-Kernels für das S2 mit einem aktuellen TWRP-Recovery. Dazu verwendet man das "isorec"-Projekt. TWRP selbst ist wegen der Geschichte mit dem Kernel (s.o.) zickig und baut selbst keine Pakete für Samsung Galaxy mehr.

Das Flashen dieses Paketes führt man am besten per "adb sideload" durch. Um das erfolgreich durchzuziehen, braucht man eine Minimalinstallation der Google Android Developer-Tools, von denen "adb" ein Teil ist. Es gibt aber auch Minimalpakete, die nur ein lauffähiges "adb.exe" mit ein paar Windows-DLLs enthalten.

Wichtig ist, dass man auf dem S2 bei einem laufenden Android in den Entwickleroptionen den Debugmodus aktiviert, damit S2 und PC sich über USB anfreunden und man den Schlüsselaustausch zwischen den Geräten bestätigen kann. Ansonsten kann man mit adb keine Dateien übertragen, wenn man im Recovery "sideload" anwählt. Beim Befehl "adb devices" erscheint dann "unauthorized" und es geht nicht weiter.

Wenn man das TWRP-Recovery geflasht hat, kann man mit "adb reboot recovery" gleich in dieses Recovery wechseln. Im TWRP wählt man nun unter "Advanced" den Punkt "ADB sideload" an, markiert die beiden Kästchen unter "wipe flash/wipe dalvik" und wischt dann zur Bestätigung den blauen Schalter nach rechts.

Nach dem Flashen eines neues Recovery-Image könnte man übrigens mit "Triangle Away" das gelbe Warn-Dreieck vom Samsung-Startbildschirm entfernen.

Jetzt wird es umständlich:
man muss in der richtigen Reihenfolge die heruntergeladene zip-Datei von CM 13 mit "adb sideload" installieren, danach die gewünschte Version der opengapps (pico, nano, micro,  etc. - je nachdem, welchen Umfang von Google Apps man vorinstallieren möchte), und danach muss man nochmals das TWRP-Recovery flashen, weil mit CM 13 ja das CM-interne Recovery mitkommt, dass das vorhandene TWRP-Recovery gerade wieder überschrieben hat.

Nach jedem "adb sideload" kehrt man mit der "<--"-Taste auf dem Touch-Screen wieder einen Schritt zurück, wählt erneut "ADB sideload" an und  wischt zum Aktivieren. Dann erneut auf dem PC den nächsten "adb sideload"-Befehl eingeben.

Es ist wichtig zu wissen, dass dadurch der "adb sideload" ebenfalls gerade wieder kaputtgegangen ist, und man das im Debugmode wieder neu autorisieren muss.

Als Erfolg zeigt sich nach dem Booten und der üblichen Wartezeit mit dem CM-Gesicht und dem "Optimieren der Apps ... x von y" unter den Eigenschaften so etwas Ähnliches wie hier rechts.

Es ist übrigens empfehlenswert, im Entwicklermenü dann den Schalter "CM recovery aktualisieren" zu kontrollieren und auszuschalten, damit man nicht nach jedem CM-Update erneut auch TWRP wieder flashen muss.

Außerdem habe ich die Beobachtung gemacht, dass das CM-Recovery nicht von der eingesteckten SD-Karte (sdcard1) installieren kann, es springt nach dem Anwählen sofort zurück ins Recovery-Hauptmenü.

[Update 20160412]
Nachtrag zum Thema "TriangleAway": die derzeitigen Nightlies von CM 13 haben ein Problem, Root-Zugang zu gewähren. Es ist nicht möglich, TriangleAway zu starten. Auf einem der S2 bin ich von Factory 4.1.2 direkt auf CM 13 gegangen, und TriangleAway funktioniert nicht. Auf einem zweiten hatte ich zuerst das Update auf CM 12.1 ausprobiert, und unter 12.1 funktioniert der Root-Zugriff. Derzeit ist es also eine Überlegung wert, das Update in zwei Schritten durchzuführen, zuerst auf CM 12.1, dann TriangleAway aufzurufen, und danach wie oben beschrieben das Update auf CM 13.

Galaxy S2 mit Cyanogenmod 12.1 installieren und Partitionen ändern

Heute war so ein Tag, an dem ich etwas in Schwitzen gekommen bin, weil ich etwas Neues ausprobieren wollte und mir nicht ganz sicher war, ob es funktionieren würde. Dummerweise wusste ich erst mittendrin während des Updates, dass ich etwas Gefährliches tun muss, damit das Update richtig funktioniert ...

Gute Nachricht vorneweg: alles hat gut funktioniert, ich konnte mir den Angstschweiß abwischen ;). Hier ist ein Beweisfoto:

Aber mal von vorn: da ich noch einige Galaxy S2 zum Testen und Ausprobieren daheim herumliegen habe, und auch noch genug Ersatzteile wie Mainboards und Kleinteile, wollte ich eins davon mit Android 5.1.1 installieren und das aktuellste Cyanogenmod 12.1 drauf werfen.

Also gesagt, getan: erst mal ein halbwegs aktuelles CM 12.1 für i9100 heruntergeladen und ein bißchen Informationen gesammelt, was noch zu tun ist. Dabei habe ich gelernt, dass es empfehlenswert ist, einen für Lollipop angepassten Kernel mitsamt aktuellem Recovery zu flashen. Bei Samsung wird das Custom Recovery zusammen mit einem Kernel geflasht, hier gibt es von verschiedenen XDA-Entwicklern fertige Pakete aus Linux-Kernel und Lollipop-geeignetem Recovery.

Wenn dieser Schritt getan ist (mit Odin als "PDA" flashen), kann man mit dem Samsung-üblichen Dreifingergriff das S2 in den Recoverymodus versetzen und die Zipdatei mit CM 12.1 installieren, und danach wie üblich ein Paket Google-Apps.

Hier hat sich viel für die Bequemlichkeit getan, seit ich das letzte Mal Google Apps herunterladen musste: es gibt ein cooles Projekt bei GitHub, das verschiedene Pakete anbietet, vom Minimalpaket mit gerade mal der Play Store-App ("pico"), über ein Mikro-Paket, das dann schon GMail, GKalender und einige Kleinigkeiten mehr enthält, bis hin zum "Super"-Paket, das wirklich alles enthält, was jemals bei Google aus dem Compiler geworfen wurde.

Das Flashen von CM 12.1 lief wie erwartet glatt, aber dann bekam ich einen kräftigen Schreck beim Flashen der Google-Apps: eine Fehlermeldung "#70" mit eher beunruhigenden Meldungen. Beim Nachschauen in der FAQ des OpenGApps-Projekts stellte ich dann fest, dass die Partition des Speichers im S2, das die System-Apps enthält, nur knapp 600 MB groß ist, und dies nicht ausreicht, um die Google Apps zu installieren. Bislang hat es immer funktioniert, aber Lollipop scheint etwas sehr stark gewachsen zu sein, und nun passten die Google Apps nicht mehr dazu. Das Booten lief trotz des Fehlers beim Flashen einwandfrei, es war also nichts lebenswichtiges zerstört oder unvollständig. Puh!


Mit ein wenig Forschen fand ich heraus, dass es leicht möglich ist, die Partitionsaufteilung des S2 zu verändern, damit die Systempartition mehr Speicherplatz erhält - natürlich zu Lasten des restlichen Telefonspeichers. Bei einem Bastelgerät mit 16 GB Ausstattung ist das natürlich kein allzu großes Problem, und selbst wenn man so ein Gerät dann als Alltagswerkzeug verwenden will, bleibt immer noch die Möglichkeit, eine 32 GB-Speicherkarte zusätzlich einzubauen.

Die Neupartitionierung kann man entweder manuell mit "adb shell" im Root-Modus durchführen und direkt am offenen Herzen des S2 mit dem "parted" Partitionseditor die Größen verändern, oder man verändert die Partitionen mit einem Hilfsprogramm wie Heimdall (für Linux und Windows) oder Odin (nur Windows), das eine Konfigurationsdatei mit der Endung ".pit" verwendet, um den Vorgang zu automatisieren.

Ich war wenig mutig und habe Odin verwendet, nachdem ich mir aus einer Auswahl von fertig vorbereiteten ".pit"-Dateien die ausgesucht habe mit 4 GB für system und den Rest für Daten.

Danach muss im Recoverymodus die Systempartition, die Datenpartition und die simulierte Speicherkarte (üblicherweise "sdcard0" genannt) neu mit einem Linux-Filesystem formatiert werden. Ich empfehle "ext4", das ist erprobt und zuverlässig. Dabei gehen natürlich alle Daten verloren! Es ist also schlau, ein Backup der vorhandenen Inhalte zu machen (Bilder in DCIM usw.). Die Zipdateien für CM 12.1 und die Google Apps sollte man auf eine SD-Karte packen und als externen Speicher ins Telefon stecken. Beim S2 geht das ja, im Gegensatz zu den sonst von mir bevorzugten Nexus-Geräten, die prinzipiell keinen SD-Steckplatz haben.

Genauer gesagt läuft es so ab: unter "advanced" kann man /system, /data, /cache, und /storage/sdcard0 formatieren und dann mounten.

Danach werden mit "install zip" die Zipdatei von CM 12.1 und die Zipdatei der Google Apps installiert und neu gebootet. Die Frage nach dem "fix root" sollte man mit "yes" beantworten, schließlich will man hinterher noch mit "TriangleAway" das lästige gelbe Dreieck beseitigen, mit dem Samsung anzeigt, dass man einen unsignierten Kernel geflasht hat ;). TriangleAway benötigt root-Zugriff. Den muss man im Entwicklermenü dann auch erst aktivieren, CM 12.1 hat den Rootzugriff prinzipiell abgeschaltet, und man muss als Entwickler dann z.B. "Nur Apps" einschalten - oder auch "Apps und ADB", wenn man als Entwickler mit den adb-Befehlen als root arbeiten können will.

Der erste Start des neuen Android-Systems dauert ziemlich lang, weil wie üblich die Java-Dateien in den APK kompiliert und gecache't werden müssen. Seit Lollipop verwendet Android ein neues Verfahren zum Kompilieren und Cache'n, nämlich "ART" und nicht mehr "Dalvik". Dies ist nicht nur aus Performancegründen, sondern auch dem Patentstreit mit Oracle geschuldet. Genauer gesagt ist ART seit Kitkat, also Android 4.4 enthalten, aber nicht als Standardverfahren eingerichtet, und Cyanogenmod hat ausdrücklich erklärt, dass ART auf CM 11 nicht verwendet werden soll. Diese Aussage ist korrekt, ich habe es ausprobiert und hatte permanenten Abstürze der Apps.

Nach dem ersten Start sollte man aus dem Play Store oder von der Speicherkarte TriangleAway installieren. Falls die App nicht aus dem Play Store geladen wird, muss man in den Einstellungen die "unbekannten Quellen" erlauben. TriangleAway lädt einen handgeschnitzten Kernel nach, der genau zum Handymodell passt, startet das Telefon neu, und dann kann man mit der Lautstärketaste "Hoch" den "Flashcounter" wieder auf 0 setzen, damit das lästige gelbe Dreieck nicht mehr auf dem Einschaltbildschirm angezeigt wird.

Da sich der Installationsvorgang bei CM gelegentlich mal ändert, sollte man unbedingt in den Einstellungen einrichten, dass beim Flashen einer neuen CM-Version auch das aktuelle Recovery mit installiert wird. Diese Einstellung findet sich bei den Entwickleroptionen, die man erst sichtbar machen muss. Dazu im Menü "Über das Telefon" siebenmal auf die Buildnummer tippen.

Puh, das war Stress! Wenn man am Partitionslayout herumfummelt, kann es unter Umständen auch böse enden, wenn man eine der Partitionen beschädigt, die das Telefon für die ersten Phasen des Bootvorgangs - vor dem Laden des Linux-Kernels - benötigt. Also auf keinen Fall an den Partitionen für "SBL", "Radio", "Factory" usw. herumfummeln.

[Update 20151204: Links zu Custom Kernels nachgetragen]

Nochmal Cyanogenmod für das Samsung S+ i9001 - aber anders

Wie schon neulich erwähnt, sind meine Kinder recht destruktiv mit ihren Handys, und Kind 2 macht da keine Ausnahme, er versucht derzeit, Kind 1 einzuholen.

Er hat es geschafft, das Samsung S+ so elegant zu biegen, dass das Display kaputt ist, aber das Glas intakt - auch schon eine Kunst.

Der Ärger ist natürlich da, aber der finanzielle Verlust ist nicht ganz so groß wie beim verlorenen iPhone 5 von Kind 1. Das S+ hat bei einem ebay-Händler nur knapp 60 € gekostet.

Das Handy hatte sogar noch eine ältere Android-Version als das erste i9001, das ich im Frühjahr zum Geburtstag des Lütten beschafft hatte. Damals war es 2.3.5, dieses kam mit 2.3.3 zu mir.

Beim Aufladen vor dem Neu-Flashen erst mal Schreck: ein Warnsymbol neben dem Akku. Da ich das alte Handy noch hatte, konnte ich den Akku auswechseln und war wieder beruhigt. Es war wirklich nur der Akku und nicht die Ladeelektronik im Handy wie beim Wasserschaden in einem S2 von Kind 1.

Nach dem Aufladen ein bißchen Herumspielen mit der alten Android-Version und die wohlige Gänsehaut genießen bei dem Gedanken, dass es bald die fast noch aktuelle 4.3.1 bekommen wird ;)

Nachdem ich eine SD-Karte mit dem passenden Custom Recovery, Custom ROM und den Google Apps für Android 4.3 eingebaut hatte, wollte ich den Samsung Recovery Mode starten, um zunächst ein anderes Recovery zu flashen, mit dem es dann möglich ist, ein Custom ROM zu flashen.

Merkwürdigerweise ließ sich zwar so etwas ähnliches wie ein Recovery Modus starten, aber dort gab es kein Menü, um andere Software zu installieren, sondern nur eine kleine Grafik mit einem Pfeil und einem kleinen grünen MännchenAndroiden. Vielleicht lag es auch nur an meinen dicken Fingern, dass ich immerzu den Zeitpunkt verpasste, nach dem Einschalten die Menü-Taste zu drücken, um ins Recovery zu gelangen. Schwer zu sagen ;)

Also eine andere Idee entwickelt: im Play Store gibt es eine App "ROM Manager", die einen Menüpunkt "Reboot to Recovery" beinhaltet. Damit sollte es möglich sein, ohne langwieriges Gefummel ins Recovery-Menü zu gelangen.

Aber natürlich war es nicht ganz so einfach: der ROM Manager erfordert ein gerootetes Handy, weil die Änderungen am Bootloader tiefe Eingriffe erfordern.

Nächste Frage also: wie rootet man ein i9001? Es gibt mehrere Verfahren, das bequemste ist das "Kingo Root Tool", das eine ganze Menge Handys erkennt und rooten kann. Dieses Tool war auch bei mir erfolgreich.

Danach konnte der ROM Manager das Recovery starten, ich konnte das gewünschte Custom Recovery flashen und danach ging es recht zügig, das ROM mit CyanogenMod und die Google Apps auf's Handy zu bringen.

CyanogenMod-Basteleien - Samsung Galaxy S plus i9001

Heute morgen brachte der Postbote mal wieder neue Hardware für weitere Basteleien, diesmal hatte ich mir recht spontan für kleines Geld ein Samsung Galaxy S plus i9001 ausgesucht.

Die Bedienung ist sehr angenehm, und die Geschwindigkeit des Telefons reicht allemal für Android 4.3. Ich bin sehr zufrieden, das einzige, was ich vermisse, ist eine Fotoleuchte.

Über die Hardware hatte ich mir vorher wenig Gedanken gemacht - obwohl es haptisch und numerisch sehr nah an einem meiner alten Lieblinge - dem i9000 - liegt, hat es vollkommen unterschiedliche CPU (Qualcomm MSM8255T mit 1,4 GHz statt Samsung S5PC110 mit 1 GHz) und GPU (Adreno 205 statt PowerVR SGX540). Im Gegensatz zum Galaxy S "advance" ist es nach wie vor eine Single-Core-CPU, kein Dual-Core.

Die unterschiedlichen CPUs/GPUs bedeuten natürlich auch, dass man nicht die Custom-ROM-Dateien vom i9000 nehmen darf.
Ich habe mir die Dateien von hier heruntergeladen (ich mag als Recovery das CWM, TWRP geht aber genauso gut, reine Geschmackssache ...). Das CM-ROM hat den Zusatznamen "ION". Außerdem benötigt man noch die Google-Apps für Jelly Bean 4.3.

So ein schnelles ROM-Update hatte ich bisher noch nicht, wow ;). Obwohl es ein Samsung-Gerät ist, habe ich kein Odin benötigt, sondern konnte das Custom-Recovery (CWM) sogar mit dem Stock-Recovery installieren.

Ursprünglich kam das Gerät mit Android 2.3.5, der Händler hatte nichtmal die Daten des Vorbesitzers gelöscht, ganz schön peinlich. Genauso dämlich aber natürlich vom Vorbesitzer, seine Daten und Fotos nicht selbst zu löschen, bevor er es endgültig aus der Hand gibt ...

Ich habe die drei benötigten Dateien für das Custom-ROM zunächst auf eine SD-Karte überspielt und ins Handy gesteckt. Danach muss man letztmalig das Samsung-Android starten, und mit dem Dateimanager "Eigene Dateien" die Dateien von der SD-Karte (zu finden unter external_sd) auf den internen Speicher zu verschieben. Das ist nötig, weil das Samsung-Recovery, das wir ersetzen wollen, nur vom internen Speicher installieren kann, aber nicht von SD-Karte.

Im Gegensatz zum S2 wird der Recovery-Modus aufgerufen, indem man beim Start nur Lautstärke-hoch und den Einschaltknopf drückt. Man darf nicht die Home-Taste drücken, sonst gelangt man in einen "RAM-Dump"-Modus, der hier nicht weiter interessiert.

Nachdem der Schriftzug "SAMSUNG" auf dem Bildschirm erscheint, die Knöpfe noch einen Moment gedrückt halten und dann die Menü-Taste (links neben der Home-Taste) drücken, bis sie aufleuchtet. Dauert alles einen Moment, aber keine Panik!

Im Recovery-Modus dann nacheinander "wipe data", "wipe cache", "install zip" aufrufen. Bestätigt wird mit der Menü-Taste (links). Zunächst zum ZIP für das CWM-Recovery navigieren und auswählen. Bestätigen wie gesagt mit der Menü-Taste, der Einschaltknopf geht einen Schritt zurück. Die Installation geht recht fix, die Datei ist ja auch nicht besonders groß. Danach "Reboot" auswählen und den Ablauf nochmal von vorne, bis das "neue" Recovery erscheint.

Jetzt nacheinander die beiden ZIP-Dateien für das CyanogenMod-ROM und die Google-Apps anwählen und bestätigen. Danach vorsichtshalber nochmals "wipe data", "wipe cache", "advanced" -> "wipe dalvik cache", und dann "Reboot system" auswählen.

Auf dem Startbildschirm unter dem Samsung-Logo müsste jetzt schon etwas zu sehen sein: nämlich das Logo der Entwickler "AriesDev" und darunter das CM-Logo.


Wie üblich dauert der erste Start recht lang, um die Apps auszupacken, zu untersuchen und zu optimieren ("odex"). Danach kommt der übliche Anmeldevorgang zu CM und zu Google, und dann geht es ans Einrichten des neuen Androiden mit 4.3.1 ;)