CyanogenMod ist tot, es lebe LineageOS.

Vor einigen Tagen noch über CyanogenMod geschrieben und jetzt ist das Projekt tot … das wollte ich nicht!

Aber Spaß beiseite: Dass es im CyanogenMod-Projekt rumort, war leider nichts neues. Und es lag tatsächlich nicht an CyanogenMod selbst, sondern vornehmlich an der Cyanogen Inc., dem kommerziellen Unternehmen, das aus dem Projekt heraus gegründet wurde. Einer der Gründer ist Steve Kondik, der maßgebliche Entwickler hinter CyanogenMod.

Die Cyanogen Inc. wurde gegründet, um CyanogenMod auch für Smartphone-Hersteller interessant zu machen. So weit, so interessant. Das Problem war, dass neben Steve Kondik auch andere Leute an der Führung des Unternehmens beteiligt waren, die, um es mal freundlich auszudrücken, nicht so sonderlich viel Ahnung von der Materie haben. Denn schon recht bald suchten sich diese destruktiven Leute einen Feind aus, der so gar nicht sinnvoll erscheint, wenn es um Android geht: Google selbst. Tatsächlich begaben sich einige Cyanogen-Leute auf den Kurs, dass man Google Android „wegnehmen müsse“, um es weiterzuentwickeln. Was natürlich völliger Käse ist, da Google Android weitgehend als Open Source bereitstellt und Cyanogen ein lauer Furz wäre, wenn es Android und Google als Maintainer nicht gäbe.

Die Cyanogen Inc. eierte aber auch schon kommerziell recht bald nach der Gründung ordentlich herum, weil es offenkundig weder Konzept noch Strategie gab. Zwar gab es das OnePlus als Smartphone, was mit einem Cyanogen-Ableger von CyanogenMod betrieben werden konnte, aber das OnePlus begeisterte vor allem mit einer völlig bescheuerten Verkaufspolitik, die das Telefon weitgehend zu einem Lotteriegewinn verkommen ließ.

Das Ende der Cyanogen Inc. machte sich im Laufe des Jahres 2016 auch schon bemerkbar durch äußerst sinnlose Pressemeldungen. Man wolle mit Microsoft (!) zusammenarbeiten, man wolle Mitarbeiter entlassen, um das Projekt (welches Projekt?) zu retten und so weiter und so fort. Dass nun am Ende des Jahres die Cyanogen Inc. die Segel streicht und auch Steve Kondik endlich das Unternehmen verlässt, ist dringend notwendig. Denn schon längst hatten viele den Überblick darüber verloren, was eigentlich Cyanogen und CyanogenMod eigentlich sind. Und noch viel schlimmer: Auch in der Entwicklergemeinde rund um CyanogenMod regte sich Widerstand.

Daher auch das Ende von CyanogenMod, denn die Namensrechte hat Kondik ärgerlicherweise der Cyanogen Inc. übertragen. Markenrecht unklar, letztlich aber der Markenname auch verbrannt – da macht man am besten das, was jetzt geboten ist: Einen Namenswechsel.

Der Nachfolger wird „LineageOS“ heißen. Daran werden wir uns gewöhnen müssen, aber immerhin steht Steve Kondik wieder dahinter und man hat schon im Vorfeld die gesamten Quellcodes und Entwicklungsumgebungen von CyanogenMod gesichert und möchte hier weitermachen. Ich kann mir auch sehr gut vorstellen, dass hier irgendwo auch Google seine Finger im Spiel hat und Kondik gut zugeredet haben könnte, denn letztlich ist CyanogenMod ein Android-Paradestück. Ein besseres Android und eine bessere After-Sales-Softwarepflege gibt es schlicht nicht.

Zunächst bedeutet das allerdings für alle CyanogenMod-Benutzer, dass es zunächst eine Reihe von Fragezeichen geben wird. Zwar sollen morgen nähere Informationen zum LineageOS-Projekt veröffentlicht werden, aber es ist sehr empfehlenswert, jetzt einmal alle eigenen Smartphones mit installiertem CyanogenMod auf den letzten Stand zu aktualisieren und das jeweilige ZIP-Paket mit dem aktuellsten Stand einmal in Ruhe wegzusichern. Näheres wird es in den nächsten Tagen und Wochen geben.

Deshalb: Der Tod von Cyanogen und CyanogenMod ist auf den ersten Blick bitter, aber unvermeidlich. Es kann jetzt alles nur noch besser werden.

Mit CyanogenMod den Drang auf Neues bekämpfen.

Ein beträchtlicher Teil der Motivation, sich ein neues Smartphone zu kaufen, kommt aus dem weitgehend unterbewussten Drang, etwas neues kaufen zu müssen, weil das Bestehende einen anfängt langzuweilen. Das Ausnutzen dieses Triebes haben nicht zuletzt die eifrigen Menschen aus der Unterhaltungselektronik ausgebaut, zur Perfektion gebracht haben es aber die Smartphone-Hersteller, allen voran Apple.

Um diesen höchst menschlichen Drang zu befriedigen, wird nicht einfach nur jedes Jahr ein neues Gerät entwickelt, sondern auch dafür gesorgt, dass die bestehenden Geräte langsam aber sicher veralten. Sie sind mit den neuen Funktionen des Betriebssystems nicht mehr ganz so flott unterwegs (und seien es nur optische Verbesserungen, die auf alten Geräten etwas mehr ruckeln, als auf der neuesten Generation) und natürlich ist auch das weitgehend schon vordefinierte Ende des Update-Zykluses des Betriebssystems eine Art Damoklesschwert des Mobile Computings. Was nicht mehr aktualisiert wird, ist Alteisen.

Es nervt. Es nervt ganz gewaltig. Nicht nur der Werbezirkus nervt, sondern auch der im Menschen fest verdrahtete Zwang nervt. Beides kann man nicht so einfach ausblenden.

Was mir aber auffällt: Man kann den Zwang wunderbar anderweitig befriedigen, nämlich mit so alternativen Android-Betriebssystemen wie CyanogenMod. Dazu hatte ich schon vor einer ganzen Weile regelmäßig geschrieben und CyanogenMod macht etwas, vor was es allen Herstellern von Smartphones graut – sie pflegen ein eigenes Android, das selbst auf sehr alten Smartphones noch läuft. Und zwar mit aktuellen Android-Versionen, sofern die Hardware das verträgt:

Mein LG G3 (von LG noch mit Android 6.0.1 gepflegt), läuft aktuell mit Android 7.1.1 und mein wirklich uraltes Samsung Galaxy S2 aus dem Jahre 2011 läuft mit Android 6.0.1 (einst mit Android 2.3.3 eingeführt und bis Android 4.1.2 offiziell gepflegt). Nicht besonders schnell, aber dafür mit gepflegter Software und damit deutlich größeren Einsatzmöglichkeiten. Und der Drang, ein neues Smartphone kaufen zu wollen, ist weg. So weg, dass man eigentlich eher zuschaut, dass man sein Smartphone noch möglichst lange nutzen kann.

