Neue Google-Richtlinien zwingen zum App Update

Ende 2017 hat Google neue Richtlinien für seinen Play Store veröffentlicht. Davon sind alle Apps betroffen, die über den Google Play Store vertrieben werden. Diese neuen Richtlinien treten bereits ab August 2018 in Kraft. Es wird also für Entwickler höchste Zeit, ihre Apps entsprechend anzupassen. Allerdings sind die erforderlichen Anpassungen mitunter ziemlich komplex. In meinem Blog-Beitrag fasse ich daher die wesentlichen Herausforderungen zusammen und zeige euch geeignete Lösungstechniken, damit euch das obligatorische Update reibungslos gelingt.

Fragmentierung ist seit jeher eine große Herausforderung im Android-Ökosystem, denn viele Anwendungen, die über den Google Play Store vertrieben werden, basieren beispielsweise noch auf alten Android- (SDK) Versionen. Zwar gewährleistet euch Android diesbezüglich eine gewisse Aufwärtskompatibilität, sodass diese Anwendungen auch auf neuere Betriebssystemversionen ausgeführt werden können, jedoch fehlen die neuesten Security-, Privacy- und Performance-Verbesserungen. Google ist in diesem Zusammenhang stets bemüht, allen Nutzern eine positive User Experience zu gewährleisten und möchte die genannte Fragmentierung der Android- (SDK) Versionen deshalb nun proaktiv reduzieren. Ende 2017 wurden daher entsprechende Änderungen der Store-Richtlinien bekannt gegeben.

Was wird sich ändern?

Zusammengefasst hat Google drei wesentliche Änderungen angekündigt:

• Ab August 2018 müssen alle neu veröffentlichten Apps und ab November 2018 alle Aktualisierungen von bestehenden Apps mindestens API Level 26 (Android 8.0) oder höher unterstützen. Damit soll sichergestellt werden, dass alle Apps von den neuesten Security-, Privacy- und Performance-Verbesserungen profitieren. Diese Mindest-API-Level-Grenze soll ab 2019 fortlaufend angepasst werden.
• Ab August 2019 wird es erforderlich sein, dass alle neuen und aktualisierten Apps mit nativen Libraries – zusätzlich zu ihrer 32-bit-Version – eine 64-bit-Version bereitstellen müssen. Der 32-bit-Support wird nicht entfallen. Google antizipiert allerdings, dass es künftig Geräte geben wird, die ausschließlich 64-bit-Code unterstützen und möchte Entwickler und Apps auf diese Weise vorbereiten.
• Ab Anfang 2018 wird der Play Store automatisch Sicherheits-Metadaten zu jeder App hinzufügen. Damit kann sichergestellt werden, dass eine App offiziell über den Play Store vertrieben wurde.

Die zuletzt genannte Änderung erfolgt automatisch. Hier müsst ihr nicht manuell eingreifen. Da die 64-bit-Unterstützung erst in der zweiten Hälfte des kommenden Jahres erforderlich ist, besteht für euch zunächst kein Zeitdruck. Im Folgenden möchte ich euch vor allem die erste Neuerung – die Unterstützung von API Level 26 oder höher – näher beschreiben, da es diese Aktualisierung in sich hat.

Welchen Impact hat diese Änderung?

Wie gesagt, müssen alle neuen und aktualisierten Apps, die über den Play Store vertrieben werden, ab August – respektive November – dieses Jahres mindestens API Level 26 unterstützen. Ihr fragt euch, was das nun konkret bedeutet und ob der Wert nicht einfach erhöht werden kann? Ich verrate es euch. Aber betrachten wir dazu zunächst einige technische Grundlagen.

Exkurs: API Level und Kompatibilität

Das API Level ist eine Zahl, mit der die Framework-API-Version einer Android Platform Version eindeutig identifiziert wird. Das bedeutet, jede Android Platform Version – zum Beispiel Android 8.0 − bietet bestimmte Funktionen, auf die Applikationen mittels einer entsprechenden Framework API zugreifen können. Diese API erhält eine eindeutige Nummer, nämlich das API Level. Wenn ihr mehr zum Thema API Level erfahren möchtet, empfehle ich euch einen Blick auf die entsprechende Stelle in der Android Dokumentation zu werfen.

Über die Parameter minSdkVersion, targetSdkVersion und compileSdkVersion könnt ihr mittels Angabe konkreter API Level die Kompatibilität eurer Apps steuern. Von besonderer Bedeutung ist dabei targetSdkVersion, da hierüber im Wesentlichen die Aufwärtskompatibilität gesteuert wird. Ändert sich in neueren Android-Versionen das Verhalten oder Aussehen, stellt Android anhand dieses Parameters und unter Einsatz bestimmter Kompatibilitätsmechanismen sicher, dass sich eure Apps so verhalten, wie gewünscht.

