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.

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.

iOS und Google Sync nur noch bis Ende Januar.

Da die Artikel zum Thema Google Sync und iPhone in meinem Blog die mit Abstand am häufigsten aufgerufenen Artikel sind, hier doch nochmal ein wichtiger Hinweis für alle, die zukünftig ihr iPhone oder iPod per Google Sync mit ihren Kalendern und Adressbüchern in ihrem Google-Account synchronisieren möchten. Denn Google Sync steht auf der Abschussliste bei Google und für viele Nutzer ist Google Sync ab 30. Januar 2013 nur noch Geschichte.

Google Sync und der technische Hintergrund

Das Ende von Google Sync ist relativ einfach zu erklären, wenn man sich anschaut, was dahintersteckt: Eine Synchronisierungstechnologie namens ActiveSync von Microsoft. Und dazu ist dann ein kleiner Exkurs recht interessant:

ActiveSync hat eine recht lange Geschichte und hat seine Wurzeln im Mobilbetriebssystem Windows Mobile und der Möglichkeit zur Synchronisieren von Smartphone-Inhalten mit Windows-Betriebssystemen ab Windows 95 und NT 4. Für diese Anforderung wurde ActiveSync entwickelt und das war schon zu den Zeiten, als Windows Mobile mit dem einst allmächtigen Betriebssystem PalmOS von US Robotics konkurrierte, revolutionär. Denn während Palm-Geräte im am PC angeschlossenen Zustand nur dann synchronisierten, wenn die Synchronisierung am Gerät oder an der Dockingstation (die „Cradle“) die Synchronisierung explizit der Knopfdruck gestartet wurde, erledigten Windows-Mobile-Gerätschaften die initiale Autorisierung direkt nach dem Anstecken an den PC und synchronisierten während der Verbindung permanent, selbstständig und zuverlässig. Wurde in Outlook ein neuer Termin eingetragen, erschien dieser Termin im gleichen Moment auch im angeschlossenen Windows-Mobile-Gerät. ActiveSync machte es möglich und nicht zuletzt diese Technologie war ein wichtiges Abgrenzungskriterium zur Palm-Welt.

Aufgebohrt wurde ActiveSync dann später, in dem das Protokoll als Basis für die Synchronisierung zwischen Windows-Mobile-Geräten und dem Microsoft-Exchange-Server diente und fortan Exchange ActiveSync hieß. Das Prinzip der Echtzeitsynchronisierung blieb, lediglich der Übertragungsweg und die Gegenstation änderte sich. Nicht mehr der Bürorechner auf dem Schreibtisch war das andere Ende, sondern der Exchange-Server des Unternehmens, der dann die zu synchronisierten Inhalte direkt mit dem Postfach des Nutzers synchronisierte.

Und obwohl ja Microsoft verschrieen ist als ein Unternehmen, das rücksichtslos seine eigenen Standards entwickelt und verbreitet – ActiveSync hatte schon sehr früh eine relativ offene Lizenzierungspolitik und konnte von Herstellern von Personal Digital Assistants, später dann Smartphones, aber auch Herstellern von Mailsystemen und Betreibern von Maildiensten (kostenpflichtig) lizenziert werden. Das hatte natürlich einen Hintergrund, denn neben den Einnahmen durch die Lizenzierung war durch den Einsatz von ActiveSync potentiell das jeweilige Produkt auch fähig zum Kontakt mit Windows-Mobile-Gerätschaften oder auf der anderen Seite mit dem Exchange-Server.

Und da ergaben sich dann die seltsamsten Allianzen. Während z.B. RIM mit dem Blackberry und dem dazugehörigen Protokoll sowohl Endgeräte als auch Synchronisierungssoftware mit dem Mailsystem aus einer Hand liefert, können z.B. iPhone und Android-Geräte per ActiveSync mit dem Exchange-Server synchronisieren. Vorteil: Diese Synchronisierung kostet den Nutzer nichts, während bei Blackberry lange Zeit der Synchronisierungsdienst Geld kostete und zwar nicht zu knapp. Dass also ActiveSync so zuverlässig funktioniert und für Hersteller von Smartphones recht freizügig lizenziert werden kann, ist mit einer der Gründe, warum Microsoft lange Zeit die eigene Mobilbetriebssystemstrategie hat schleifen lassen und es hat ihnen zumindest im Business-Bereich nicht sonderlich viel finanziellen Schaden beschert. Das Lehrgeld in der Smartphone-Jungsteinzeit haben tatsächlich andere bezahlt.