Alle maulen über das Google Nexus 6. Ich nicht.

Mein Google Nexus 6 war letztes Jahr eine Art Verlegensheitskauf. Ich hatte als Nachfolger des Samsung Galaxy S4, mit dem ich nicht wirklich warm wurde, das LG G3 gekauft, was im Frühjahr 2015 als Auslaufmodell schön günstig wurde. Da ich sehr auf die Android-Alternative CyanogenMod stehe, war deren Lauffähigkeit Grundbedingung. Leider zeigte sich jedoch im Sommer, dass CyanogenMod auf dem G3 einige ärgerliche Fehler hatte, darunter merkwürdige und unmotivierte Reboots. So geht das natürlich nicht auf Dauer. Es gab dann im Sommer letzten Jahres kurzfristig ein Angebot zum Google Nexus 6 und ich griff zu. Nun ist das LG G3, auf dem CyanogenMod inzwischen zuverlässig läuft, sozusagen mein Ersatz-Smartphone, während das Nexus 6 mein täglicher Begleiter ist.

Das Nexus 6 ist mit seinem sechs Zoll großen Bildschirm eine echte Wuchtbrumme und damit ein Phablet, also eine Mischung aus Smartphone und Tablet. Damit hatte ich anfangs so meine Probleme, auch wenn ich jetzt zugeben muss, dass mir die Bildschirmdiagonale sehr gefällt. Man kann einfach richtig viel auf diesem Bildschirm sehen und selbst als Autonavi-Verlegenheitslösung macht es eine gute Figur. Das geht so weit, dass mein eigentliches Tablet, ein 10,1-Zoll Xperia-Tablet, immer häufiger im Regal bleibt, weil ich die meisten Aufgaben schon auf dem Nexus 6 erledigen kann. Und dank seiner Größe passt mit einem 3.220-mAh-Akku auch ein richtiger Klotz an Stromspeicher hinein, der das Teil sehr locker den ganzen Tag über ohne Zwischenladen betreibt.

Google mault, Motorola mault.

Bei der Auswahl der Nexus-Hersteller lässt Google die Zügel nicht (mehr) schlaff herunterhängen. Wer als Hersteller ein Nexus bauen darf, muss sich an die Wünsche von Google halten. Die sind teilweise löblich (zum Beispiel das reine Android ohne zusätzliche Hersteller-Apps), zum Teil aber auch ärgerlich (beispielsweise der konsequent fehlende MicroSD-Kartenslot). Dass Google auf den Nexus-Geräten eine Reihe von Spielereien nicht sehen will, mag ja noch durchgehen, aber teilweise ist Google schlicht ignorant.

So kann die Hardware des Nexus 6 einige Dinge, die das Nexus-Android nicht unterstützen mag. So hat das Nexus 6 eine LED zur Signalisierung, die aber vom Betriebssystem nicht angesprochen wird. Auch kann der Bildschirm hardware-seitig mit einem doppelten Tippser aufgeweckt werden, auch das unterstützt Google nicht. Und schließlich werden ähnliche Schwestermodelle des Nexus 6, die von Motorola direkt angeboten werden, auch mit MicroSD-Kartenslot angeboten, so dass man davon ausgehen kann, dass Google im Nexus 6 explizit darauf verzichten wollte.

Auch Motorola mault: Das Handy sei schlicht zu groß (naja, eben Geschmackssache), es sei zu billig verarbeitet, hat einen runden Rücken, mit dem es nicht plan auf dem Tisch liegen kann.

Stimmt ja alles. Aber: warum fällt Google und Motorola all das erst über einem Jahr nach Markteinführung ein? Und warum gefällt mir das Google Nexus 6 dennoch?

Quo vadis, Android?

Android ist ein schönes und übersichtliches Betriebssystem, nicht mehr nur für Smartphones, sondern auch für Tablets und viele andere Geräte. Wer aber die Nachrichten über Android in den letzten Wochen gelesen hat, kann sich durchaus die Frage stellen, ob es Google mit Android überhaupt ernst meint. Sicherheitsprobleme, die gleich Millionen von Geräten betreffen prallen auf die Versäumnisse, dass es immer noch kein einheitliches Konzept darüber gibt, wie man eigentlich bei bereits verkauften Geräten die Softwarepflege bewerkstelligen will. Während das bei eher kosmetischen Problemchen maximal ärgerlich ist, könnten echte Sicherheitsprobleme unter Umständen zukünftig vielleicht auch dazu führen, dass komplette Mobilfunknetze dann in Mitleidenschaft gezogen werden könnten, wenn beispielsweise Android-Probleme zu fehlerhaft arbeitenden Smartphones führen.

Alles so Fragen, zu denen es fatalerweise immer noch keine Antworten gibt.

Smartphone-Hersteller sehen Smartphones zu singulär.

Wenn mir eines immer wieder auffällt, ist es die erschreckende Beobachtung, wie wenig Sorgfalt viele Smartphone-Hersteller auf die Software legen. Üblicherweise nehmen Hersteller die Android-Basis und setzen da dann ihren eigenen Aufsatz an Launcher und zusätzlichen Apps drauf. So weit, so schlecht. Denn hier prallen gleich mal westliche und fernöstliche Welt zusammen, denn während in Fernost ein Smartphone erst mit möglichst viel Klimbim (vulgo: Apps) begehrenswert erscheint, ist es in der westlichen Welt eher umgekehrt. Keep it simple.

Das haben viele Hersteller erkannt und liefern ihre Smartphones mit deutlich weniger vorinstallierten Apps aus, dafür jedoch mit einem eigenen App-Store. Google wiederum hat mit der Einführung von Android 4.0 Hersteller dazu verpflichtet, eigene Launcher nicht so zu implementieren, dass der Nutzer keine Auswahl mehr hat.

Die echten Ärgernisse kommen aber im Unterbau daher und hier wird von Seiten der Hersteller mitunter mächtig geschludert, in dem eigentlich vorhandene Android-Funktionen einfach deaktiviert werden. Beispiel: Das LG G3 meldet sich, so wie leider viele Android-Smartphones, akustisch, wenn der Akku voll ist. Das ist vielleicht ganz toll, wenn das Smartphone auf dem Tisch steht, aber störend, wenn das nachts passiert. Android bringt nun von Hause aus die Funktion mit, dass sich Benachrichtigungen nachts abschalten lassen, aber daran hält sich die Software des G3 nicht. Mit dem Ergebnis, dass es auch nachts piept, wenn der Akku voll geladen wurde.

Noch viel drastischer ist das, was zur Zeit zu einem ernsthaften Vertrauensverlust gegenüber Android führt, nämlich die mitunter erbärmliche Pflege der Software. Auch relativ neue Android-Smartphones erleben die meisten Updates im ersten Jahr, danach wird es dramatisch schlecht. Das LG G3 hat sein letztes Update beispielsweise Anfang des Jahres 2015 erhalten und dabei ist es nun gerade einmal ein Jahr auf dem Markt. Und: Wir reden auch noch gar nicht von Android 5.1, sondern immer noch von Android 5.0, während Google im Herbst die Nachfolger-Version von 5.1 präsentieren wird.

