Gefangene der Google-Android-Entwicklung

 (solutional.ee)
2 Punkte von GN⁺ 2023-08-28 | 1 Kommentare | Auf WhatsApp teilen
  • Eine kleine Wartungsarbeit, bei der die targetSdkVersion einer Legacy-Android-App an die Google-Vorgaben angepasst wurde, weitete sich zu einem Produktionsabsturz unter Android 13 und langen Wartezeiten bei der Google-Play-Prüfung aus
  • Bestehende Apps mussten API level 31 oder höher als Ziel angeben, um Nutzern auf Geräten mit einer Android-Version oberhalb des Zielniveaus weiterhin angeboten zu werden; der Autor erhöhte daher von API level 30 auf 33 und veröffentlichte das Update
  • Die erste Veröffentlichung wurde innerhalb einer Stunde genehmigt, doch auf echten Android-13-Geräten trat direkt nach dem Login ein Crash auf, und es gab keine Möglichkeit zum Rollback auf die zuvor funktionierende Version
  • Der korrigierte Build wurde direkt nach der Codeänderung eingereicht, blieb dann aber etwa 72 Stunden in der Prüfung hängen und wurde schließlich erst am 4. September nach 11 Tagen in der Produktion veröffentlicht
  • Native mobile Apps können trotz eigener Kontrolle über Quellcode und Infrastruktur beim finalen Auslieferungskanal von App-Store-Betreibern abhängig sein, was Notfall-Fixes, Rollbacks und die Release-Geschwindigkeit einschränkt

Ein kleines SDK-Update wird zum Produktionsvorfall

  • Betroffen war eine Legacy-Android-Anwendung eines Kunden
    • Die Funktionen waren seit Jahren fertig, und die App wurde nicht mehr aktiv weiterentwickelt
    • Idealerweise wollte man die stabile Version unverändert lassen
  • Google informierte am 18. August 2023 per E-Mail über die Anforderungen an Android-API-Level
  • Der Kern der Mitteilung war, dass bestehende Apps API level 31 oder höher als Ziel angeben mussten, um Nutzern auf Geräten mit neueren Android-Versionen weiterhin angeboten zu werden
  • Die genauen Auswirkungen auf bereits installierte Apps waren nicht klar, daher wurde zunächst die sicherere Auslegung verfolgt und das Update priorisiert
  • Bis zur Frist blieben weniger als drei Wochen, und Google hatte zu dieser Anforderung nicht früher erinnert

targetSdkVersion von 30 auf 33 geändert

  • Die Arbeit begann am 23. August, und die targetSdkVersion der App wurde von API level 30 auf 33 erhöht
  • Der erste Build schlug wegen einer inkompatiblen Analytics-Abhängigkeit fehl
    • Diese Abhängigkeit war nicht eng mit der Business-Logik verknüpft und konnte entfernt werden
  • Danach wurde die App im Android-Emulator ausgeführt, und die Kernfunktionen schienen wie zuvor zu funktionieren
  • Diese Änderung war ein Policy-bedingtes Update, das keinen neuen geschäftlichen Mehrwert lieferte

Erstes Google-Play-Release und Crash unter Android 13

  • Der Release-Prozess bei Google Play verlief zunächst reibungslos
    • Da die Legacy-App nur ein- bis zweimal im Jahr aktualisiert wurde, mussten mehrere Fragebögen ausgefüllt werden
    • Das Release bestand die Prüfung innerhalb einer Stunde und wurde in die Produktion ausgerollt
  • Am selben Abend gegen 21:30 wurde das Problem sichtbar, als der Kunde Nutzer meldete, die sich mit der neuen App-Version nicht anmelden konnten
  • Beim Test auf einem echten Android-Gerät stürzte die Anwendung direkt nach dem Login ab
  • Weitere Untersuchungen zeigten, dass das Problem auf Android 13, damals der neuesten Android-Version, auftrat, während frühere Versionen normal funktionierten
  • In der ersten Arbeitsphase war nur mit älteren Emulator-Images getestet worden, sodass das Kompatibilitätsproblem unentdeckt blieb
  • Mit Tests über mehrere Android-Versionen hinweg hätte sich das Problem finden lassen
    • Der kleine Änderungsumfang und der Zeitdruck vor der Frist erzeugten ein falsches Sicherheitsgefühl, doch die unzureichende Testabdeckung war ein Fehler des Teams

