Wir lesen in den Medien wir viel über die Tücken der Android-Fragmentierung. Sicher kämpfen Entwickler von Android-Apps mit dem Design mobiler Applikationen, die auf verschiedenen Geräten und OS-Versionen funktionieren sollen. Sie kämpfen auch für größere Anerkennung und Umsätze im offenen App-Markt, der keine Testphasen vorsieht und niedrige Preise verlangt. Eine Erhebung von Flurry Analytics zeigt, dass bei jedem Dollar, den ein Entwickler auf Apples iOS verdient, mit Googles Android nur 24 Cent zu verdienen wären. Autsch! Trotz dieser Herausforderungen unternimmt Google sehr viel, um die Anliegen der Entwickler zu adressieren - Lösungen gibt es bereits. In meiner Keynote erläuterte ich diese Bemühungen, zusammen mit anderen Faktoren, die Android hin zu mehr Einheitlichkeit und einer strafferen App-Entwicklungslandschaft führen sollen. Blicken wir ca. fünf Jahre zurück: Steve Jobs dachte gerne anders, und die Arbeit seines Unternehmens brachte ein flüssiges Betriebssystem hervor - mit Top-Hardware und dem iTunes-Ecosystem - ein wahrlich vertikaler Markt nach Apple-Stil. Andy Rubin von Google hingegen wollte Apps auf allen Arten von Geräten aller Hersteller verbreiten - ein mehr horizontaler Ansatz. Eine schwierige Aufgabe angesichts der verschiedenen Architekturen, IP-Techniken, Bildschirme, Funktionen, Kosten, regionalen Unterschiede etc. In gewisser Weise hat sich Google an das bereits bestehende, fragmentierte Ecosystem angepasst - mit dem Ziel der Vereinheitlichung und der Möglichkeit für Unternehmen, sich doch differenzieren zu können. Der erste wichtige Schritt hin zur Vereinheitlichung kam im Dezember 2011 mit der Veröffentlichung von Android 4.0 'Ice Cream Sandwich'. Diese Android-Version war die erste, die Smartphone- und Tablet-Anwenderschnittstellen (APIs) in einer User-Interface-Umgebung namens 'Holo' vereint und über OS-Versionen und Geräte hinweg portierbar ist. Google hat viele weitere Schritte unternommen, um die Android-Entwicklungslandschaft zu vereinheitlichen:

• Workshops und Schulungen für Entwickler (und OEMs) sollen die Portierbarkeit erhöhen, z.B. das Android Training im Dezember 2011. Vereinheitlichte Designprinzipien in Android helfen Entwicklern, dass sie nur einmal Code schreiben müssen - unabhängig vom Gerät - mithilfe von Layouts und Fragmenten.
• Im Februar 2012 wurde die Android Design Website freigeschaltet, damit Entwickler sicherstellen können, dass ihre Inhalte auf verschiedenen Geräten funktionieren.
• Eine strenge und ständig weiterverbesserte Compatibility Test Suite (CTS) sowie ein dazugehöriges Compatibility Definition Document (CDD) garantieren, dass Geräte höchste Qualität bei den API-Standards bieten (über 25.000 Tests).

Jede dieser Maßnahmen hat eine freundlichere, konsistentere Entwicklungsumgebung geschaffen, was das Design weiterer und besserer Apps fördert! Vor nicht langer Zeit sah der Android-Markt fast wie der 'Wilde Westen' aus. Man wusste nie, was auf einen zukam. In vielen Fällen funktionierten Apps nicht auf allen Geräten, was vor allem bei den ersten Tablet-PCs vermehrt auftrat. Das Motorola Xoom scheiterte kläglich - trotz eindrucksvoller Hardware und Marketing-Kampagnen - teilweise aufgrund der App-Kompatibilität. Dies ist einer der vielen Gründe, warum Entwickler Schwierigkeiten bei der Bereitstellung von qualitativ hochwertigen Inhalten auf Android-Geräten haben. Und Entwickler müssen natürlich auch ihr Ziel verfolgen, mit ihren Apps Erlöse zu erzielen. Viele dieser Probleme wurden mit der Einführung von Google Play im März 2012 adressiert:

• Malware blockiert: Nach Malware (oder Schad-Applikationen) wird nun dauerhaft gesucht und diese sofort blockiert bzw. entfernt.
• Erweiterte Verfügbarkeit: Google Play ist nun in 130 Ländern verfügbar (30 im letzten Jahr). Ein großer Sprung! Mehr Interessenten für die Inhalte – mehr Erlöse.
• Verbesserungen beim In-App-Kauf: Immer mehr Apps nutzen dieses Modell. Anwender, die versuchen, eine App schnell zwischendurch (oder zuhause) zu kaufen, entscheiden sich eher für den Kauf, wenn sie dazu nicht extra ihre Kreditkarte zücken müssen. Bei iOS werden neue App-Käufe direkt auf dem iTunes-Konto des Anwenders verbucht. Dies wird zunehmend auch bei Android der Fall sein.
• Automatische Verlängerung von Abos und Einmalzahlungen: Automatische Aboverlängerung erlaubt den Anbietern von Inhalten (Zeitungen, Magazine), die Informationen auf Android-Tablets und -Smartphones des Anwenders bereitzustellen - und das mit automatischer monatlicher Zahlung.
• Direkte Abrechnung über den Netzbetreiber: Die Zahl der Netzbetreiber, die eine direkte Abrechnung anbieten, hat sich in den USA im letzten Jahr von zwei auf 15 erhöht. Damit erscheinen App-Käufe auf der Mobiltelefonrechnung des Verbrauchers.
• Verbesserte Architektur-Filter: Da MIPS nun offiziell von Google in Android unterstützt wird, muss der Markt nur noch kompatible Apps bereitstellen. Dies führt zu einer verbesserten Benutzererfahrung.

In Wirklichkeit kümmern sich die meisten Verbraucher wenig um die Architektur ihres Smartphones, Tablets oder Computers. Entscheidend ist eine konsistente Benutzererfahrung mit Apps, über Geräte hinweg, unabhängig von der Architektur. Google adressiert dies durch vereinheitlichte APIs und Änderungen bei Google Play. Verbraucher wollen auch eine Auswahl haben, was durch die Open-Source-Natur von Android unterstützt wird. Und auch die Kosten müssen stimmen: Durch Architektur-Neutralität und Diversität sorgt Google für einen erheblichen Anstieg bei den Stückzahlen für Android-Tablets und -Smartphones, was die Kosten für den Verbraucher wiederum senkt. Mit der offiziellen Unterstützung der MIPS ABI kamen 1,8 Mio. MIPS-basierte Tablets zur Android-Familie hinzu (Tendenz weiter steigend). Googles MIPS-Support in der Release 8 des Android Native Development Kits (NDK) ist ein Vorteil für Anwender und Entwickler: Dies ebnet den Weg für eine noch größere Anzahl an Entwicklern, Apps zu erstellen, die kompatibel zu mehreren Architekturen sind. Entwickler erhöhen damit ihre Umsätze, und Verbraucher profitieren von einer größeren Fülle an Anwendungen, die sie konsequent auf verschiedenen Geräten nutzen können. Für Hersteller (OEMs) bedeutet die Offenheit von Android mehr Differenzierung. Dies ist in Anbetracht der hohen Anzahl an Android-Smartphones mit verschiedenen Schnittstellen auch nötig: HTC Sense, Samsung TouchWiz und Motorola MotoBlur sind nur einige davon. Jedem Hersteller steht es frei, sich für verschiedene SoCs (Qualcomm, TI, Nvidia, Actions, Ingenic), Architekturen (MIPS, Intel, ARM), Bildschirmgrößen und zusätzliche/weniger Hardware (GPS, Bluetooth, NFC, Mobilfunk etc.) zu entscheiden. Diese Differenzierung kommt dem Verbraucher zugute, denn er hat eine größere Auswahl. Auch der OEM profitiert, indem er seine Produkte kundenspezifisch anpassen kann. Dank der o.g. Google-Initiativen wächst die App-Kompatibilität zwischen all diesen Geräten rasant, was die Fragmentierung verringert und doch eine Diversifizierung erlaubt. Was muss also ein Entwickler tun? Die Differenzierung schätzen und sich an die APIs halten! Neuste APIs verwenden (Fragmente & Layouts) und portabel kodieren (aufbauend auf Dalvik oder mit der NDK r8 für alle Architekturen). Folgen Sie diesem Rat und nutzen Sie die vielen Tools, die Google anbietet, bei Google Play und anderswo. Die Grundlagen zur Vereinheitlichung von Android sind gelegt. Die Entwickler müssen diesem Weg nur folgen. Nehmen Sie teil an der Diskussion. / Autor: Amit Rohatgi, Principal Architect Mobile, MIPS Technologies