CyanogenMod: Die Custom ROM für Android erklärt

Android stammt von Google. Doch wer will, kann sich auch sein eigenes Android-System bauen. Das populärste alternative Android-System stammt vom CyanogenMod-Team. Wir stellen die Firmware vor.

Sicher hat schon fast jeder Leser den Begriff CyanogenMod [1] gehört. Es ist eine spezielle Version von Android, die Sie auf Ihrem Handy installieren können. Die Entwickler nenne das ROM oder Firmware. Aber was steckt dahinter? Was für Erfahrungen und Philosophien prägen diese Android-Version? Diese Fragen möchte der Autor hier beantworten – seine Eindrücke sind dabei persönlich und im Laufe der letzten drei Jahre beim Umgang mit CyanogenMod und den Menschen dahinter entstanden.

ROM, Firmware, Android

Erst einmal ist CyanogenMod eine Android-Firmware. Ein Betriebssystem, welches man auf seinem Android-Telefon installieren kann. Solche Android-Firmwares machen auch Samsung, HTC, Sony, LG, Huawei und natürlich auch Google. Diese Hersteller arbeitet aber immer nur an ihren eigenen Geräten (bei Google sind es die Nexus-Geräte) und die Firmware ist meistens nicht komplett frei verfügbar. CyanogenMod ist für alle Handys und Tablets offen.

Da die Arbeit des CyanogenMod-Projekts Open Source ist (also unter einer freien Lizenz steht), kann jedermann sein eigenes CyanogenMod erstellen, eigene Veränderungen hinzufügen, Funktionen aus anderen ROMs einfügen oder das Projekt auf exotische Geräte portieren. Diese Dinge unterliegen nicht der Kontrolle des CyanogenMod-Projekts, und werden daher als „Unofficial“ – manchmal auch KANG – bezeichnet. Eine Liste der verschiedenen Versionen von CyanogenMod finden Sie am Ende dieses Artikels.

Die Macher von CyanogenMod können ihre Firmware nur deshalb anbieten, weil Google den (exzellenten) Source Code frei zur Verfügung stellt. Dieser Code wird auch als AOSP – Android Open Source Project – bezeichnet [2]. Fast alle Android-ROMs basieren auf dem Quelltext des Android Open Source Projekts – auch CyanogenMod gehört dazu. Allerdings lässt sich der von Google halbjährlich veröffentlichte Quelltext ohne Änderungen – wenn überhaupt – nur für die neueren Nexus-Geräte in eine ROM übersetzen.

Hier kommt das CyanogenMod-Team ins Spiel: Die Entwickler portieren den Code auf die von ihnen betreuten Geräte. So bieten das Projekt für Telefone, die vom Hersteller schon lange vergessen wurden, das neueste Android an. Aktuell sind das 50 Geräte, die mit der neuesten Version 10.1 RC5 basierend auf Android 4.2 arbeiten [3]. Prominentes Beispiel hierfür ist das nun schon 3 Jahre alte erste Samsung Galaxy S (i9000) – auf diesem läuft das neueste Android 4.2.2 – und das erstaunlich weich und flüssig bei Scrolling und Task Wechsel. Die neuste Samsung ROM für dieses Gerät von Ende 2012 basiert auf Android 2.3. Wie Sie Ihr Galaxy S i9000 mit CyanogenMod 10.1 wieder fit machen, zeigt unser separater Artikel in der Fokus-Strecke dieser Android-User-Ausgabe.

Die Philosophie

Das CyanogenMod Team hat aus den Erfahrungen der letzten Jahre einige Philosophien entwickelt, die es bei der Arbeit am System berücksichtigt. Zum einen benutzen die Entwickler eine gemeinsame Quellcode-Basis für alle Geräte. Das bedeutet, dass Änderungen für ein einzelnes Gerät die anderen nicht in Mitleidenschaft ziehen dürfen. Kommt dies mal wieder vor, muss ein Weg gefunden werden, der allen Geräten gerecht wird. Dies zwingt das Team, keine Kompromisse für einzelne Geräte einzugehen, sondern alle Probleme sauber zu lösen. Daraus entsteht beim CyanogenMod-Projekt am Ende ein klarer Vorteil gegenüber ROMs, die nur für ein einzelnes Gerät entwickelt werden und Probleme vielleicht schneller aber dafür unsauber lösen.

CyanogenMod nimmt auch Anpassungen am Erscheinungsbild des Systems vor, und fügt neue Funktionen ein oder erweitert existierende. Der Sperrbildschirm, die Status Leiste oder das Ein-/Aus-Tasten Menü sind populäre Beispiele. Dabei haben die Entwickler aus alten Versionen gelernt. CM7 beinhaltete noch eine Flut an Optionen, über die am Ende weder Entwickler noch Anwender den vollen Überblick hatten. Schlimmer noch: Es gab Optionen, die nur vereinzelt verwendet wurden, aber für jeder Nutzer die Options-Dialoge aufblähten.