Google und ActiveSync

Auch Google gehört zu den ActiveSync-Lizenznehmern und das wiederum aufgrund einiger Umstände:

  1. Google benötigt ActiveSync im hauseigenen Mobilbetriebssystem Android, um Android-Handys mit der Exchange-Welt synchronisieren lassen zu können.
  2. Google muss seine eigenen Kalender- und Kontaktedienste mit Schnittstellen zu ActiveSync ausstatten, um Smartphones mit anderen Betriebssystemen als Android eine Synchronisierung zu ermöglichen. Dies gilt insbesondere für das iPhone, denn obwohl das iPhone direkt (ohne ActiveSync) mit Google Mail synchronisieren kann, wird ActiveSync wiederum zum Synchronisieren von Kalender und Kontakten benötigt, da das iPhone hier keine eigenen Schnittstellen zu den Google-Diensten hat (warum auch immer).

Punkt 2 muss man sich ob des Irrsinns auf der Zunge zergehen lassen – weil Apple und Google zu doof sind, iOS und Google-Dienste vollständig miteinander synchronisieren lassen zu können, muss ausgerechnet ein lizenzpflichtiges Microsoft-Protokoll den Lückenfüller machen.

Und weil genau das Kostenthema der ActiveSync-Lizenzierung für die (kostenlos nutzbaren) Google-Dienste eine Rolle spielen dürfte, ist ActiveSync nun wohl bei der Synchronisierung der Google-Accounts auf der Abschussliste. Immerhin gibt es aber einige begrenzende Ausnahmen für das Ende:

  • Wird ein Google-Account bis zum 30. Januar 2013 noch mit ActiveSync synchronisiert, bleibt diese Möglichkeit für diesen Account auch darüber hinaus noch erhalten. Das Ende gilt also ab 30. Januar 2013 nur für bis dato noch nicht per ActiveSync synchronisierende Google-Accounts. Inwiefern es bis zu diesem Datum tatsächlich aktiv genutzt werden muss oder ob die Nutzung irgendwann in der Vergangenheit schon ausreicht, wird sich zeigen.
  • Ebenfalls nicht betroffen von dem Ende sind Google-Accounts, die innerhalb der inzwischen auch kostenpflichtigen Google Apps angelegt sind. Google-Apps-Accounts werden also auch weiterhin per ActiveSync synchronisieren können und wer da noch das Glück hatte, in der vergangenen Kostenlos-Zeit einen Google-Apps-Account einzurichten, lebt immer noch komplett kostenlos.

Die kostenlosen Protokollalternativen zum Synchronisieren

Google beendet das Synchronisieren mit ActiveSync vor allem auch deshalb, weil es inzwischen kostenlose Protokolle zum Synchronisieren gibt, die auch hinreichend zuverlässig sind. Für das Synchronisieren von Kalender ist dies das CalDAV-Protokoll und für das Synchronisieren von Kontakten das CardDAV-Protokoll. Beide Protokolle sind (inzwischen offizielle) IETF-Standards und im Falle von CardDAV eine beschwerliche Geburt hinter sich.

Das ist auch einigermaßen nachvollziehbar, denn ein einheitlicher, herstellerübergreifender Standard liegt zunächst einmal nicht im Interesse der Hersteller von eigenen, proprietären Protokollen und da lange Zeit die Motivation an echten freien Protokollen fehlte, dauerte es auch dementsprechend, bis beide Protokolle jeweils die Hürden genommen hatten, um als IETF-Standard zu gelten – zumal alle involvierten Hersteller innerhalb der IETF auch an der Standardisierung beteiligt waren. Das Wort „Sabotage“ will niemand in den Mund nehmen, aber IETF-Standardisierung ist mitunter auch interessant für Beobachter, die sich für Rudelbildungen im Tierreich interessieren.