Eure entwickelten Apps müssen also zukünftig mindestens das API Level 26 als targetSdkVersion aufweisen, was natürlich einen sehr hohen Impact auf eure Apps hat. Das bedeutet, dass Android bei der Erhöhung dieses Wertes sämtliche Kompatibilitätsmechanismen entsprechend deaktiviert. Da von Android-Version zu Android-Version mitunter sehr viele Änderungen notwendig sind, müsst ihr für eure Apps meist manuell sicherstellen, dass diese auch mit der neuen Android-Version reibungslos funktionieren. Beispielsweise kann eine eurer Apps unter Umständen problemlos kompiliert werden und funktioniert augenscheinlich auch problemlos. Sie stürzt jedoch in speziellen Konstellationen ab, wenn sie Funktionen nutzt, deren Verhalten sich in der neuen Android-Version geändert hat. Eine Aussage, ob eine App kompatibel zu einer neuen Version ist, könnt ihr daher erst treffen, wenn ihr alle Workflows intensiv auf einem echten Gerät oder Emulator mit dieser Android-Version getestet habt.

Das bedeutet, ihr könnt die targetSdkVersion also nicht ohne weiteres erhöhen. Stattdessen solltet ihr eure Apps entsprechend migrieren und dediziert testen. Dabei solltet ihr euch folgendes merken: Je älter die unterstützte Android-Version ist, desto höher ist der Migrationsaufwand.

Was ist zu tun?

Wie ihr nun wisst, solltet ihr die targetSdkVersion nicht einfach erhöhen, sondern stattdessen eine schrittweise Migration durchführen. Google stellt Entwicklern für jede Plattform beziehungsweise für jedes API Update eine entsprechende Übersicht mit relevanten Änderungen zur Verfügung. Für die aktuelle Version gibt es zudem einen ausführlichen Migrationguide, dessen genereller Ablauf auch exemplarisch für andere Android-Versionen genutzt werden kann.

Damit ihr den Überblick behaltet und zusätzlich unerwartete Seiteneffekte vermeidet, sollte dieser Prozess idealerweise schrittweise erfolgen. Wenn eine App beispielsweise API Level 19 unterstützt, solltet ihr sie mithilfe des oben skizzierten Prozesses schrittweise auf 26 migrieren. Dabei bietet es sich an, die jeweiligen Plattformänderungen in Form von Checklisten abzuarbeiten.

Während einige Anpassungen relativ simpel oder gar nicht notwendig sind, weil etwa eine geänderte Funktion von einer bestimmten App überhaupt nicht genutzt wird, gibt es bestimmte Anpassungen, die auch tiefgehende Navigationsfluss- und Code-Änderungen mit sich bringen. Dazu zählen insbesondere die Runtime Permissions beim Update auf Android 6.0 beziehungsweise API Level 23. Der Aufwand für eine Migration ist daher direkt abhängig von der Architektur und dem Funktionsumfang einer individuellen App.

Was passiert, wenn ich meine App nicht aktualisiere?

Wie gesagt, betrifft der Zwang zur Unterstützung aktueller API Level zunächst nur neue oder aktualisierte Apps. Habt ihr bereits Apps veröffentlicht, sind diese erst einmal nicht direkt davon betroffen. Dementsprechend passiert zunächst nichts, wenn ihr bestehende Apps nicht aktualisiert.

Auch wenn vielleicht aktuell kein funktionales Update geplant ist, rate ich euch, die oben beschriebene Migration durchzuführen, damit ihr zeitnah auf typische Gegebenheiten im Lebenszyklus eurer Apps reagieren könnt. Dazu zählen zum Beispiel:

• Die Behebung von kritischen Fehlern: Etwa bei der Inkompatibilität mit neuen Android-Geräten oder wenn sich die Backend-Schnittstelle ändert.
• Die Realisierung von Änderungen: Beispielsweise bei einem neuen Logo oder einer neuen Corporate Identity, einem neuen Impressum oder aktualisierten Datenschutzbestimmungen.

Zu guter Letzt möchte ich euch nochmals darauf hinweisen, dass Google die API-Level-Grenze ab 2019 fortlaufend erhöht. Damit wird eine etwaige Migration immer umfangreicher. Zudem ist nicht auszuschließen, dass künftige Richtlinien auch bestehende Apps betreffen.

Mit adesso mobile solutions haben wir zudem einen erfahrenen Partner an der Seite, der die oben beschriebene Migration im Rahmen des Application Managements als Dienstleistung anbietet. Sowohl unsere Kunden als auch Interessenten, deren mobile Anwendungen nicht von uns entwickelt wurden, profitieren von den Synergieeffekten und Erfahrungswerten unserer bereits erfolgreich durchgeführten Migrationen.