Bei anderen Herstellern sieht es teilweise nur wenig besser aus. Immer hat man den Eindruck, dass Software-Updates quälend lange dauern und dann auch noch immer wieder die Veröffentlichung von Updates herumgeschoben wird. Es gibt in Sachen Android auch nicht im entferntesten das Gefühl, dass hier Google und Smartphone-Hersteller an einem wie auch immer gearteten Strang ziehen. Das schafft kein Vertrauen.

Google ist übrigens mit seinen Nexus-Geräten, die ja eine Art Referenzdesign darstellen sollen, keinen Deut besser. Auch das Nexus 6, das ich selbst einsetze, erfährt kaum Updates, obwohl Google nachweislich an der Android-Software ständig Änderungen und Verbesserungen durchführt. Dass das Nexus 6 darüber hinaus die Merkwürdigkeit mitbringt, dass es sehr gute Hardware an Bord hat, die Google aber nicht ansatzweise nutzt (z.B. eine LED-Signalisierung und ein per Fingertip einschaltbarer Bildschirm, beides nicht nutzbar), ist auch so eine Geschichte, die man wohl nur bei Google verstehen mag.

Lifecycles mit festen Ansagen.

Wenn etwas teures dauerhaft funktionieren soll, kommt man um die Ansage eines Lifecycles nicht herum, also die Festlegung, wie lange man ein Gerät mit Updates versorgen wird. Das ist bei Desktop-Betriebssystemen Normalität und ein Grundpfeiler, dass sich Betriebssysteme in kommerziellen Umfeldern überhaupt einsetzen lassen. Und genau das fehlt der Android-Welt komplett.

Wir brauchen also tatsächlich eine Regelung, dass Smartphone-Hersteller für ihre Geräte feste Angaben darüber machen müssen, wie lange sie die Gerätschaften zu pflegen gedenken. Das tun sie zwar auch heute schon, nur werden diese Informationen nur selten auch nach außen hin kommuniziert, was ein echtes Problem darstellt und im Prinzip auch verbraucherfeindlich ist.

Während jetzt ein nicht gebundener Hersteller kaum gezwungen werden kann, regelmäßig seine Gerätschaften zu pflegen (außer mit gesetzlichen Regularien in einzelnen Ländern), könnte Google mit Android da sehr eindrücklich Zügel anlegen und Ansagen machen – wenn man denn wollte. Und es vielleicht gleich so machen, wie auch bei den Android-Smartwatches, wo sich Google von Anfang an die komplette Hoheit über die Software zusichern hat lassen. Mit dem Ergebnis, dass Android-Smartphones herstellerübergreifend alle zum gleichen Zeitpunkt Updates bekommen.

Keep it open (oder macht es zumindest irgendwann).

Auf meinen Android-Smartphones nutze ich schon seit Jahren die herstellereigene Android-Version nur kurz, um möglichst bald das Smartphone mit einer After-Sales-Androidversion zu installieren, in meinem Fall mit CyanogenMod. Das ist eine Truppe, die auf Basis der originalen Android-Quellen eine eigene Implementierung pflegt. Zu der Installation muss man zwar die meisten Smartphones „rooten“, also den Bootloader mehr oder weniger aufwendig knacken, aber mit Unsicherheit hat CyanogenMod nicht viel zu tun. Ganz im Gegenteil:

CyanogenMod bezieht die offiziellen Android-Updates in der Regel sofort, nachdem sie in den offiziellen Android-Quellen veröffentlicht werden. Und in vielen Fällen stellt die Programmiertruppe um CyanogenMod auch eigene Fixes bereit, um erkannte Sicherheitslöcher zu beheben. Das führt dazu, dass mit CyanogenMod bespielte Geräte oftmals erheblich aktueller sind, als alle anderen Smartphones mit Hersteller-Android – selbst bei den Nexus-Geräten. Ich bin so frei und behaupte, dass CyanogenMod das aktuellste Android ist, was man bekommen kann.

Bei einem PC würde es kaum jemand akzeptieren, wenn der Hersteller alles dafür tut, dass das Betriebssystem nicht gewechselt und auch nicht aktualisiert werden kann, wenn der Hersteller zu beidem keine Lust mehr hat. Bei einem Smartphone ist das leider überall immer noch gang und gäbe. Und genau hier wird sich auch für Hersteller irgendwann mal die Frage stellen, ob es nicht einfacher wäre, Geräte so einzurichten, dass ein interessierter Nutzer auch ohne große Biegungen eine andere, offene Android-Version einzuspielen. Das werden auch dann sicherlich nur ein Bruchteil der Besitzer tun, aber zumindest hätte man nach Ablauf der Gewährleistung und Garantie das Thema los, die Software der Gerätschaften selbst noch pflegen zu müssen, wenn man freundlich darauf verweisen kann, dass es After-Sales-Androidversionen wie CyanogenMod gibt.

Quo vadis, Android?

Android kann man sicher machen, zweifellos. Früher oder später wird es dann auch immer mehr Smartphones geben, die dann auch sicher sind. Was aber mit einer fehlenden Versionsstrategie niemals funktionieren wird: Breitflächige Innovationen. Mit einer zu fragmentierten Basis an Android-Versionen ist der Umstand, dass es schon jetzt gewaltig viele Hardware-Konstellationen gibt, nicht mehr zu bändigen. Google versucht zwar immer noch aufopfernd mit einem Verschieben von Programmier-APIs in austauschbare Apps eine zumindest grob einsetzbare Gerätewelt herzustellen, aber zukünftige Innovationen werden sich mit immer komplexen Details beschäftigen.

Beispiel: NFC ist nicht einfach NFC. NFC gibt es am Smartphone, an der Smartwatch und dann gibt es eine Reihe von Anwendungen, die spezialisierte NFC-Protokolle nutzen. Wie will man das einheitlich von Android 4.1 bis 5.1 durchziehen? Gibt es aber kein einheitliches NFC, gibt es auch kein mobiles Payment, das auf NFC aufsetzt.

Es wird der Zeitpunkt kommen, wo Google einen Teil von Android nicht mehr den Herstellern überlassen darf, weil sie nicht nur technisch nicht in der Lage sind, damit umzugehen, sondern weil sie offenkundig auch keine Lust haben, Produktversprechen abzugeben und/oder einzuhalten. Dieser Zeitpunkt ist gekommen.

In Android Benachrichtigungen einzelner Apps deaktivieren.

Die Benachrichtigungsfunktion in Android ist eigentlich etwas sehr nützliches. Sich Neuigkeiten und Mitteilungen mit Signalisierung zukommen zu lassen, damit kommt kein Smartphone mehr wirklich aus. Eine Unart dabei ist es, dass Benachrichtigungen von vielen Apps immer häufiger nicht für wichtige Mitteilungen eingesetzt wird, sondern für schnöde Werbung. Die Amazon-Apps gehören dazu, aber auch viele andere Apps. Okay, bei den meisten dieser Apps kann man deren Benachrichtigungen dort auch gleich wieder abschalten.