Was zu tun ist … Empfehlungen

Also, grundsätzlich: ActiveSync muss niemand unbedingt einsetzen, der auch CalDAV und CardDAV einsetzen kann. Beide Protokolle sind gleichwertig funktional, wenn es um die Synchronisierung von Kalender- und Kontaktdatenbanken geht. Selbstverständlich ist ActiveSync deutlich mächtiger, allerdings richten sich viele Funktionen von ActiveSync vornehmlich an Unternehmen, die z.B. in einer Exchange-Infrastruktur alle Arten von Clients – vom Windows-Rechner mit Outlook bis zum iPhone – synchronisieren und zentral verwalten müssen.

Innerhalb von Google-Diensten ist ActiveSync bzw. der eigene Name „Google Sync“ immer als bisher mehr oder weniger notwendige Alternative zu verstehen. Es besteht also kein Grund zur Panik und auch nicht zu übermäßiger Hektik in Sachen Synchronisierungen zum Google-Konto einrichten. Wer bis zum 30. Januar 2013 Google Sync bzw. ActiveSync nicht einsetzt, wird es auch danach nicht vermissen, den selbst das iPhone, die Ausgeburt an Apple-Scheuklappentum in Sachen offenen Standards, unterstützt CalDAV und CardDAV

Zu erledigende Aufgaben für Besim

Das inzwischen gewachsene Sammelsurium an Blog-Artikeln, die sich mit der Synchronisierung zwischen Google-Konto und iPhone beschäftigen, aktualisieren. Die Artikel, die Google Sync erklären, werden mit Hinweisen darauf versehen, dass Google Sync nicht mehr bei allen Arten Google-Accounts funktioniert, der Artikel zu CalDAV so überarbeitet, dass es wieder als Empfehlung gilt und ein Artikel zu CardDAV neu geschrieben, das ich bisher großflächig ausklammerte, weil die CardDAV-Unterstützung von Google vor zwei Jahren, als ich das erste und bis dato letzte Mal in dieser Konstellation mit CardDAV experimentierte, schlicht unmöglich war.

Manchmal hilft die wohltuende Wirkung der Zeit doch, dass Hersteller sich ihren Möglichkeiten zur Interoperabilität bewusst werden.

Musik und Android.

Seit einigen Wochen ist ja nur noch mein Samsung Galaxy S2 als Haupttelefon am Start. Das iPhone 4S fristet seitdem das Dasein als Backup-Telefon für den Fall, wenn ich am S2 wieder etwas mit CyanogenMod herumspiele und nebenbei erreichbar sein mag. Grundsätzlich aber läuft CyanogenMod 10 mit Android 4.1.2 als Unterbau erstaunlich zuverlässig, obwohl CM 10 eigentlich noch im Alphastadium ist (und ich eine Installation ausdrücklich nicht empfehle).

Aber zum Thema Musik auf dem Smartphone: Einer der großen Pro’s für das iPhone war bisher die Musikabspielfähigkeit. iTunes unter Windows ist zwar ein Krampf und die iPod-App unter iOS bei weitem unter seinen Bedienmöglichkeiten (schon mal jemand probiert, in einer Wiedergabeliste ein bestimmtes Lied anzusteuern?), allerdings funktioniert das Synchronisieren zwischen iTunes und iOS idiotensicher.

Ausgangszustand bei mir.

Ich habe inzwischen 51 GB Musik auf etwas über 7.000 Audiodateien. Und ich bin kein Fan von Musik in der Cloud, weil ich Musik auch im Wald höre und mit meiner Datenflatrate von O2 eigentlich besseres zu tun habe, als die Bandbreite für das Herumblasen von Musik zu verschwenden. Zudem habe ich keine Lust, meine Musik in einer proprietären Cloud eines Anbieters verschwinden zu lassen und ein für allemal von dessen Spielregeln abhängig zu sein. Meine Musik ist meine Musik.