Deshalb hat man mit CM9 einige Grundlegende Änderungen eingeführt. Zum einen gibt es nun ein UX Team (User eXperience – meint alles womit der Benutzer interagiert) innerhalb des Projekts, das auch aus Nicht-Programmiern besteht. Jeder Patch aus diesem Bereich wird darauf überprüft, ob er sinnvoll ist und von grob geschätzt 10% der CyanogenMod-Benutzer genutzt werden würde.

Da sich das Projekt streng am Quelltext von Google als Leitfaden orientiert, dürfen solche Änderungen diese Grundfunktionalität nicht in Mitleidenschaft ziehen und müssen sich nathlos einfügen – zumindest so lang es nicht gute Gegenargumente gegen den ursprünglichen Entwurf von Google gibt. Bei der Funktion der Schnelleinstellungen von 4.2 ist das CyanogenMod-Team zum Beispiel bewusst leicht andere Wege gegangen.

Abgelehnt werden Änderungen, die aus Sicht des Teams keinen Sinn machen, oder die grafische oder funktionelle Art des Google-Systems zu sehr verändern. Ein Beispiel ist die zentrierte Uhr in der Statusleiste. Dieser Patch schränkt die Anzahl der sichtbaren Benachrichtigungen stark ein – besonders auf Geräten mit geringer Auflösung. Zusätzlich erfordert es eine Option, die keinen wirklichen Funktionsgewinn mit sich bringt. Daher wird dieser –immer wieder neu eingereichte – Patch seit CM9 konsequent abgelehnt. So wird jeder Patch der Veränderungen an der Benutzerschnittstelle mit sich bringt, genauestens geprüft, damit CyanogenMod weiterhin ein schlankes, schnelles System bleibt, das sich möglichst nahe am Original orientiert.

Für Mami und Papi

Eine der Hauptanforderungen der Entwickler besteht darin, dass die Firmware, die am Ende entsteht, auch von ihrer Mutter gut benutzbar sein soll (oder von Oma und Opa). Andere Projekte wie Android Open Kang Project [4] oder Paranoid Android [5] haben andere Ansätze, und erlauben Funktionen, die CyanogenMod nicht integrieren möchte. Die Zusammenarbeit dieser drei AOSP-basierten Projekte ist in der letzten Zeit aber immer enger geworden, und es kommt zu einem regen Tausch von Quelltext – so lang die Neuerungen Sinn für das jeweils andere Projekt machen.

Für den Anwender bietet sich mehr Auswahl als noch vor ein paar Jahren. Die drei genannten ROMs sind für eine stetig wachsende Zahl von Geräten verfügbar. Zusätzlich gibt es meist noch einige Hersteller basierte ROMs, die zum Beispiel HTC Sense oder Samsung TouchWiz erweitern, und letztlich noch Googles unmodifiziertes System. Pro Gerät also bis zu fünf verschiedene Arten von grundlegend verschiedenen Systemen. Das freut auch das CM-Team, denn der User kann sich heraussuchen, was am besten zu ihm passt, und er ist nicht auf die offizielle Unterstützung oder den Segen seines Geräte-Herstellers angewiesen.

Warum Version 10.1?

Sie mögen sich fragen, wie eine Version 10.1 zustande kommen kann. Android Versionen von Google sind alphabethisch benannt. C wie Cupcake, D wie Donut, E wie Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich und aktuell Jelly Bean. Die Hauptversionsnummer von CyanogenMod entspricht der Stelle des von Google gewählten Buchstabens im Alphabet. Gingerbread wurde so zu CM7 und Ice Cream Sandiwch zu CM9. Ein CM8 für Honeycomb gab es nie, da Google den Quellcode zunächst nicht freigegeben hatte. Die Nummer hinter der Hauptziffer steht dann für die Unterversion: Sowohl Android 4.1 als auch 4.2 heißen JellyBean. Daher gibt es CM10 (eigentlich 10.0) für JellyBean 4.1 und CM10.1 für JellyBean 4.2. Da laut Gerüchten wohl auch die nächste Version 4.3 noch JellyBean heißen wird, gibt es dann passend dazu CM10.2

Welche Version wählen?

Die verfügbaren Versionen von CyanogenMod können Außenstehenden Rätsel aufgeben. Daher hier eine kurze Erläuterung.

Jeder Patch (Änderung an der Software), der in den Quelltext eingeht, wird allen Entwicklern zur Begutachtung und Diskussion zur Verfügung gestellt [6]. Diesen Vorgang nennt man Code Review. Die Diskussion kann bei großen Änderungen auch Wochen dauern und mehrere Verfeinerungen beinhalten – sowohl in Funktion als auch in Quellcode Stil. Am Ende wird das finale Ergebnis mit allgemeinem Einverständnis in den Quellcode integriert, und steht ab dem nächsten Nightly Build für alle Geräte zur Verfügung.