Besonders nervig sind jedoch Apps, bei denen die Benachrichtigungsfunktion nicht abschaltbar ist. Das sind meist System-Apps der Smartphone-Hersteller. Eine solche Benachrichtigung schickt das LG G3 beispielsweise immer dann ab, wenn der Akku voll geladen ist. Zum Beispiel auch nachts. Und das, obwohl ich in den Töne-Einstellungen explizit eingestellt habe, dass zwischen 0 und 8 Uhr mein Smartphone nur Telefongespräche akustisch signalisieren soll.

Nun ist es leider so, dass LG in seiner Android-Installation die Konfiguration der Android-Benachrichtigungsfunktion leider ziemlich beschneidet. Mit dem Ergebnis, dass Benachrichtigungen von System-Apps (die Akku-Benachrichtigung kommt von der System-App „System-UI“) nicht abgeschaltet werden können. Eigentlich alles schon ein Argument, um mit diesem Smartphone die LG-Entwickler tagelang zu ohrfeigen.

Eine Lösung wartet aber in Form einer kleinen, unscheinbaren App namens Notifications filter in Google Play. Die macht nämlich genau das: Benachrichtigungen von Apps filtern. Da die App dabei nicht in das Benachrichtigungssystem eingreift (was sie ohne Root auch gar nicht könnte), sondern sich praktisch zwischen Benachrichtigungsgenerierung und endgültiger Anzeige dazwischenschaltet, filtert sie auch die Benachrichtigungen, die sich eigentlich nicht abschalten lassen.

Die Benutzung der werbefinanzierten App ist dabei sehr simpel. Die Anzeige von Benachrichtigungen kann für jede App eingestellt werden, auch für System-Apps. Zusätzlich lässt sich dabei auch noch ein Inhaltsfilter konfigurieren, der nach bestimmten Wörtern in Benachrichtigungen sucht und entsprechend filtert.

In meinem Fall reicht es, einfach alle Benachrichtigungen der App „System-UI“ zu filtern, damit ist jetzt Ruhe – auch dann, wenn der Akku voll ist.

Smartphone-Apps als Schriftenlieferanten.

Disclaimer: Mein Anwalt hat geprüft und in folgendem Text keine potentiellen Rechtsverstöße festgestellt. Die folgenden Schritte zeigen keine Vorgänge, die durch Deassemblieren von kompilierten Dateien entstehen, ebenso wird kein Kopierschutz geknackt, sondern lediglich eine Datei in einem De-Zip-Programm geöffnet.

Der meines Erachtens nach notwendige, auch wenn völlig bescheuerte Disclaimer erklärt eigentlich schon alles – Gängige Smartphone-Apps (egal ob Android oder iOS) enthalten neben Programminhalten, Grafiken und multimedialen Inhalten meist auch Schriftdateien, in der Regel im TTF- oder OTF-Format. Zwar haben App-Dateien eine eigene Dateiendung (unter Android „.apk“ und unter iOS „.ipa“), allerdings sind diese Dateien nichts anderes als handelsübliche Zip-Dateien, also im Zip-Format komprimiert. Benennt man App-Dateien in ihrer Dateiendung auf „.zip“ um oder öffnet sie in einem besseren Komprimierungsprogramm wie 7-Zip, dann zeigt sich auf einen Schlag das gesamte Gut. Im Falle der SPIEGEL-Reader-App für iOS zum Beispiel mit folgendem Inhalt:

Font-Dateien in Apps

Das ist nicht weniger als die gesamten SPIEGEL-Schriftfamilien, die zum Beispiel bei MyFonts.com mehr als 220 Euro kosten. Schiebt man diese Dateien aus der gezippten App-Datei direkt in den eigenen Schriftenordner … aber das darf ich nicht weiter beschreiben, denn natürlich ist so eine Nutzung der in der App gelieferten Schriften nicht gestattet (andererseits müsste das ein Lizenzvertrag auch explizit untersagen). Das Spiel kann man so weiterführen, denn viele Apps nutzen nicht die an sich reichhaltige Auswahl an im Mobilbetriebssystem integrierten Schriften, sondern bringen ihre eigene Hausschrift in voller Pracht mit.

iOS macht es da sogar deutlich leichter als Android, denn wer sein iPhone/iPad mit iTunes sichert, hat ein komplettes Backup aller installierten Apps auf der Festplatte. Man schaue (unter Windows) in den Benutzerordner, dort unter

"Eigene Musik\iTunes\iTunes Media\Mobile Applications"

Unter Android ist es nicht ganz so einfach, denn dort lassen sich installierte Apps nur auf dem Smartphone/Tablet selbst heraussuchen und das auch nur bei einem gerooteten Gerät. Dort befinden sich die Apps in

"/data/app"

Da Android Apps auch direkt von hier aus startet, sollten Apps hier nicht direkt geöffnet werden, sondern an eine Stelle im Smartphone kopiert, wo man dann mit einem Dekomprimierprogramm gefahrlos hineinschauen kann. Meist befinden sich innerhalb der App-Datei die Schriftarten im „assets“-Ordner.

Sicherheitshalber nochmal der Hinweis: So dahergeholte Schriftdateien sind in der Regel nicht zur Nutzung außerhalb der jeweiligen App lizenziert. Ich habe das jetzt hier laut und deutlich gesagt. Ich liebe Schriftarten und kaufe offiziell die Schriften, die mir gefallen, um damit auch die Leute zu unterstützen, die sie erstellen. Allerdings könnten genau diese Leute auch mal die Verkäufer ihrer Schriften bitten, wenigstens doch bitte mal ihre Schriften mit entsprechenden Flags auszustatten, die eine Installation als normale Schriftdatei in Betriebssystemen untersagen. Das ist für gewiefte Leute zwar auch keine echte Hürde, ist aber wenigstens nicht ganz so einfältig. Am sinnvollsten wäre es, wenn ein App-Programmierer mit etwas Phantasie solche wertvollen Assets halbwegs gut codiert und vor einfacher Entnahme schützt.

App-Übersicht in Android hochdosiert.

Wenn ich mich entscheiden müsste, welches Feature unter Android das beste ist, wäre es ziemlich sicher das Konzept der Widgets. Smartphone einschalten und unmittelbar nach dem Entsperren die Ansicht bekommen, die man möchte. Bei mir sieht diese „Seite 1“ auf meinem Samsung Galaxy S4 mit CyanogenMod 11 (Android 4.4.2) derzeit folgendermaßen aus (ruhig mal auf die Screens hier klicken, die sind im Original alle 1920 mal 1080 Pixel groß):

Besims Android-Ansicht Widgets Seite 1Das spannende an Android ist, dass die Android-Benutzeroberfläche zwar von Android mitgeliefert ist (der so genannte „Launcher“), aber nicht zwingend genutzt werden muss. Das merkt man am ehesten an den Android-Versionen vieler Gerätehersteller, die einen eigenen Launcher mitliefern. Bei Samsung heißt der z.B. „TouchWiz“, bei HTC „HTC Sense“ und so weiter.