Eine Release-Struktur ohne Rollback

  • Die sicherste erste Reaktion wäre gewesen, das vorherige funktionierende Release wiederherzustellen und den Crash am nächsten Arbeitstag zu untersuchen, doch bei Google Play gab es diese Option nicht
  • Es gab keine Möglichkeit, das aktuelle Produktions-Release zurückzuziehen und die vorherige Version wieder zu aktivieren
  • Als nächste Maßnahme sollte die targetSdkVersion wieder auf 30 gesetzt und mit erhöhter App-Version ein neuer Build veröffentlicht werden, doch Google Play lehnte dies ab
    • Die veröffentlichte Anleitung wirkte so, als seien niedrigere Zielversionen bis zum 1. September erlaubt, doch es erschien ein Fehler, dass neue Updates API level 33 als Ziel haben müssten
  • Es wurde eine Verlängerung beantragt, die API level 30 bis zum 1. November erlauben sollte, doch der Veröffentlichungsfehler blieb bestehen
  • Damit blieb nur ein Weg: den Android-13-Crash beheben und ein neues Release einreichen

Fix unter Druck und lange Wartezeit in der Prüfung

  • Die fehlerhafte Version wurde über automatische Updates schrittweise an Nutzer ausgeliefert, und je schneller der korrigierte Build die Produktion erreichte, desto weniger Kunden wären betroffen
  • Der Crash ließ sich im Android-13-Emulator reproduzieren, und die nötigen Codeänderungen waren überschaubar
  • Allerdings musste spät am Abend unter Druck gearbeitet werden, und für umfassende Regressionstests blieb nur wenig Zeit
  • Der damalige Plan war eher pragmatisch
    • alle bekannten Crashes beheben
    • die wichtigsten Abläufe testen
    • die korrigierte Version sofort einreichen
    • breiter weiter testen und bei Bedarf weitere Updates vorbereiten
  • Der neue Build wurde bei Google Play eingereicht, doch auch nach zwei Stunden blieb er im Status Prüfung ausstehend und war gegen etwa 01:00 noch nicht genehmigt
  • Am nächsten Morgen stand die App weiterhin auf in review
  • Ein Großteil des Tages ging für Android-13-Tests und das Prüfen der Google Play Console drauf, dabei wurden noch einige kleinere Probleme gefunden und behoben, die weniger gravierend als der Login-Crash waren
  • Bis zum Ende dieses Tages war der Fix für die Produktion noch immer nicht genehmigt
  • Zu diesem Zeitpunkt wartete der korrigierte Build bereits etwa 72 Stunden; der Code war repariert, doch die Auslieferung steckte in einer intransparenten Prüfwarteschlange fest

Spätere Updates: Prüfung, Support-Chat, gestaffelter Rollout

  • Am 27. August wurde der Beitrag bei Hacker News veröffentlicht; in der Diskussion ging es sowohl um Android-Release-Strategien als auch um Kritik daran
    • Der Beitrag schaffte es auf die Startseite und erreichte über einige Tage hinweg etwa 130.000 eindeutige Besucher
    • Die statische Website, betrieben auf einem VPS für rund 5 € pro Monat, bewältigte den Traffic
    • Diese Aufmerksamkeit führte nicht zu einer Reaktion von Google, und das App-Update blieb weiter in Prüfung
  • Am 1. September wurde der Support-Chat entdeckt, der sich hinter dem Fragezeichen-Symbol in der Google Play Console verbarg
    • Der Support-Mitarbeiter versprach, die Prüfung zu beschleunigen, nannte aber weder einen klaren Zeitplan noch eine konkrete Lösung
    • Auffällig war, dass in der großen Hacker-News-Diskussion niemand diesen Weg erwähnt hatte
    • Möglicherweise erwarten Entwickler wegen des Rufs der schlechten Erreichbarkeit des Google-Supports keine direkte Hilfe
  • Am 4. September wurde das korrigierte Update nach 11 Tagen Prüfung schließlich veröffentlicht
  • Danach wurde statt einer sofortigen Auslieferung an 100 % der Nutzer ein weiteres kleines Folge-Release mit gestaffeltem Rollout eingereicht; dieses Update bestand die Prüfung innerhalb einer Stunde
  • Am 7. September wurde noch ein kleines Update eingereicht, um die Version zu ersetzen, die bereits 99,9999 % der Nutzer erreicht hatte
    • Sobald die neue Version in die Prüfung ging, stoppte Google ohne Vorwarnung automatisch den vorherigen Rollout
    • Hätte die neue Prüfung mehrere Tage gedauert, wäre selbst das vorherige Release den verbleibenden Nutzern nicht mehr angeboten worden
    • Auch das Zurückziehen der neuen Einreichung stellte den vorherigen Rollout nicht wieder her
    • Glücklicherweise war auch diese Prüfung innerhalb einer Stunde abgeschlossen