• Nightly Build: Hierbei handelt es sich um Versionen, die nachts (daher Nightly) automatisch erstellt werden. Ihnen fehlt jede Kontrolle auf Funktionalität. Das Code Review stellt dennoch sicher, das ein Nightly Build verhältnismäßig selten grobe Fehler enthält. Trotzdem sollte ein Nutzer eines Nightlies sich dessen bewusst sein, und immer damit rechnen, dass Teile der ROM nicht funktionieren wie gewünscht. Im schlimmsten Fall funktioniert die Version überhaupt nicht. Nightly Builds sind also nichts für den täglichen Gebrauch.

• M/Monthly Build: Sobald eine neue Android Version laut CM-Entwickler rund genug auf verschiedener Hardware läuft, erstellt das Team davon Monthly Builds. Neue Versionen sind für Anfang jedes Monats geplant, können sich aber auch bis Mitte des Monats verzögern. Die ROMs werden vom jeweiligen Geräte-Betreuer getestet, und auch das UX Team versucht, offensichtliche Probleme in der erweiterten Funktionalität des Systems zu beheben. Ein M-Build ist für all jene gedacht, die neueste Versionen und Funktionen bei minimalem Risiko nutzen möchten. Er ist daher die offizielle Empfehlung unseres Teams.

• Stable Build: Ein Stable Build wird erstellt, wenn der Android-Zyklus sich dem Ende neigt, und die nächste Android Version kurz vor der Veröffentlichung steht bzw. schon veröffentlicht ist. Da sich damit auch der Fokus sämtlicher CM-Entwickler verlagert, bedeutet das quasi den Abschluss der Entwicklung mit einer stabilen Version. Am Ende eines Versionzyklus heißt natürlich auch, dass in einer solchen Version all das Wissen, all die Erfahrung und all die Erweiterungen eines kompletten Zyklus – der meist ein halbes Jahr lang dauert – stecken. Ein Stable Build wird im Gegensatz zu allen anderen Builds auch nachträglich gepflegt, falls zum Beispiel ein Sicherheitsfehler oder gravierender Bug bekannt wird.

• RC Build: Ein RC – Release Candidate – ist eine Spezielle Form von Stable. Sobald in einer Reihe dieser Versionen keinerlei Fehler mehr gemeldet werden, wird dies die Stable Version. Veröffentlicht das CM-Team eine Version RC1, dann werden darin Fehler gefunden. Eine Woche Später erscheint RC2, es werden weitere kleine Fehler gefunden. Werden in einem RC keine weiteren fehler mehr gefunden, dann wir die Version als „Stable“ veröffentlicht. Aktuell steht dieser Status für CyanogenMod 10.1 RC5 kurz bevor (Stand Mitte Juni 2013).
• Experimental Build: Experimental Builds sind vom Geräte Betreuer individuell erstellte Versionen. Meist findet man diese für Geräte, die noch keinen Nightly Status haben. Manchmal werden Experimental Builds auch genutzt, um neue Kernel Funktionen außerhalb der normalen Nightly ROMs zu testen. Man sollte auf jeden Fall die Hinweise des Gerätebetreuers lesen, bevor man so eine ROM nutzt. Leider gibt es keine zentrale Stelle für diese Hinweise – man findet jedoch meist im CyanogenMod-Forum [7] oder bei XDA-Developers [8] einen Beitrag dazu.
• Unofficial Build: Unofficial Builds sind Firmware-Versionen, die sich jeglicher Kontrolle des CyanogenMod-Teams entziehen und meist in einem Forum – wie XDA, rootzwiki oder modaco – ihr Zuhause haben. Die Qualität dieser Builds hängt ausschließlich vom Betreuer ab. Im ersten Beitrag zur Veröffentlichung einer solchen ROM steht aber meist ausführlich, welche Hardware-Komponenten nicht laufen, und welche Probleme es geben kann. Es kommt nicht selten vor, daß diese Builds und ihre Entwickler später dem Weg zum offiziellen CyanogenMod-Team finden.

Allgemein ist anzuraten, die Stable-Version der letzten Android Version – beispielsweise 4.1 – zu nutzen, bis die neue Version 4.2 so weit entwickelt ist, dass ein Monthly Build angeboten wird. Natürlich gibt es immer experimentierfreudige Nutzer, die die neue Version testen, sobald sie irgendwie verfügbar ist. Diese Power User geben dem Projekt wertvolles Feedback.

Ordnung ins Chaos

Auf den kommenden Seiten zeigen wir Ihnen anhand konkreter Beispiele, wie Sie CyanogenMod auf Ihrem Handy installieren. Eine grundlegende Voraussetzung zur Installation besteht darin, dass Sie Ihr Android-Gerät gerootet haben. Details dazu finden Sie auf der Android-User-Webseite in unserer Root-Ausgabe 02/2013 [9] frei online. Ob Ihr Gerät von CyanogenMod unterstützt wird, erfahren Sie auf der Homepage des Projekts unter dem Menüpunkt Devices [10].