Zudem gibt es im Play Store eine Reihe von weiteren Launchern, die viele weitere Funktionen mitbringen, als der Android-Launcher. Einige Launcher glänzen dabei mit teilweise bizarrer Verspieltheit (und Akkuverbrauch), andere sind relativ „konservativ“. Ich verwende hier den Nova-Launcher, der meiner Meinung nach sehr am Android-Look-and-Feel bleibt und doch einige interessante Funktionen mitbringt. Darunter beispielsweise die Möglichkeit, den Raster für Widget- und App-Ansicht deutlich engmaschiger zu stricken.

Normalerweise ist der Raster bei den meisten Telefonen so um die 5 mal 5 Flächen. Also 5 Zeilen und 5 Spalten. In meiner Widget-Ansicht habe ich aktuell 9 x 6 und kann so deutlich mehr Inhalt auf die Seite packen, ohne dass es auf dem riesigen 5-Zoll-Bildschirm zu eng daherkommt. Experimentieren tue ich hier seit einigen Wochen vor allem mit dem Umstand, dass ich schlicht die Namen der Apps nicht mehr einblende, sondern nur noch die Piktogramme selbst. Das funktioniert übrigens ziemlich problemlos nach einer kurzen Eingewöhnungszeit, zumindest auf der Widget-Ansicht. Denn die Icons, die ich hier einblenden lasse, das ist der „harte Kern“. Übrigens habe ich witzigerweise einen Artikel hier im Blog, der meine Android-Seite-1 vom August 2011 beinhaltet.

Seit einigen Tagen experimentiere ich noch ein Stück weiter, nämlich auch mit einem engeren Raster in der App-Ansicht. Hier habe ich aktuell einen Raster von 10 mal 6 Flächen, kann also schlappe 60 Apps auf eine Seite unterbringen, anstatt vorher nur 30. Und weil es jetzt superkompakt dahergeht, habe ich derzeit auch nur zwei App-Seiten, obwohl ich zur Zeit 114 Icons unterzubringen habe:

Das ist jetzt schon ziemlich heftig. Das Problem hierbei sind wiederum nicht die fehlenden Namen der Apps, sondern die schiere Fülle. Alles zwar noch bequem mit dem Finger antippbar, aber man braucht anfangs einen Moment. Andererseits spart man sich in vielen Fällen das Blättern und nach einigen Tagen geht es dann doch erstaunlich gut. Was allerdings in so einer Übersicht unabdingbar ist, ist die alphabetische Sortierung bzw. überhaupt eine Richtlinie, nachdem Apps streng sortiert werden. Sonst geht das hier so gar nicht.

Ich habe spaßeshalber mit einem anderen Launcher auch mal mit kleineren Icons experimentiert, um noch mehr Apps auf eine Seite unterzubringen. Spätestens dann wird es aber blöd. Ich habe zwar keine Wurstfinger, aber dann macht es echt keinen Spaß mehr.

Apple und der kommende Untergang auf dem Smartphone-Markt.

Die heutige Apple-Keynote habe ich nicht live verfolgt, sondern auf die Ergebnisse gewartet. Keynotes sind Geschmackssache, Apple-Keynotes habe ich zumindest mal so lange verfolgt, wie ich Apple-Aktien hatte. Die habe ich seit einer Weile nicht mehr und okay, ich will nicht schimpfen, der Gewinn beim Verkauf war beträchtlich.

Nach den ständigen Gerüchten der letzten Monate, dass Apple angeblich ein Billig-iPhone plane, um damit der Billigkonkurrenz mit Android-Betriebssystem Paroli zu bieten, horchte ich dann heute trotzdem genauer hin. Das iPhone 5C hätte das Potential, tatsächlich mit iOS und als billiges Gerät den Markt untenherum aufzurollen, in dem viele Hersteller mit Android tollen, teilweise auch mit recht emotionsarmen Geräten. Und vor allem hätte Apple die Chance, in Märkte hineinzukommen, die sich das metallene Original schlicht nicht leisten können.

Und was macht Apple? Sie verkacken es so, wie man es nur verkacken kann.

Denn: Der Plastikbomber in Form des iPhone 5C wird, so wie es derzeit aussieht, in allen Ausbaustufen (16 und 32 GB) gerade einmal 100 Euro billiger sein, als die des iPhone 5S, also dem iPhone-Flaggschiff. Und damit kostet das billigste iPhone 5C mit 16 GB Speicherausstattung immer noch knackige 599 Euro. Bei Google gibt es für 599 Euro das Google Nexus 4 (199 Euro) und das Google Nexus 7-Tablet (229 Euro) und man hat am Ende noch 171 Euro übrig.

Und selbst so Oberklasse-Gerätschaften wie das Samsung Galaxy S4 kosten derzeit etwas über 300 Euro. Will man es luxuriös, konkurriert der iPhone-Plastikbomber preislich zum Beispiel mit dem kommenden Android-Flagschiff Sony Xperia Z1, das ebenfalls in der 600-Euro-Klasse einsteigen wird, aber bei weitem besser ausgestattet ist.

Mit 599 Euro Einstiegspreis für das billigste iPhone hat Apple ein klares Statement gestellt. Das Segment der günstigen und mittelpreisigen Smartphones will man nicht betreten und diese Segmente weiterhin Android überlassen. Das schon jetzt über eine Milliarde aktivierte Geräte zählt und jeden Tag eine Million mehr. Dass iOS daran arbeitet, nächsten Monat die Hürde der 700 Millionen Aktivierungen zu reißen, ist da kein hoffnungsvolles Signal, sondern eine Kapitulation.

Stand von CyanogenMod auf dem Samsung Galaxy S2.

Seit nun fast einem Jahr benutze ich auf meinem geliebten Samsung Galaxy S2 nicht mehr die originale samsungsche Android-Version, sondern die der Aftermarket-Firmware-Truppe CyanogenMod. Deren Android-Paket ist schlank und hält sich weitgehend an die originalen Android-Vorgaben und ist vor allem aktuell. Während CyanogenMod derzeit Pakete mit Android 4.2.2 und 4.3 anbietet, ist bei Samsung für das Galaxy S2 immer noch Android 4.1.2 das Maß der Dinge. Zwar baut Samsung inzwischen weitgehend stabile Firmware zusammen – aktuelles Android gibt es aber nur für aktuelle Modelle.

Das Samsung Galaxy S2 und der aktuelle Status bei CyanogenMod.

Auch wenn das Galaxy S2 zu den im CyanogenMod-Projekt unterstützten Geräten gehört, gibt es ein zentrales Manko: Die Entwicklung ist unter anderem für dieses Smartphone beta. Das liegt daran, dass der unter anderem im Galaxy S2 verbaute Prozessor aus der Samsung-Prozessorserie Exynos 4 nicht vollständig unterstützt werden kann. Das liegt offenkundig daran, dass nicht jeder Programmcode, der zur Anpassung von Treibern mit diesem Prozessor notwendig ist, als Open Source zur Verfügung steht.