Beim iPhone tut es (gerade noch so) die 64-GB-Version des iPhones, um hier meine gesamte Medienbibliothek zu versammeln. Das ist dann ziemlich lässig, wenn man wirklich überall seinen gesamten Musikbestand parat hat. Muss ich niemandem erzählen. Vielleicht nur noch den Herstellern von Android-Gerätschaften, denn hier sind selbst Android-Smartphones mit 32 GB Speicherplatz eher Raritäten. Mit 16 GB geht allerdings wirklich gar nichts mehr bei mir.

Mein Samsung Galaxy S2 hat zwar auch nur 16 GB Speicher onboard, allerdings einen großen Luxus: Einen MicroSD-Kartensteckplatz. Das war das Kaufargument Nr. 1. Denn zusammen mit diesem kleinen Winzling hier, ist mein Smartphone mit nun schlappen 80 GB Speicherplatz der Chef im Wald:

SanDisk Ultra 64GB MicroSD XC

Habe ich übrigens einmal erwähnt, dass mich so ein Stück Kunststoff wirklich schwer begeistern kann? 7.000 Musikstücke, gut 420 Alben – alles in diesem Plättchen drin. Allein der Musikimport auf das Kärtchen hat gut zwei Stunden gedauert.

Musikplayer unter Android.

Die iPod-App ist schon käsig zu bedienen – unter Android sieht es glatt noch dunkler aus. Android selbst hat keinen eigenen Musikplayer, so dass die Hersteller von Android-Geräten ihre eigenen Player mitbringen. Die sind an Abspielkomfort mindestens genauso langweilig zu bedienen, wie die iPod-App unter iOS.

Eine Alternative ist der Musikplayer Apollo aus dem CyanogenMod-Projekt, der seit neuestem auch über den Google-Play-Store bezogen werden kann und hochgelobt wird. Allerdings nicht von mir, weil mir Apollo nicht behagt. Mit einer Medienbibliothek in den Dimensionen, wie ich sie herumzutragen pflege, ist Apollo sichtlich beschäftigt. Die Albenauswahl ist eine Blätterorgie und zu alldem kommt noch, dass die Albumbilder, mit denen ich weitgehend alle Musikstücke verziert habe, nur sehr unzuverlässig geladen werden und mitunter auch wild durcheinandergewürfelt angezeigt werden. Solche Schlampereien kann ich gar nicht haben.

Ein alter Bekannter: Winamp.

Wenn mir einer vor über zehn Jahren gesagt hätte, dass ich irgendwann einmal wieder Winamp nutzen würde, hätte ich ihn ausgelacht. Winamp war so ein Biest von Player. Für mich als (damaliger) MP3-Verlegenheitsnutzer völlig überladen, mit einem völlig verquakten Bedienoberfläche und einer Musiksortierung die allenfalls für 700 Audiofiles taugte, sicherlich aber nicht für 7.000. Winamp war direkt aus der Hölle und als das Windows-Media-Player-Zeitalter kam war ich froh, Winamp los zu sein.

Für Android gibt es ebenfalls Winamp, das mit der Windows-Version vermutlich kaum etwas zu tun hat, außer ein paar Reminiszenzen auf die einfach grässliche Grafik. Der pixelige Winamp-Blitz ist jedenfalls geblieben – ansonsten ist Winamp auf Android erstaunlich gut. Nach dem Start findet man sich in der zentralen Auswahl, in der der Benutzer nach Interpret, Titel oder Album suchen kann. Die Suche ist blitzschnell, Musik wird in Echtzeit angezeigt und abgespielt.

Dass für all das noch nicht mal Geld fällig ist, sondern Winamp unter Android per In-App-Kauf um einige Funktionen zusätzlich ergänzt werden kann, macht es noch sympathischer. Die knapp 4 Euro für die Pro-Version sind es zumindest wert.