Wie Plattformkontrolle die Verantwortung in der Produktion verändert

  • Mobile Entwickler haben viele ähnliche Fälle erlebt, in denen Google oder Apple dringende Produktions-Fixes verzögerten, Apps entfernten oder ihre Entscheidungen kaum erklärten
  • Selbst wenn ein Technikteam Fehler schnell diagnostiziert und behebt, wird der Zeitpunkt, zu dem Nutzer die Lösung erhalten, von App-Store-Betreibern kontrolliert
  • Für normale Nutzer gibt es möglicherweise keine Rollbacks, keine alternativen Distributionswege und keine verlässliche Möglichkeit, Prüfungen zu beschleunigen
  • Auch wenn man Quellcode und Infrastruktur besitzt, verändert sich die Natur der Produktionsverantwortung, wenn man den finalen Auslieferungskanal nicht kontrolliert
  • Wenn eine native mobile App nicht zwingend nötig ist, spricht mehr dafür, die offene Webplattform zu bevorzugen
    • Webanwendungen können die nötigen Funktionen bereitstellen, während Deployment, Monitoring und Rollbacks oft direkt vom Team selbst gesteuert werden können
  • Für native Apps gibt es weiterhin sinnvolle Einsatzfälle
    • Abhängigkeit von Gerätefunktionen
    • Hintergrundausführung
    • Fälle, in denen die Verteilung über App-Stores erforderlich ist
  • Die Entscheidung für Mobile bedeutet, neben den Produktvorteilen auch die betrieblichen Kosten zu akzeptieren, die entstehen, wenn ein mächtiger Dritter in den Release-Prozess eingreift

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-28
Meinungen auf Hacker News

  • Ich habe diese E-Mail sowohl privat als auch beruflich bekommen.
    Privat entwickle und betreibe ich freiwillig eine Open-Source-App für die Nahverkehrssysteme von 16 Städten, und wegen einer Arbeit, von der niemand etwas hat, musste ich 16 Apps innerhalb von zwei Wochen aktualisieren.
    Meine App ist eine PWA, und die Android-Version ist im Grunde Cordova mit einigen Plugins, die ein paar native Optionen hinzufügen. Als ich Cordova aktualisierte, um die neue Ziel-Android-API zu unterstützen, gingen Plugins kaputt, die noch nicht aktualisiert waren, sodass ich das ganze Wochenende daran arbeiten und testen musste.
    Ehrlich gesagt würde ich die App am liebsten abschaffen und die Nutzer auf die Website schicken, damit sie dort die PWA installieren, aber der durchschnittliche Nutzer weiß noch nicht, wie das geht. Der erste Ort, an dem Nutzer nach einer App suchen, ist weiterhin der Play Store. Es wäre schon gut, wenn Google erlauben würde, PWAs direkt in den App Store einzureichen, und ich möchte das nicht jedes Jahr wiederholen.
    Beruflich reagiere ich ebenfalls im Chaosmodus. Bis Jahresende gibt es eine Legacy-App, die einige unserer Support-Kunden nutzen. Sie ist ziemlich komplex, und allein das Ändern der Ziel-API-Version hat in den Basistests mehrere Teile kaputtgemacht. Wir haben zwar eine Verlängerung bekommen, aber ich weiß, dass ein Update ohne jede Funktionsänderung, außer Google zu beschwichtigen, 1–2 Wochen Entwicklerzeit und 1–2 Wochen QA kosten wird. Und das, obwohl die App am Jahresende offiziell aus dem Store entfernt wird, sobald alle Kunden auf die neue App migriert sind.

    • Für solche Fälle gibt es Trusted Web Activities (TWA). Damit kann man eine PWA auch ohne Frameworks wie Cordova in den Play Store bringen.
      https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
      https://developers.google.com/codelabs/pwa-in-play#0
    • Um das klarzustellen: Es liegt nicht nur daran, dass Nutzer nicht wissen, wie es geht. Es liegt daran, dass Google und Apple es nicht so einfach gemacht haben wie die Installation einer App aus ihren App Stores. Das ist eine Entscheidung, und zwar eine bewusste Entscheidung.
    • Ich glaube, du verstehst die Nutzer falsch. Es ist nicht einfach ein Problem von Unwissenheit. Apps sollten wieder echte native Apps werden, also weg von Cordova. Es gibt kaum Web-Apps, die mit der Erfahrung einer gut gemachten echten App mithalten können, statt nur irgendein halbgar gebautes webbasiertes Ding zu sein.
    • Ich stimme zu. Ein paar meiner privaten Apps waren ebenfalls betroffen.
      Allerdings wurde diese Frist schon seit Monaten immer wieder kommuniziert, und es war klar, dass sie irgendwann deutlicher angezeigt werden würde. Die Formulierung selbst gefiel mir nicht, und es ergab auch keinen Sinn, sich zu beschweren, dass die Produktionsversion in Ordnung ist, aber die Testversion die Vorgaben nicht erfüllt.
      Außerdem ging es immer darum, ein neues Update zu pushen, und so läuft es jedes Jahr. Man konnte die App noch eine Weile weiterhin öffentlich lassen.
      Deshalb ist die Aussage, man habe nur zwei Wochen gehabt, nicht korrekt.
    • Ich weiß nicht, ob es hilft, aber in meiner Situation würde ich über ein paar App-Updates hinweg einen Bildschirm einbauen, der erklärt, wie man die PWA-Version installiert, und mich dann schrittweise aus diesen Problemen herausziehen. Man könnte wohl auch ein Feedbackformular anbieten, über das Nutzer ihre Schwierigkeiten melden können.

  • Ich stimme zu, dass Android-Entwicklung schwierig ist, aber der Autor hat zwei große Fehler gemacht.
    Erstens hat er die App nicht auf der neuesten Android-Version getestet. Das ist ein sehr großer Fehler und der Grund, warum wir 11 virtuelle Maschinen für alle von uns unterstützten Android-Versionen vorhalten.
    Zweitens sollte man eine App bei Google Play beim Veröffentlichen niemals von Anfang an an 100 % der Nutzer ausrollen. Stufenweiser Rollout ist der Standard, und wir gehen nach dem Veröffentlichen eines Releases anfangs nicht über 10 % der Nutzer hinaus. Wenn wir Vertrauen haben, rollen wir nicht auf 100 %, sondern auf 99 % aus. So kann man die Verteilung leicht stoppen, falls sie aus irgendeinem Grund angehalten werden muss, solange sie nicht an 100 % ausgeliefert wurde.
    Ob man es mag oder nicht: Diese beiden Methoden sind Taktiken, die erfahrene Android-Entwickler gut kennen.

    • Ich stimme zu, dass man es in vielerlei Hinsicht besser hätte machen können. Wie aber beschrieben, handelt es sich hier um eine Legacy-Anwendung, die heute nicht aktiv weiterentwickelt wird; dafür ein so robustes QA-System aufzubauen ergibt keinen Sinn. Diese App wurde vor langer Zeit von einem anderen Unternehmen geschrieben und hat nicht einmal einfache Unit-Tests. Das ist die Realität.
      Aber selbst mit einem derart komplexen System passieren Fehler, und das eigentliche Problem ist, dass es keine Möglichkeit gibt, ein Release zurückzunehmen, abzubrechen oder zurückzurollen.
      Wie hilft ein stufenweiser Rollout in dieser Situation allen Kunden? Wenn Endnutzer eine kaputte Version bekommen haben, gibt es dann eine Möglichkeit für sie, die funktionierende Version zu erhalten?
    • Ein Tipp: Dieses Eingabefeld akzeptiert auch Dezimalzahlen. Wir setzen es immer auf 99.99999999%, damit keine Nutzer versehentlich außen vor bleiben. Gleichzeitig bleibt, wie gesagt, die Möglichkeit, den Rollout abzubrechen.
    • Wenn man für jede unterstützte Android-Version virtuelle Maschinen vorhalten muss, dann sei es so. Aber am Ende fragt man sich schon, wofür eigentlich die 30 % Gebühr auf die Einnahmen genommen werden.
    • Das fühlt sich ein bisschen nach Victim Blaming an. Diese beiden Dinge sollten von vornherein kein Problem sein.
    • Was du sagst, ist völlig richtig und die einzig praktikable Art, Updates und Releases zu machen. Trotzdem ist es bedauerlich, dass man nicht erwarten kann, dass ein API-Update, nur weil es kompiliert, auch einfach funktioniert.

  • Ich verstehe die Reaktionen nicht, die den Autor des Originalbeitrags so in die Ecke drängen. Natürlich hätte er vorsichtiger sein können, und er hätte den Login auf der neuesten Android-Version testen können. Aber was, wenn es kein Login-Crash gewesen wäre? Was, wenn es auf der neuesten Version funktioniert hätte, auf anderen Versionen aber nicht? Wo zieht man die Grenze?
    Irgendwann muss man sagen: „Das ist buchstäblich eine Plattform, die von Millionen Apps und Millionen Entwicklern genutzt wird; Fehler können passieren, und sie sollten sich leicht beheben lassen, indem man etwa eine eigene Auslieferung stoppt oder eine bereits genehmigte frühere Version sofort wieder veröffentlicht, auch wenn man Tricks wie gestaffelte Rollouts nicht kennt.“ Gerade bei etwas wie einem App Store ist es ein grundlegendes Designprinzip, Dinge rückgängig machbar und wiederherstellbar zu machen.

    • Ich bin der Autor des Originalbeitrags, und danke, dass du mitdenkst. Wie ich schon in mehreren Antworten gesagt habe, stimme ich völlig zu, dass ich beim Testen besser hätte sein können. Natürlich gibt es in diesem Bereich immer Verbesserungsmöglichkeiten.
      Google hat die Deadline gesetzt, und noch einmal: Ich habe am 18. August zum ersten Mal davon gehört, vorher wusste ich nichts davon. Die Änderung wirkte damals trivial, und da die App auf älteren Android-Versionen wie zuvor funktionierte, habe ich nicht erwartet, dass sie so katastrophal scheitern würde.
      Ich bin kein erfahrener Android-Entwickler, habe aber insgesamt mehr als 15 Jahre Erfahrung in der Softwareentwicklung und daher ein gewisses Gespür dafür, wie Dinge funktionieren, was man erwarten und wovor man sich fürchten sollte. Dass ein 99,99999999% gestaffelter Rollout Best Practice ist, wenn man sich die Möglichkeit offenhalten will, ein aktuelles Release zumindest teilweise „zurückzuziehen“, wusste ich wirklich nicht.
      Ich hätte mir nie träumen lassen, dass es keine Möglichkeit gibt, ein aktuelles Release abzubrechen oder zu löschen, um zur vorherigen funktionierenden Version zurückzukehren. Das lernt man offenbar erst, wenn man so eine Situation durchlebt.
      Man kann mir vorwerfen, nicht jede Funktion auf jeder Android-Version getestet zu haben, und ich sehe das auch so. Aber ich hoffe, man öffnet die Augen und versteht, dass die derzeitige Art, wie der Play Store Releases handhabt, außerhalb des Play Store nichts ist, was ein vernünftiger Mensch so machen würde. Jeder kann irgendwann in so ein Problem geraten, und ich hoffe, dass dieser Beitrag und dieser Thread die Zahl der Entwickler reduzieren, die in eine ähnliche Situation kommen.
    • „Was, wenn es auf der neuesten Version funktioniert hätte, auf anderen Versionen aber nicht?“ ist eine schwache Ausrede. Auch bei einer Web-App muss man in mehreren Browsern testen.
      Smoke Tests für ein neues Release gehören zur grundlegenden Berufsethik.
      Gestaffelte Rollouts mit Rollback sind ebenfalls kein neues Konzept.
    • Dass man bei der Portierung einer App auf Android 13, also targetSdkVersion 33, keine Tests auf Android 13 gemacht hat, ist nicht zu entschuldigen.

  • Der Satz „Kehren wir zu offenen Webstandards zurück und holen uns die Kontrolle zurück“ wirkt vielleicht anders, wenn man feststellt, dass auch das Web zur Hälfte von Google kontrolliert wird – also von dem Unternehmen, das hier das Problem verursacht. Apple mit Safari, dem auf iOS faktisch einzigen Browser, ist auch nicht gerade ein Freund.

    • Das stimmt auch, aber zumindest kann man solche Probleme dort mit Dingen wie Rollbacks handhaben. In der aktuellen Situation weiß man, dass ein kaputter Build in Produktion ist und Telefone automatisch darauf aktualisiert werden, kann aber nichts tun. Das ist das Schlimmste.
    • Wenn man im Web hostet, kann das mehr Wartungsaufwand bedeuten, als nur die Kosten zu bezahlen.
      Ich bevorzuge eindeutig eine Website gegenüber irgendeiner App, die nur existiert, um besser zu tracken, aber dieser Beitrag las sich für mich wie ein Beispiel für halbherzige Wartung.
    • Wenn man sich weigert, auf den Zug aufzuspringen, der Nutzerprivatsphäre und Sicherheit priorisiert, dann ist Apple sicher kein Freund. Wenn man einen Grund nennen will, dann diesen.

  • Das ist eine Situation, die man nicht gewinnen kann.
    Microsoft steckt enorm viel Aufwand in Abwärtskompatibilität, und das verdient große Anerkennung. Aber dadurch wächst auch die Angriffsfläche erheblich.
    Ebenso stammen viele der schlimmsten Seiten von C++, das zu Unrecht viel Kritik abbekommt, aus seiner harten Haltung zur Abwärtskompatibilität. Möglichst alter Code, sogar alter C-Code, soll weiterhin kompilieren und sich wie erwartet verhalten; man geht sogar so weit, mit alten Binaries zu linken, deren Quellcode verloren gegangen ist.
    Die meisten betreiben diesen Aufwand nicht und erklären Altes aus Gründen der Wartbarkeit, Zuverlässigkeit und Sicherheit für ungültig.
    Egal für welchen Schnittpunkt man sich entscheidet: Irgendjemand hat das Nachsehen. Wenn nicht, nutzt niemand diesen Code.

    • Stimmt. Das ist eine Seite des Problems, und ich verlange auch keine übertriebene Abwärtskompatibilität. In dieser konkreten Situation ist die größte Sorge, dass es unter Android keine Möglichkeit gibt, ein Release zurückzunehmen, abzubrechen oder zurückzurollen, und alles hinter Googles Review-Prozess festhängt.
      Warum ist es unmöglich, ein problematisches Release „zurückzuziehen“ und das vorherige Release weiter als neueste Version anzuzeigen? Damit wäre in diesem Problemkontext das meiste gelöst.
    • Ein Mittelweg, der allen hilft, wäre meiner Ansicht nach, die API zu ändern und die Kompilierung brechen zu lassen. Dann müssen Entwickler die Kompilierfehler beheben und die API korrekt verwenden.
      Aber man sollte nicht das Verhalten einer bestehenden Funktion mit derselben Signatur ändern. Als API-Anbieter sollte man sein Bestes tun, damit Kompilierung eine Bedeutung hat.
    • Es gibt keine optimale Gewinnstrategie, aber man kann Apps auch separat vertreiben. Das ist keine Android-Anforderung, sondern eine Play-Store-Anforderung.
      In vielen Fällen ist das überhaupt nicht einfach und wird auch nie so viel genutzt werden wie die Play-Store-Version, aber es ist gut, einen Ausweg zu haben.
    • Der Autor schien sich hauptsächlich darüber zu beschweren, dass Google als Schiedsrichter darüber auftritt, welche Software Nutzer ausführen dürfen. Das API-Deprecation-Problem war nur der Anlass, der uns vor Augen geführt hat, wie anfällig wir für Googles Launen geworden sind.
    • Das lässt sich schwer als Entschuldigung für Google akzeptieren.
      Die meisten Anwendungen, die auf Android verteilt werden, zielen auf Android-Bytecode ab. Es sind keine nativ kompilierten Anwendungen.
      Der Grund, warum C++ schwer zu bewältigende Sicherheitsprobleme schafft, liegt in seiner Low-Level-Natur und in der Tatsache, dass bei nativen Binaries damit Schluss ist.
      Aber wenn es sich um Bytecode einer speichersicheren Sprache handelt, warum sollte man Sicherheitsfixes nicht zurückportieren können? Solchen Code auszuführen hat an sich den Charakter, Bytecode immer wieder neu zu kompilieren.
      Um zu sehen, wie absurd diese Position für Google ist: Die JVM kann bis heute Klassen, die auf Java 1.0 von 1996 zielen, ausführen und nutzen.
      Das ist kein Sicherheitsproblem, sondern ein Problem nach dem Motto: „Google will die Plattform nicht unterstützen.“
      Dass Google bei Artefakten mit nativ kompiliertem Code strenger ist, kann ich bis zu einem gewissen Grad verstehen. Aber eine pauschale Richtlinie nach dem Motto „Die App wurde für eine alte Android-Version gebaut, also unterstützen wir sie nicht mehr“ ist unsinnig. Das wirkt eher wie eine Methode, alte Apps aus dem Store auszusortieren, als wie Sicherheit.
      Besonders weil solche Richtlinien im Kern eine große Wartungslast auf Android-Entwickler abwälzen. Wenn man eine Anwendung möglichst breit unterstützen will, zielt man auf eine möglichst alte Android-Version. Kaum jemand zielt auf die neueste Android-Version, aus Angst, zu viele Kunden auszuschließen.
      Wenn Google Sicherheit und breiten Zugang zu aktuellen Android-Technologien ernst nähme, würde es versuchen, die Android-Runtime von der Betriebssystemversion zu entkoppeln. Es gibt keinen Grund, warum die ART- und Dalvik-Runtimes nicht wie andere Teile des Android-Ökosystems über Google Play verteilt werden könnten. Das würde auch dumme Situationen wie „Dafür braucht man Android 17 … ach, der Hardwarehersteller aktualisiert die Treiber nicht“ beseitigen.
      Aber das würde wohl den Verkauf neuer Geräte beeinträchtigen, also ist es wahrscheinlich inakzeptabel.

  • Es war immer offensichtlich, dass der Play Store und die darin eingesperrte Entwickler-„Community“ eine Falle sind. Erzwingene API-Upgrades sind nur ein Aspekt davon.
    Es gibt eindeutig Aufgaben, die Telefone oder mobile Apps am besten erledigen. Üblicherweise Dinge, die mit Bewegung zu tun haben, wie Navigation, oder solche, die auf Telefonsensoren angewiesen sind, etwa herauszufinden, welche Seite „oben“ ist. Aber fast alles andere lässt sich als Website machen.
    Wenn man allein eine Cross-Platform-Mobile-App wartet, muss das wirklich hart sein, und ich habe Mitgefühl. Allerdings habe ich vor langer Zeit beschlossen, nicht am Spiel der proprietären Plattformen und Gatekeeper teilnehmen zu wollen; daher ist es Mitgefühl nur aus der Perspektive eines vollständigen Außenstehenden.

    • Eigentlich lassen sich auch diese beiden Dinge problemlos in Browser-Apps erledigen.
      Das Einzige, was auf Mobile derzeit kaum einfach geht, sind wohl GPU-Compute-Shader. Aber sobald WebGPU aus Desktop-Browsern herüberkommt, wird auch das fallen.
      Was mir außerdem einfällt, ist allgemeines systemweites Dateimanagement. Das wird vermutlich nie kommen. Die File System API erlaubt es Nutzern zwar, Zugriff auf bestimmte Verzeichnisse zu gewähren, aber ich weiß nicht, ob diese Berechtigung über ein Neuladen der Seite hinaus bestehen bleibt.
    • Ich war überzeugt, dass App-Stores scheitern würden. Ich dachte nicht, dass sich genug Entwickler finden würden, um die Garantie aufzugeben, ihre Apps tatsächlich vertreiben zu können.
    • Es ist lustig, das auf einer Seite zu lesen, die Google oft dafür angreift, auf Android nicht genug Software-Gatekeeping zu betreiben, und das iPhone dafür lobt, besser zu sein, weil dort aggressiver durchgegriffen wird.
    • Man möchte wohl nicht ideologisch auf der Souveränität der Nutzer über ihre eigenen Geräte bestehen? Stattdessen sollte man klug und pragmatisch sein und einfach den Weg des geringsten Widerstands nehmen, geradewegs in den Käfig hinein.

  • Wenn man bedenkt, dass einer der SRE-Grundsätze von Google „Rollbacks sind normal“ lautet, ist das ironisch
    https://cloud.google.com/blog/products/gcp/reliable-releases...
    „Unsere Philosophie bei Google lautet: ‚Rollbacks sind normal.‘ Wenn in einem neuen Release ein Fehler gefunden oder mit vertretbarer Wahrscheinlichkeit vermutet wird, macht das Release-Team zuerst ein Rollback und untersucht danach das Problem. Eine Rollback-Anfrage wird nicht als Angriff auf das Release-Team oder auf die Person verstanden, die den fehlerhaften Code geschrieben hat. Vielmehr wird sie als das Richtige verstanden, um das System für die Nutzer so zuverlässig wie möglich zu machen. Solange die beobachteten Probleme in der Rollback-Änderungsliste beschrieben sind, fragt niemand: ‚Warum wurde diese Änderung zurückgerollt?‘“

    • Stand letztes Jahr war das Ergebnis der Kombination aus Google-Play-Richtlinien und Android-Updates: Wenn man eine App über den Play Store ausliefert, besteht die einzige Möglichkeit für ein Rollback darin, sie zu löschen und die Nutzerdaten zurückzusetzen
      Ein Downgrade auf einen niedrigeren versionCode ist nicht möglich, und der versionCode wird vom Entwickler festgelegt
      Android 11 verbietet das Schreiben in den „permanenten“ Speicher des Telefons, außer über Medien-Ausnahmen oder die Nutzung der DocumentFile-API, die lokale Ordner wie Cloud-Speicher behandelt. DocumentFile ist für viele Anwendungsfälle unbrauchbar
      Entwickler können hasFragileUserData setzen; dann sollte der Nutzer beim Löschen gefragt werden, ob die Daten entfernt werden sollen. Wegen eines Google-/Android-Bugs kann dieser Dialog jedoch unter Umständen nicht angezeigt werden
      Wenn die App gelöscht wird und der Nutzer die Daten nicht löscht, verhindert Android ein Downgrade auf einen niedrigeren versionCode
      Wenn man MANAGE_EXTERNAL_STRORAGE anfordert, kann man das normale java.io.File verwenden
      Google Play erlaubt MANAGE_EXTERNAL_STRORAGE nur in Ausnahmefällen
    • „Rollback für mich, kein Rollback für dich“

  • Dasselbe ist mir auch bei mehreren Apps passiert, die auf einem von mir erstellten Framework basierten. Eine neue API-Version kollidierte mit bestehenden Abhängigkeiten, und es war wirklich enorm viel Arbeit nötig, um einfach zu genau dem bereits vorhandenen Zustand zurückzukehren
    Ich habe jetzt deutlich mehr Respekt vor Microsoft, wo Dinge aus den 90ern auf aktuellem Windows problemloser laufen als eine Mobile-App, die ich vor vier Jahren für Android geschrieben habe

    • Wenn das verwendete Framework nicht von Google stammt, ist das eine unfaire Aussage
      Man würde Microsoft ja auch nicht dafür verantwortlich machen, dass Adobe Flash im Windows-11-Store nicht läuft, oder?

  • Ich sehe viel zu viele Nachteile und kaum Vorteile darin, Apps dazu zu zwingen, ausschließlich über einen einzigen „selbst genehmigten“ App Store verteilt zu werden.
    Der vermeintliche Vorteil ist ironischerweise, dass die Betreiber des App Stores vor der Veröffentlichung auf Malware und Viren prüfen. Apps voller Google-Werbung und Google/Facebook-Tracker werden dagegen in jeder Form willkommen geheißen.
    Außerdem macht es Nutzern das Suchen, Installieren und Aktualisieren von Apps leichter — sofern man zwischen Milliarden von Spiele-Apps und extrem ähnlichen Apps, die nur veröffentlicht wurden, um Werbung auszuliefern oder persönliche Daten zu sammeln, überhaupt das Gewünschte findet.
    Der Nachteil ist, dass man den Launen der App-Store-Betreiber ausgeliefert ist und keine Kontrolle über den Veröffentlichungsprozess der App hat. Nicht ich kann entscheiden, ob und wann ich eine App veröffentlichen darf, sondern die App-Store-Betreiber entscheiden je nachdem, ob es ihnen gerade passt. Meiner Meinung nach sollte dieses Recht ausschließlich bei den Nutzern liegen.
    Kommerzielle native Apps, zum Beispiel Homebanking-Apps, möchte ich nach dem Login in einen privaten Bereich der Entwicklerwebsite herunterladen können. Die App sollte per GPG signiert sein, und die Integrität des Pakets sollte überprüfbar sein. Auch automatische Updates wären möglich.
    Für Open-Source-Apps gibt es den F-Droid-Store, und man kann eigene Repositories hinzufügen. Ich gebe zu, das ist etwas technisch und nicht für alle geeignet. Es würde sehr helfen, wenn F-Droid auf neuen Smartphones vorinstalliert wäre, aber ich glaube nicht, dass Google das zulassen würde.
    Eine weitere realistische Option sind PWAs. Meiner Meinung nach brauchen nur sehr wenige Apps native Funktionen, und fast alles andere lässt sich mit PWA-Technologie umsetzen. Man muss den Nutzern auch keine Updates zuschieben oder sie zu Upgrades auffordern.
    Proprietäre, kommerzielle App Stores, die unter dem Vorwand betrieben werden, den Nutzern das Leben leichter zu machen und „bessere Sicherheit“ zu bieten, sind ein „großartiges“ Mittel, mit dem Apple und Google Milliarden Dollar an der Arbeit unabhängiger Entwickler verdienen und — im Fall von Google — persönliche Daten der Nutzer sammeln und verkaufen sowie auf alle möglichen Arten Werbung verkaufen können.

    • Du hast noch einen weiteren Vorteil vergessen: Man kann den Boston Strangler[0] aus dem Haus halten. Wenn man den Nutzern die Hände auf den Rücken bindet, kann man festlegen, unter welchen Bedingungen sie dein Werk nutzen. Keine Piraterie, keine Werbeblocker.
      Genau deshalb folgten Spieleentwickler in den 80er- und 90er-Jahren weitgehend dem „Licensed by Nintendo“-Modell, und mobile App-Entwickler Ende der 2000er taten dasselbe mit dem iOS App Store. Sie wollen nicht direkt mit den Nutzern zusammenarbeiten, um den Plattformbetreiber zu umgehen. Sie wollen, dass der Plattformbetreiber den Nutzern die Hände bindet, und nehmen dabei in Kauf, dass auch ihnen selbst die Hände gebunden werden.
      Nehmen wir zum Beispiel Banking-Apps: Banken wollen eine sichere Remote Attestation. Sie wollen Nutzer blockieren, die Credential-Stuffing-Angriffe auf die App durchführen, verhindern, dass Malware die Banking-App öffnet und auf den Button „Geld an Betrüger überweisen“ tippt, verhindern, dass Nutzer die kryptografischen Geheimnisse für Tap-to-Pay extrahieren, und auch verhindern, dass gestohlene Geheimnisse in die Smartphone-App eingeschleust werden.
      Die App kann nicht selbst überprüfen, ob dem Nutzer die Hände gebunden sind. Sie braucht eine dritte Partei in der Boot Chain oder in EL3, der nicht der Nutzer vertraut, sondern die Bank. Deshalb will man nicht einfach nur die App und eine Signatur bereitstellen, sondern möchte, dass Google das übernimmt, damit Google den Nutzern die Hände binden kann.
      Wichtig ist: Alle nutzerseitigen Vorteile von App Stores sind nachträgliche Rationalisierungen. Das Ziel war von Anfang an, Nutzer einzusperren. Denn für sie sind Nutzer so etwas wie kleine diebische Mücken. Das ist der „leise Teil“, den sie nicht laut aussprechen.
      Bitte möge Googles WEI-Vorschlag nie Realität werden und PWAs keinen Zugriff auf Attestation-Funktionen bekommen. Google betreibt bereits diesen Unsinn nach dem Motto „In unbekannten Browsern darf man sich nicht anmelden“, und dieser Krebs muss sich nicht weiter ausbreiten.
      F-Droid ist großartig. Googles Spielchen auf Android müssen gestoppt werden. Die EU hätte das tun können, aber auch die USA sollten es tun und dafür sorgen, dass es international gilt.
      [0] Der Codename der MPAA für nicht-kommerzielles Kopieren in kleinem Umfang, also das Aufnehmen von Fernsehsendungen mit einem Videorekorder. Jack Valenti war wirklich ein furchtbarer Mensch, oder?

  • Ich bin seit Jahren gegen die Entwicklung mobiler Apps, weil man in dem Moment, in dem man sich für eine mobile App entscheidet, die Kontrolle über sein Produkt oder seinen Dienst an einen Dritten abgibt.
    Dem kann man nur schwer widersprechen.
    Wenn „Unterstützung“ bedeutet, darauf zu hoffen, auf HN oder Twitter hilfreiche Aufmerksamkeit zu bekommen, sind wir auf dem falschen Weg.