Dazu vielleicht ein kleiner Exkurs: Moderne Smartphone besitzen Prozessoren, die viele Funktionen in einem Chip integrieren. Das geschieht aus Platz- und Energiespargründen. Samsung baut unter anderem eine eigene Prozessorserie, eben die Exynos-Serie. Um nun alle Funktionen dieses Chips nutzen zu können, braucht man einen Satz an Treibern, die zwischen Android und dem Prozessor vermitteln können. Dazu braucht es eine gewisse Unterstützung des Prozessorherstellers und leider ist da Samsung offenbar etwas schwerhörig.

Das führte dann zu ein paar „Effekten“: Während nämlich für andere Geräte die Entwicklung voranschritt und nach und nach zu einem richtigen Release führte, war das Galaxy S2 einer der wenigen Geräte, die immer nur Software im Alpha-Stadium bekamen. Aber auch hier noch ein kleiner Exkurs:

Die Entwicklungsschritte bei CyanogenMod.

CyanogenMod-Versionen haben mehrere Entwicklungsschritte:

  • Die so genannten Nightlies sind das Ergebnis der täglichen Entwicklungsarbeit im Projekt und quasi Alpha-Software. Diese werden zu nächtlicher pazifischer Zeit (bei uns am Vormittag) automatisch (!) aus der vorhandenen Code-Basis für die offiziell unterstützten Geräte erstellt. „Automatisch“ ist vor allem deshalb mit einem Ausrufezeichen versehen, weil hier tatsächlich relativ wenig Qualitätssicherung vorgenommen wird. Bastelt ein Entwickler an einem Fragment des Codes, spielt den zurück auf den Server und wird dann dieses Fragment einige Stunden später zu einem Nightly verarbeitet – ob das Fragment nun funktioniert oder nicht. Weil also Nightlies mitunter „roughen“ Code enthalten können, kann es durchaus passieren, dass ein Nightly auch mal defekt ist und ein Smartphone reif für eine Neuinstallation macht. Nightlies sind also eigentlich nur etwas für Entwickler und für Leute, die regelmäßig Backups machen.
  • Sehr spezielle Versionen sind die so genannten Experimentals. Vor diesen Builds sei ausdrücklich gewarnt, denn diese sind speziell zum Experimentieren von einzelnen Features gedacht und können sehr „rough“ sein. Meist werden hier Kernel-Geschichten ausprobiert oder neue Treiber und deshalb haben Experimentals eigentlich wirklich nur auf reinen Testgeräten etwas zu suchen. Dummerweise bleiben auf den Download-Seiten die Experimental-Builds sehr lange zum Download, was den ein oder anderen dazu verleitet, sich diese mal zu installieren. Wie gesagt: Nicht tun, wenn man nicht den blassesten Schimmer hat, was der Zweck des Experimentals ist.
  • Der erste Schritt zu einer stabilen Version sind die Milestones oder auch einfach nur „M“ genannt. Für Milestones werden schon die ersten Bugreports akzeptiert und was hier im Featureumfang dabei ist, wird später höchstwahrscheinlich auch in der fertigen Firmware drin sein. Milestones können ebenfalls fehlerbehaftet sein und haben oft Software an Bord, die noch im Rohbau ist, aber immerhin sieht man hier schon mal, wo es lang gehen wird.
  • Wird lange genug entwickelt und der Programmcode für ein Gerät verbessert, kommt das Stadium der Release Candidats. Ein RC ist im Prinzip eine Vorstufe für einen echten Release und an einem RC wird auf jeden Fall von Hand nachgearbeitet. Sprich: Für ein RC können und werden Bugreports angenommen mit dem Ziel, den RC zu verbessern und zu stabilisieren, aber (weitgehend) nicht mehr mit neuen Features auszustatten). RC sind also quasi Beta-Software. Auch sie können noch Fehler enthalten, sind aber für gewöhnlich schon sehr gut (und werden, wenn es mehrere RC gibt, immer besser).
  • Ist auch der RC-Prozess erfolgreich durchlaufen und alles an Fehlern abgearbeitet, kommt das Stable, das ist dann die offizielle Software. Die ist dann „ausgehfertig“ und wird dann auch unterstützt, beispielsweise mit Support oder mit späteren Wartungs-Updates.

Weil es nun bei allen Geräten, die die Exynos-4-Prozessorreihe einsetzen, noch diverse Punkte gibt, die noch nicht abgearbeitet sind, hängen diese Geräte in der Entwicklung hinterher. Um die Versionsnummern zu verstehen, braucht es noch einen kleinen Exkurs:

CyanogenMod-Versionen.

Die Versionsnummern bei CyanogenMod unterscheidet sich von der Android-Versionierung und sieht folgendermaßen aus:

  • CyanogenMod 7: Android 2.3.x
  • CyanogenMod 9: Android 4.0.x
  • CyanogenMod 10: Android 4.1x
  • CyanogenMod 10.1: Android 4.2.x
  • CyanogenMod 10.2: Android 4.3.x

Derzeit (Stand Ende August) gibt es offiziell für die meisten Geräte CyanogenMod 7, 9, 10 und 10.1 als offizielle Stables. Sprich: Da CyanogenMod 10.1 derzeit auf Android 4.2.2 basiert, gibt es für die meisten Geräte, die mit CyanogenMod 10.1 Stable laufen, Android 4.2.2. Das relativ neue Android 4.3.0 ist derzeit für die unterstützten Geräte in der Nightly-Phase und durchläuft damit die obigen Prozesse.

Das Dilemma mit Exynos-4-Geräten im CyanogenMod-Projekt.

Weil nun die Entwicklung bei Exynos-4-gepowerten Geräten hinterherhinkt, gibt es für diese Geräte bisher noch gar keine Stables. Die Entwicklungsarbeit beim Galaxy S2 begann mit CyanogenMod 7, ging über Version 9, 10, 10.1 und 10.2, aber immer nur gab es Nightlies und bisher noch nie ein Release Candidate oder gar ein Stable.

Das mag jetzt auf den ersten Blick kein größeres Problem sein, ist aber eines: Denn während man mit einem Release Candidate oder mit einem Stable irgendwann eine stabile Firmware hat, die dann auch einige Monate lang unverändert bleibt, ist der Nightly-Prozess gewissermaßen eine kleine Lotterie. Die meisten Nightlies laufen zuverlässig, aber manchmal gibt es eben Blindgänger und defekte Nightly-Versionen. Und wenn dann jemand so eine Version installiert, darf er mitunter länger daran arbeiten, sein Handy wieder aufwendig wiederherzustellen und/oder zu rooten. Sprich: Nightlies gibt es jeden Tag und die installiert man sich auch gern mal, aber letztendlich muss man immer auf der Hut sein, regelmäßig das CyanogenMod-Forum mitlesen und immer ein Backup für den Ernstfall in der Hinterhand haben.

Dazu kommt, dass die Entwicklungsarbeit im Nightly-Stadium irgendwann abrupt endet. Das ist kein Problem, wenn aus Nightlies irgendwann ein Release Candidate und daraus dann ein Stable entstanden ist, denn das bleibt ja. Wenn es aber kein RC und kein Stable gibt, sondern nur Nightlies und irgendwann die Entwicklungsarbeit dann auf eine neuere Android-Version geht, bleibt man mitunter als Nutzer mit einer letzten Nightly-Version auf breiter Flur.

Das Samsung Galaxy S2 und CyanogenMod 10.1 und 10.2.

So geschehen jetzt aktuell mit CyanogenMod 10.1 und 10.2. Von der Version 10.1 gab es das letzte Nightly am 13. August. Dieses Nightly läuft stabil und gut, wäre eigentlich auch RC- und Stable-fähig, ist es aber aus oben genannten Gründen mit den Problemen mit Exynos 4 eben nicht. Dennoch: Dieses Nightly läuft mit Android 4.2.2 und ist ein guter Kompromiss.

Am 14. August begann für viele Geräte, die offiziell für die Unterstützung von CyanogenMod 10.2. So gab es auch für das Galaxy S2 mit dem Nightly vom 14. August automatisch CyanogenMod 10.2 und damit Android 4.3. Und damit begann das Dilemma. Denn tatsächlich hat das Galaxy S2 mit den ersten Nightlies von CyanogenMod 10.2 noch eine ganze Reihe von Problemen: Der Bildschirm flackert, die Systemeinstellungen sind teilweise sehr deutlich umorganisiert worden und generell hat das Galaxy S2 das Designproblem, dass es noch einen Hardware-Home-Button hat und mit CyanogenMod 10.2 die Unterstützung noch nicht wirklich rund ist.

Nun wäre das ja kein Problem, wenn man sagen könnte: „Okay, CyanogenMod 10.2 ist Nightly, mach‘ das nicht drauf, wenn du nicht mutig bist, sondern installiere das letzte Stable!“ Das geht aber beim Galaxy S2 leider nicht, weil es bisher gar kein Stable gab. Man kann derzeit also nur auf das letzte Nightly von CyanogenMod 10.1 zurückgreifen, das funktioniert und aber selbst von Hause aus, da Nightly, nicht gepflegt wird. Zu allem Unglück kam dann auch noch, dass vor einigen Tagen im einem CyanogenMod-10.2-Nightly für das Galaxy S2 ein mittelschweres Unglück im Boot-Modul existierte, der dazu führte, dass eine Reihe von Galaxy S2 mit dem jeweiligen Nightly gar nicht mehr starteten konnten und aufwendig wieder zurückgesetzt werden mussten.

Das alles schafft eine Menge Unfrieden, das man im CyanogenMod-Forum auch so lesen kann. Und eigentlich haben die CyanogenMod-Entwickler – zu einem Großteil freiwillige Programmierer und Entwickler rund um den Globus – daran gar keine Schuld.

Ein RC! Ein RC!

Heute Vormittag dann gab es eine Überraschung auf dem Downloadserver von CyanogenMod: Ein Release Candidate von CyanogenMod 10.1! Das zwar den Besitzern eines Galaxy S2, die sich mit 10.2-Nightlies herumärgern, nicht sonderlich hilft, aber zumindest für CyanogenMod 10.1 endlich eine Perspektive in Richtung Stable darstellt. Und tatsächlich: Der Release Candidate läuft. Und zwar richtig nett, flüssig, schnell und zuverlässig.

Was nun tun, wenn man ein Gerät mit Exynos-4-Prozessor und/oder ein Samsung Galaxy S2 besitzt? Von CyanogenMod 10.2 ist derzeit noch abzuraten, das ist noch sehr am Anfang der Entwicklungsarbeit und läuft auf dem Galaxy S2 nur leidlich gut. Mit dem RC von 10.1 gibt es aber nun zumindest eine Perspektive, dass CyanogenMod 10.1 endlich in eine Stable-Version für das Galaxy S2 erscheinen dürfte. Zwar gibt es in Sachen Exynos-4-Prozessor noch einige offene Punkte, aber die erachtet man im CyanogenMod-Projekt offenbar als nicht so fatal, als dass man sich nicht schon mal mit RC befassen könnte.

Wer also auf seinem Galaxy S2 schon 10.2 hat und sich damit ärgert, sollte überlegen, ob er sein Smartphone nicht vielleicht nochmal plattmacht und das RC von 10.1 installiert und vorerst damit arbeitet.

Synchronisation von Kontakten zwischen iPhone und Google Contacts via CardDAV.

Seit einiger Zeit gibt es im Funktionsumfang von normalen Google-Konten einen kleinen Einschnitt in Sachen Funktionsumfang. Dieser Einschnitt betrifft die Synchronisation von Daten zwischen dem Google Kalender und Adressbuch zu iPhone und/oder iPad. Konnte man nämlich Kalender und Adressbuch bei allen Konten bis dato per ActiveSync synchronisieren (dass unter iOS „Microsoft Exchange“ heißt und auf Seiten von Google „Google Sync“), so ist das seit 30. Januar 2013 nur noch für Google-Konten möglich, bei denen bis zu diesem Datum Google Sync mindestens einmal eingerichtet wurde. Mit allen Google-Konten, die nach dem 30. Januar 2013 mit iPhone/iPad Kontakte und Kalender synchronisieren sollen, ist dieser Weg nun versperrt.

Aber: Es gibt Alternativen. Und zwar sehr gute, weil nämlich mit offenen Protokollen.

Kalender synchronisieren

Dazu sei an dieser Stelle nicht viele Worte verloren, weil ich hierzu vor einiger Zeit schon mal einen sehr umfangreichen Artikel geschrieben habe, der den Installationsweg ausführlich beschreibt:

Aber jetzt: Kontakte synchronisieren via CardDAV

Das CardDAV-Protokoll gehört ebenfalls zur Familie der WebDAV-Protokolle und ist speziell auf die Synchronisation von Kontaktdatenbanken ausgerichtet. Die Synchronisationsmechanismen sind dabei ähnlich zu CalDAV bei Kalendersynchronisationen, grundsätzlich ist CardDAV aber ein eigenes und auch relativ neues Protokoll. So neu, dass es beim iPhone bzw. im iOS-Betriebssystem von Anfang an gar nicht im Funktionsumfang war. Erst ab iOS 5 wurde CardDAV standardmäßig in iOS implementiert und ist seitdem auch verfügbar. Die Einrichtung einer CardDAV-Verbindung zum eigenen Google-Konto ist dabei relativ simpel und auf keinen Fall schwerer, als bisher mit Google Sync.

Der Startpunkt auf dem iPhone sind, wie immer, die Einstellungen und dort der Punkt “Mail, Kontakte, Kalender”. Hier geht es auf “Account hinzufügen …”. Der nächste Schirm zeigt die möglichen Synchronisationstechnologien dazu an:

iOS Synchronisationsauswahl

Alle DAV-Protokolle finden sich im letzten Menüpunkt, der etwas stillos unter dem Wort „Andere“ versteckt ist. Deshalb bitte hier drauf tippen, um zum nächsten Schirm zu kommen:

iOS Auswahl der DAV-Protokolle zur Synchronisation

Hier geht es nun richtig los, unter „Kontakte“ findet sich die Auswahlmöglichkeit zur Einrichtung eines CardDAV-Accounts. Bitte diesen Menüpunkt antippen und dann geht es schon darum, die eigenen Zugangsdaten zu hinterlegen:

iOS Einrichtung CardDAV

Die vorzunehmenden Einstellungen sind weitgehend selbsterklärend, deshalb nur im Schnelldurchlauf:

  • Account: Muss selbstverständlich aktiviert werden, hier lässt sich später aber dann auch vorübergehend die Synchronisation anhalten, falls das mal notwendig sein sollte.
  • Server: Ist die Gegenstelle, mit dem das iPhone-Gerät Verbindung zur Synchronisation aufnehmen soll. Das ist tatsächlich einfach nur „google.com“.
  • Benutzername: Das ist der Google-Kontoname, also im Normalfall die eigene Gmail- bzw. Googlemail-Adresse.
  • Kennwort: Selbsterklärend.
  • Beschreibung: Das ist eine Beschreibung, die frei gewählt werden kann. Bei mehreren konfigurierten Konten auf dem iOS-Gerät macht eine eindeutliche Beschreibung durchaus Sinn…

Wir gehen jetzt aber noch nicht zurück (und drücken natürlich auch nicht auf „Account löschen“), sondern wählen noch den Menüpunkt „Erweiterte Einstellungen“ für einen Kontrollblick aus. Der dortige Schirm sieht folgendermaßen aus:

iOS CardDAV Erweiterte Einstellungen

Hier geht es um die Verschlüsselung der CardDAV-Übertragung. SSL sollte hier aktiviert werden, der Standard-Port hierzu ist 443.

Nach dieser Überprüfung oben auf den Pfeil nach links „Google Contacts“ (oder wie auch immer die Beschreibung lautet) tippen, um zum vorherigen Schirm zurückzukommen. Dort dann nochmal auf den an der gleichen Stelle positionierten Pfeil tippen, der da lautet „Zurück“. Danach geht es nämlich nicht sofort zurück, sondern dann wird zunächst der Account geprüft. Hat alles seine Ordnung, erscheinen hinter allen Eingabefeldern kleine Häkchen und der Synchronisationsaccount ist erfolgreich eingerichtet.

Bitte dann einfach wieder zurück auf den Home-Bildschirm und mit einem Tippser auf die Kontakte-App gleich mal austesten, ob nun die ersten Adressen aus dem Google-Konto – sofern dort welche hinterlegt sind – eintrudeln.

Der Weg der Synchronisation

Ein spannendes Thema kommt an dieser Stelle: Hat man nämlich bisher Google Contacts nicht genutzt und sein Adressbuch ausschließlich auf dem iPhone gepflegt, dann passiert auch nichts. iOS synchronisiert ein lokales Adressbuch nicht ohne weiteres mit einem Adressbuch, das mit einem externen Dienst synchronisiert wird.

Damit also eventuell auf dem iPhone vorhandene Adressbestände ins Google-Contacts-Adressbuch kommen, müssen diese dorthin einmalig übertragen werden. Am einfachsten funktioniert das mit der iOS-App namens „My Contacts Backup“, die das Adressbuch auf iPhone/iPad als CSV-Datei exportieren kann. Diese kann man sich dann bequem per E-Mail an das eigene E-Mail-Postfach schicken lassen.

Hat man dann diese CSV-Datei, lässt sich diese auf der Website von Google Contacts unter https://www.google.com/contacts/ (ggf. zunächst anmelden) importieren. Auf der Hauptseite gibt es oben mittig angeordnet einen Button namens „Mehr“ und in diesem Untermenü dann den Menüpunkt „Importieren“. Dort dann einfach die oben generierte CSV-Datei importieren und schon nach einigen Augenblicken stehen die exportierten Adressen in Google Contacts zur Verfügung.

Hilfe! Alles doppelt!

Tatsächlich kann es zunächst passieren, dass nach der ersten Synchronisation im iOS-Adressbuch alle Kontakte doppelt auftauchen. Insbesondere dann, wenn wie im letzten Absatz der bisher lokal verwaltete Adressbestand in Google Contacts importiert wurde. iOS verwaltet alle Adressbücher strikt getrennt voneinander, also damit auch das lokale Adressbuch getrennt vom Adressbuch, das nun per CardDAV synchronisiert wird. Dass es hier mitunter dann Dubletten gibt, juckt iOS herzlich wenig.

Meine Empfehlung ist da ganz klar: Wer jetzt sein Adressbuch mit CardDAV synchronisiert und auch die lokalen Kontakte in Google Contacts importiert hat, auch nur noch mit diesem Adressbuch arbeiten und die lokalen Kontakte ersatzlos löschen. Sie gehen ja, wenn sie in Google Contacts importiert wurden, nicht verloren, sondern werden jetzt eben über die Google Cloud synchronisiert und das macht technisch gesehen keinen Nachteil aus. Denn der Zugriff auf einen synchronisierten Adressbestand ist selbst dann möglich, wenn das iOS-Gerät vorübergehend z.B. keine Verbindung haben sollte. Eine eventuell notwendige Synchronisierung erfolgt immer dann, wenn eine Netzverbindung besteht.

Also: Wenn es tatsächlich Dubletten in Ihrem Adressbestand gibt, dann ist die Vorgehensweise folgende (Bitte machen Sie dennoch unbedingt sicherheitshalber ein Backup mit der obig empfohlenen App):

  1. Schalten Sie vorübergehend die Synchronisation mit allen fernen Adressbüchern aus, sofern welche vorhanden und diese aktiv sind. Das können Sie bequem in den Einstellungen der einzelnen Adressbuchsynchronisationen tun, in dem sie den Schieber vorübergehend auf den „Off-Zustand“ schieben (siehe oben).
  2. Wenn Sie dann alle Adressbuchsynchronisationen ausgeschaltet haben, gehen Sie in die Kontakte-App und sehen hier dann logischerweise nur noch die Adressen, die tatsächlich lokal auf dem iOS-Gerät liegen. Wenn das dann tatsächlich die eine Hälfte der Dubletten ist, können Sie alle die lokalen Adressen hier getrost löschen.

Und wie lege ich nun neue Kontakte an?

Das ist jetzt nämlich echter Komfort: Es ist egal, wo Sie neue Kontakte anlegen – ob nun im iPhone, auf dem iPad (falls es auch mit Google Contacts synchronisiert), auf der Website von Google Contacts oder mit einem anderen Programm oder Gerät, das mit Google Contacts synchronisiert – sie haben nur noch eine Adressdatenbank und das ist die bei Google Contacts.

Sie machen es jetzt also wie die Profis mit dem Adressbuch – in der Cloud. Und wenn Ihnen aus irgendeinem Grund das iPhone abhandenkommt (sie es von der Ferne aus natürlich sperren), ist Ihnen wenigstens nicht Ihr Adressbuch abhanden gekommen, denn das liegt eben nun in der Cloud.