Google Play wird Entwickler bald dazu zwingen, App Bundles anstelle von APKs hochzuladen, was unangenehme Sicherheitsfragen zu dieser Anforderung aufwirft.
Letzter November, Google angekündigt dass Entwickler neue Apps im Play Store im Android App Bundle (AAB)-Format anstelle einer APK veröffentlichen müssen. Erst neulich erinnerte Google die Entwickler an diese bevorstehende Anforderung und löste damit einen Feuersturm der Kontroversen aus von Nutzern, die glauben, dass Google APKs vernichtet, Sideloading verhindert, App-Stores von Drittanbietern behindert usw was nicht.
Es stimmt, dass Android App Bundles eine ziemlich große Abweichung vom klassischen APK-Format darstellen, an das Sie sowohl als Benutzer als auch als Entwickler vielleicht gewöhnt sind. Obwohl die Verwendung von App Bundles einige Vorteile mit sich bringt, gibt es einen Schlüsselaspekt, der einige Entwickler und Sicherheitsexperten zu Recht beunruhigt.
In diesem Artikel gehen wir auf die Kritik ein, die wir an der Umstellung auf Android App Bundles gesehen haben, sowie auf einige Lösungsvorschläge und sprechen auch über die von Google vorgeschlagene Lösung für diese Probleme.
Hintergrund
Bevor dies geschieht, müssen wir jedoch ein wenig darüber sprechen, wie die App-Verteilung auf Android im Allgemeinen funktioniert. Wenn Sie bereits wissen, wie App-Signierung und App-Bundles funktionieren, können Sie diesen Teil überspringen.
APKs
Apps auf Android werden größtenteils in APK-Dateien verteilt. Ein APK enthält den gesamten Code und die gesamten Ressourcen einer App sowie einige Sicherheitsfunktionen wie ein Signaturmanifest. Wenn ein APK installiert wird, wird es im Grunde nur in einen bestimmten Ordner kopiert und einer internen Datenbank installierter Apps hinzugefügt.
Unterschriften
Während der Installation wird auch die Signatur dieser App überprüft, um sicherzustellen, dass sie gültig ist. Wenn die App bereits installiert ist, vergleicht Android die Signatur der neuen App mit der bereits installierten. Wenn die Signatur ungültig ist oder nicht übereinstimmt, verweigert Android die Installation der App.
Diese Signaturprüfung ist ein wichtiger Teil der Sicherheit in Android. Dadurch wird sichergestellt, dass die von Ihnen installierte App gültig ist und mindestens aus derselben Quelle stammt wie die, die Sie bereits installiert haben. Wenn Sie beispielsweise Folgendes installieren: meine Lockscreen Widgets-App aus dem Play StoreSie können einigermaßen sicher sein, dass ich derjenige bin, der es unterschrieben hat, und dass es authentisch ist. Wenn Sie dann versuchen, ein Update für Lockscreen Widgets von einer zwielichtigen Website eines Drittanbieters zu installieren, und dies fehlschlägt, wissen Sie, dass jemand dieses APK manipuliert hat, möglicherweise um Malware hinzuzufügen.
Der zum Signieren einer App verwendete Schlüssel ist (idealerweise) niemals öffentlich veröffentlicht. Dies wird als privater Schlüssel bezeichnet. Der private Schlüssel wird dann verwendet, um den in der Signatur der App angezeigten Schlüssel zu generieren, den sogenannten öffentlichen Schlüssel. Dies wird von Android und App-Stores verwendet, um die Gültigkeit einer App zu überprüfen. Ich werde nicht näher darauf eingehen, wie genau Sie einen öffentlichen Schlüssel generieren können, ohne den privaten Schlüssel offenzulegen, da dies eine Menge Verschlüsselungsmathematik erfordert. Wenn Sie weitere Einzelheiten wünschen, schauen Sie hier vorbei Googles Dokumentation zum Signieren von APKs oder recherchieren Sie über mathematische Einwegfunktionen.
Eine weitere Funktion von App-Signaturen ist die Möglichkeit, Berechtigungen nur auf Apps mit übereinstimmenden Signaturen zu beschränken. Android führt dies intern für viele Funktionen durch, wobei nur Apps, die mit demselben Schlüssel wie das Framework signiert sind, auf bestimmte Funktionen zugreifen können.
App-Bundles
Nachdem wir nun einen kurzen Überblick über APKs und Signaturen gegeben haben, sprechen wir über App Bundles. Hier kommen APK-Ressourcen ins Spiel. Ressourcen sind Dinge wie Layouts, Bilder, Audio usw. Im Grunde handelt es sich dabei um alles, was kein Code ist. Um unterschiedliche Anzeigekonfigurationen und unterschiedliche Sprachen besser zu unterstützen, können Entwickler mehrere Versionen derselben Ressource erstellen, die je nach Gerät und Sprache verwendet werden.
Aber in einem APK sind alle diese Ressourcen vorhanden, egal welche Sie verwenden. Und sie nehmen Platz ein. Abhängig von der Komplexität Ihrer App können für viele Geräte viele ungenutzte Ressourcen vorhanden sein. Dafür sind App-Bundles gemacht. Entwickler können ein App-Bundle wie ein APK erstellen und dieses App-Bundle kann dann wie ein APK in den Play Store hochgeladen werden.
Google verwendet dieses App Bundle dann, um eine ganze Reihe verschiedener APKs für verschiedene Gerätekonfigurationen zu generieren. Jedes App Bundle enthält nur die für diese Konfiguration erforderlichen Ressourcen. Wenn ein Benutzer diese App herunterlädt, wird ihm das generierte APK bereitgestellt, das seiner Konfiguration entspricht. Dies trägt dazu bei, sowohl die Download- als auch die Installationsgröße von Apps zu reduzieren und so Bandbreite und Speicherplatz zu sparen.
Wenn Sie ein für Ihr Gerät spezifisches APK installieren, ist es für Sie natürlich schwieriger, es einfach auf ein anderes Gerät zu kopieren und problemlos zu installieren. Abhängig von Ihrer Perspektive kann dies eine gute oder eine schlechte Sache sein. Einerseits erschwert es die Piraterie, da Nutzer nicht mehr über die gesamte App verfügen. Andererseits erschwert es aus dem gleichen Grund die rechtmäßige Archivierung von Apps.
App-Signierung
Da es sich bei Android App Bundles nicht um APKs handelt, können Sie nicht einfach eine AAB-Datei öffnen und direkt auf einem Gerät installieren. Wenn Sie eines in den Play Store hochladen, verwendet Google das Bundle, um verschiedene (unsignierte) APK-Dateien zu generieren. Diese APKs müssen dann signiert werden, bevor sie installiert werden können.
Anstatt den Entwickler zu bitten, die generierten APKs zu signieren und erneut hochzuladen, verwaltet Google die Signierung stattdessen selbst. Der Play Store verwendet entweder einen neuen Schlüssel, den er erstellt, oder fragt den Entwickler nach dem Schlüssel, den er zum Signieren verwendet APKs. Bei beiden Optionen übernimmt Google die öffentliche Signatur für den Entwickler und stellt einen Upload bereit Schlüssel. Google verwendet den Upload-Schlüssel zur internen Überprüfung und stellt sicher, dass das App Bundle (oder in manchen Fällen APK), das der Entwickler hochlädt, das richtige ist.
Wenn ein Upload-Schlüssel kompromittiert wird oder verloren geht, können Entwickler einen neuen anfordern und der für die Verteilung der App verwendete Signaturschlüssel bleibt unverändert.
App Signing bietet noch viel mehr, aber das ist es, was für diesen Artikel relevant ist. Wenn Sie möchten, können Sie mehr über App Bundles und App Signing lesen dieser Medium-Artikel von Wojtek Kaliciński.
Kritik
In der Theorie und in der Praxis sind App Bundles ziemlich großartig. Sie reduzieren den Datenverbrauch und die Installationsgröße, ohne dass der Benutzer etwas tun muss. Doch aufgrund der Art und Weise der Implementierung haben einige Entwickler und Sicherheitsforscher in den letzten Monaten Bedenken geäußert. Bevor ich diese Bedenken zusammenfasse, möchte ich kurz sagen, dass das meiste, was unten geschrieben steht, direkt ist basierend auf einer Artikelserie vom Entwickler Mark Murphy von CommonsWare. Seine Artikel sollten Sie unbedingt lesen, da sie mehr Details und Kritik aus der Sicht eines Entwicklers liefern.
Sicherheit
Im klassischen Vertriebsmodell hält ein Entwickler den Schlüssel, den er zum Signieren eines APK verwendet, privat. Es wird niemals der Öffentlichkeit zugänglich gemacht und nur autorisierte Personen sollten Zugriff darauf haben. Dadurch wird sichergestellt, dass nur diese Personen eine gültige APK generieren können.
Wenn Sie jedoch App Bundles im Play Store verwenden, ist Google derjenige, der den Schlüssel verwaltet, der die APKs signiert, die Benutzer erhalten. Der Standard Verhalten für neue Apps, die auf Google Play hochgeladen werden ab August 2021 besteht darin, dass Google einen eigenen Verteilungsschlüssel erstellt, den es vor dem Entwickler geheim hält.
Entwickler reichen ein neue Apps Google wird standardmäßig ihren privaten Schlüssel für sie verwalten lassen, obwohl Entwickler Aktualisierungen an senden vorhandene Apps kann weiterhin APKs verwenden oder Sie können zur AAB-Verteilung wechseln, indem sie einen neuen Schlüssel generieren, den Google für neue Nutzer verwenden kann. Vorhandene Apps sind nicht erforderlich von der APK-Verteilung auf Android-App-Bundles zu wechseln, obwohl diese Option ihnen bei Bedarf zur Verfügung steht. Nach einigem Widerstand Google wird es sogar möglich machen Sie können Ihren eigenen privaten Schlüssel hochladen, mit dem Google sowohl für neue als auch für bestehende Apps signieren kann. Keine dieser Situationen ist ideal, da Google in jedem Fall Zugriff auf Ihren privaten Schlüssel hat, wenn Sie dies wünschen Verwenden Sie Android App Bundles (und Entwickler haben in dieser Angelegenheit keine andere Wahl, wenn sie nach August eine neue App einreichen möchten 2021!)
Obwohl wir davon überzeugt sind, dass Google die Sicherheit sehr ernst nimmt, gibt es kein Unternehmen auf der Welt, das vor Datenschutzverletzungen gefeit ist. Wenn sich der Schlüssel, den Google zum Signieren Ihrer App für die Verbreitung verwendet, in einem dieser Verstöße befindet, kann jeder eine Version Ihrer App signieren und sie so aussehen lassen, als wäre sie von Ihnen signiert worden. Und einige Entwickler und Sicherheitsexperten sind mit dieser Möglichkeit nicht zufrieden. Das ist zwar eine sehr, sehr geringe Möglichkeit, aber die Tatsache, dass es überhaupt eine Möglichkeit ist, macht einigen in der Infosec-Community Angst.
Wenn Entwickler Android-APKs signieren, kann jeder APKs von Google Play verifizieren, blindes Vertrauen ist nicht erforderlich. Es ist ein elegantes Design, das nachweisbare Sicherheit bietet. App-Bundles stellen das auf den Kopf und scheinen so strukturiert zu sein, dass sie die Bindung an einen Anbieter fördern. Es gibt viele alternative technische Ansätze, die kleine, noch von Entwicklern signierte APKs bereitstellen würden, aber diese würden Play nicht bevorzugen. Beispielsweise könnten alle APK-Varianten vom Entwickler generiert und signiert und dann in einen beliebigen App-Store hochgeladen werden.
Es gibt sicherlich Argumente darüber, ob es besser ist, die sichere Speicherung privater Schlüssel in den Händen von Google oder einzelnen Entwicklern zu belassen. Aber diese Entwickler verwenden (wahrscheinlich) normalerweise kein zentrales Repository für ihre Schlüssel. Indem Entwickler gezwungen werden, Play App Signing zu verwenden, muss ein böswilliger Angreifer die Sicherheit von Google nur einmal durchbrechen, um Tausende oder Millionen Schlüssel abzurufen.
Was es wert ist, hier ist, was Google darüber sagt, wie es Ihren Signaturschlüssel in seiner Infrastruktur schützt:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate bei Google"]Wenn Sie Play App Signing verwenden, werden Ihre Schlüssel auf derselben Infrastruktur gespeichert, die Google zum Speichern seiner eigenen Schlüssel verwendet.
Der Schlüsselzugriff wird durch strenge ACLs und manipulationssichere Prüfprotokolle für alle Vorgänge geregelt.
Alle generierten und mit dem Schlüssel des Entwicklers signierten Artefakte werden Ihnen in der Google Play Console zur Überprüfung/Bescheinigung zur Verfügung gestellt.
Um Schlüsselverlusten vorzubeugen, erstellen wir außerdem sehr häufig Backups unseres Primärspeichers. Diese Backups sind stark verschlüsselt und wir testen regelmäßig die Wiederherstellung aus diesen Backups.
Wenn Sie mehr über die technische Infrastruktur von Google erfahren möchten, lesen Sie die Whitepapers zur Google Cloud-Sicherheit.[/blockquote]
Trotzdem sind alle Geräusche, Verlust und Diebstahl möglich. Und Audit-Trails helfen nur dabei, zukünftige Angriffe zu verhindern. Sie erhalten keine beschädigten Schlüssel zurück.
Möglichkeit unautorisierter Änderungen
Ein großes Problem bei der Art und Weise, wie Google App Bundles eingerichtet hat, ist die Möglichkeit, dass unbefugte Änderungen zu einer App hinzugefügt werden. Der Prozess des Extrahierens von APKs aus einem App Bundle ist grundsätzlich mit Änderungen verbunden, da Google jedes APK manuell erstellen muss. Während Google hat versprochen, keinen Code einzufügen oder zu ändernDas Problem mit dem App Bundle-Prozess besteht darin, dass er dazu in der Lage ist.
Hier sind ein paar Beispiele dafür, wozu ein Unternehmen in der Position von Google die Macht hat:
Angenommen, es gibt eine sichere Messaging-App, mit der Menschen ohne das Risiko staatlicher Überwachung kommunizieren können. Dies könnte ein unglaublich nützliches Werkzeug für Menschen sein, die gegen eine autoritäre Regierung protestieren, oder sogar für Menschen, die einfach nur ihre Privatsphäre wahren wollen. Diese Regierung möchte sehen können, was App-Benutzer sagen, und könnte versuchen, Google dazu zu zwingen, eine Überwachungs-Hintertür in den Code der App einzufügen.
Dieses Beispiel ist etwas harmloser, aber es ist auch etwas, das einige Leute beunruhigt. Nehmen wir an, es gibt eine App, die täglich Millionen von Downloads erhält, aber keine Werbung oder Analysen enthält. Das ist eine riesige Datenquelle ohne Möglichkeit, auf diese Daten zuzugreifen. Als Werbeunternehmen möchte Google möglicherweise auf diese Daten zugreifen.
Im klassischen APK-Modell der App-Verteilung kann Google die Apps nicht ändern, ohne die Signatur zu ändern. Wenn Google die Signatur ändert, insbesondere bei einer beliebten App, werden die Leute es bemerken, weil das Update nicht installiert werden kann. Aber mit App Bundles und App Signing könnte Google stillschweigend seinen eigenen Code in Apps einschleusen, bevor es sie verteilt. Die Signatur würde sich nicht ändern, da Google der Signaturschlüssel wäre.
Deutlich sein, Es ist unglaublich unwahrscheinlich, dass diese Beispiele eintreten. Google neigt dazu einfach sich ganz aus schwierigen Märkten zurückzuziehen, anstatt sich anzupassen. Aber auch wenn es unwahrscheinlich ist, ist es dennoch möglich. Nur weil ein Unternehmen verspricht, dass etwas nicht passieren wird, ist es keine Garantie dafür.
Code-Transparenz
Als Google diese Bedenken hörte, führte es diese Woche eine neue Funktion namens „ Code-Transparenz für App-Bundles. Code-Transparenz ermöglicht es einem Entwickler im Wesentlichen, eine zweite Signatur zu erstellen, die mit der App an Benutzer versendet wird. Diese zusätzliche Signatur sollte aus einem separaten privaten Schlüssel erstellt werden, auf den nur der Entwickler Zugriff hat. Allerdings gibt es bei dieser Methode einige Einschränkungen.
Code-Transparenz deckt nur Code ab. Das mag angesichts des Namens offensichtlich erscheinen, bedeutet aber auch, dass Benutzer keine Ressourcen, das Manifest oder alles andere überprüfen können, bei dem es sich nicht um eine DEX-Datei oder eine native Bibliothek handelt. Während böswillige Änderungen an Nicht-Code-Dateien in der Regel weitaus geringere Auswirkungen haben, stellen sie dennoch eine Lücke in der Sicherheit der App dar.
Ein weiteres Problem bei der Code-Transparenz besteht darin, dass es keine inhärente Überprüfung gibt. Für eine, Es handelt sich um eine optionale FunktionDaher müssen Entwickler daran denken, es bei jeder neuen APK einzuschließen, die sie hochladen. Im Moment muss dies über die Befehlszeile und mit einer Version von erfolgen bundletool Das kommt nicht mit Android Studio. Selbst wenn ein Entwickler es einbindet, verfügt Android über keinerlei integrierte Überprüfung, um zu überprüfen, ob das Code Transparency-Manifest mit dem Code in der App übereinstimmt.
Es liegt am Endbenutzer, dies selbst zu überprüfen, indem er das Manifest mit einem öffentlichen Schlüssel vergleicht, den der Entwickler bereitstellen kann, oder indem er das APK zur Überprüfung an den Entwickler sendet.
Während Codetransparenz die Bestätigung ermöglicht, dass kein Code in einer App geändert wurde, beinhaltet es keinerlei Überprüfung für andere Teile einer App. Es besteht auch kein inhärentes Vertrauen in den Prozess. Sie könnten argumentieren, dass Sie, wenn Sie Google nicht vertrauen, wahrscheinlich der Aufgabe gewachsen sind, die Überprüfung unabhängig durchzuführen, aber warum sollten Sie das tun müssen?
Es gibt andere Probleme mit der Code-Transparenzfunktion, z wies darauf hin von Mark Murphy aus CommonsWare. Für eine tiefergehende Analyse der Funktion empfehle ich die Lektüre seines Artikels.
Komfort und Auswahl für Entwickler
Ein dritter (und letzter für diesen Artikel) Grund, warum einige Entwickler Probleme mit App Bundles haben, ist der eingeschränkte Komfort und die eingeschränkte Auswahl.
Wenn ein Entwickler eine neue App im Play Store erstellt, nachdem Google begonnen hat, App Bundles zu verlangen, und er sich dafür entscheidet Die Standardoption, Google die Verwaltung des Signaturschlüssels zu überlassen, hat keinen Zugriff auf diese Signatur Schlüssel. Wenn derselbe Entwickler diese App dann in einem anderen App Store vertreiben möchte, muss er seinen eigenen Schlüssel verwenden, der nicht mit dem von Google übereinstimmt.
Das bedeutet, dass Benutzer entweder über Google Play oder über Quellen von Drittanbietern installieren und aktualisieren müssen. Wenn sie die Quelle ändern möchten, müssen sie die App vollständig deinstallieren (wobei möglicherweise Daten verloren gehen) und sie neu installieren. APK-Aggregatoren mögen APKMirror Dann muss man sich dann auch mit mehreren offiziellen Signaturen für dieselbe App auseinandersetzen. (Technisch gesehen müssen sie dies bereits tun, da Sie mit der App-Signierung einen neuen, sichereren Schlüssel für neue Benutzer erstellen können. Für sie und andere Websites ist dies jedoch noch schlimmer, wenn alle hat es zu tun.)
Die Antwort von Google auf dieses Problem besteht darin, den App Bundle Explorer oder Artifact Explorer in der Play Console zu verwenden, um die resultierenden APKs aus dem hochgeladenen Bundle herunterzuladen. Ähnlich wie bei Code Transparency ist dies keine vollständige Lösung. Die von der Play Console heruntergeladenen APKs werden für verschiedene Geräteprofile aufgeteilt. Während die Play Console das Hochladen mehrerer APKs für eine Version einer App unterstützt, ist dies bei vielen anderen Vertriebskanälen nicht der Fall.
Daher gehen viele Vorteile der Verwendung von App Bundles verloren, wenn Entwickler mehrere Stores verwalten, was die Verteilung erschwert. Mit Nachrichten, die Windows 11 Ist Unterstützung für Android-Apps erhalten Dank des Amazon Appstore glauben einige, dass die App-Bundles-Anforderung Entwickler davon abhalten wird, auf Amazon zu vertreiben. Natürlich geht es Google in erster Linie um den eigenen App Store, aber genau darum geht es brachte sie mit der Konkurrenz in heißes Wasser sie dazu bringen, etwas zu machen kleine, versöhnliche Veränderungen erfahren Sie, wie App-Stores von Drittanbietern auf Android funktionieren.
Ein paar Probleme im Zusammenhang mit mehreren Stores sind die App-Interkonnektivität und Schnelltests.
Beginnen wir mit der App-Interkonnektivität. Haben Sie schon einmal eine App heruntergeladen, die Funktionen hinter einer Paywall sperrt? Mit ziemlicher Sicherheit. Einige Entwickler nutzen die Funktionen für einen In-App-Kauf, andere entscheiden sich jedoch möglicherweise dafür, eine separate, kostenpflichtige App zu erstellen. Wenn diese Add-on-App installiert wird, werden die Funktionen der Haupt-App freigeschaltet.
Aber was hindert jemanden daran, das Add-on einfach von einer Raubkopie-Quelle zu installieren? Nun, es gibt viele Optionen für Entwickler, aber mindestens eine beinhaltet die Verwendung signaturgeschützter Berechtigungen. Angenommen, die Haupt-App erklärt eine signaturgeschützte Berechtigung. Die Add-on-App erklärt dann, dass sie diese Berechtigung nutzen möchte. Im Idealfall verfügt die Add-on-App auch über eine Art Lizenzüberprüfungsfunktion, die eine Verbindung zum Internet herstellt, um sicherzustellen, dass der Benutzer legitim ist.
Wenn beide Apps die gleiche Signatur haben, erteilt Android der Add-on-App die Berechtigung und die Piraterieschutzprüfungen werden bestanden. Wenn die Add-on-App nicht über die richtige Signatur verfügt, wird die Berechtigung nicht erteilt und die Überprüfung schlägt fehl.
Mit dem klassischen APK-Verteilungsmodell kann ein Benutzer eine der beiden Apps von jeder legitimen Quelle beziehen und ist damit fertig. Beim aktuellen Standard-App-Bundle-Modell stimmen die Signaturen der Haupt- und Zusatz-Apps nicht überein. Google wird für jede App einen eindeutigen Schlüssel erstellen. Der Entwickler könnte jederzeit auf die signaturgeschützte Berechtigung verzichten und eine direkte Signatur-Hash-Überprüfung verwenden, aber das ist viel weniger sicher.
Und dann gibt es noch Schnelltests. Benutzer senden Entwicklern ständig E-Mails über Probleme in ihren Apps. Manchmal handelt es sich bei diesen Problemen um einfache Lösungen: Reproduzieren Sie das Problem, finden Sie das Problem, beheben Sie es und laden Sie eine neue Version hoch. Aber manchmal sind sie es nicht. Manchmal können Entwickler ein Problem nicht reproduzieren. Sie können das ihrer Meinung nach bestehende Problem beheben, aber dann muss der Benutzer es testen. Gehen Sie nun davon aus, dass der Benutzer die App über Google Play installiert hat.
Mit dem APK-Modell kann ein Entwickler Code ändern, ein neues APK erstellen und signieren und es zum Testen an den Benutzer senden. Da die Signatur des Test-APK mit der Signatur des vom Benutzer installierten übereinstimmt, ist das Aktualisieren, Testen und Melden ein einfacher Vorgang. Bei App Bundles fällt dies weg. Da Google das APK signiert, das der Nutzer ursprünglich installiert hat, stimmt es nicht mit der Signatur des APK überein, das der Entwickler sendet. Wenn diese App nach Ablauf der App Bundles-Frist veröffentlicht wird, hat der Entwickler nicht einmal Zugriff auf die wichtigsten Google-Anwendungen. Zum Testen müsste der Benutzer die aktuelle App deinstallieren, bevor er die Testversion installiert.
Hier gibt es eine Menge Probleme. Erstens gibt es Unannehmlichkeiten, sowohl auf Entwickler- als auch auf Benutzerseite. Die App deinstallieren zu müssen, nur um einen Fix zu testen, macht keinen Spaß. Und was ist, wenn das Problem verschwindet? Lag es an den Änderungen, die der Entwickler vorgenommen hat, oder lag es daran, dass der Benutzer die Daten der App effektiv gelöscht hat? Der Play Store verfügt zwar über interne Tests, die es Entwicklern ermöglichen sollen, schnelle Builds und Verteilungen durchzuführen, aber dazu muss der Benutzer zuerst die Release-Version deinstallieren. Es repariert eigentlich nichts.
Für den Fall, dass sich das alles nach einer Menge hypothetischem Unsinn anhört, hier ist ein sehr reales Beispiel eines Entwicklers, der diese Probleme haben wird, wenn er Google einen privaten Schlüssel für sich generieren lässt: João Dias. Er ist der Entwickler von Tasker und einer ganzen Reihe von Plugin-Apps, darunter die AutoApps-Suite. Mit der neuen App-Bundles-Anforderung könnte der Entwicklungszyklus von João deutlich schwieriger werden, zumindest für neue Apps. Das direkte Senden von Testversionen ist weniger praktisch. Die Überprüfung von Lizenzen wird weniger effektiv sein.
Das hört sich vielleicht wie ein Randfall an, aber es ist nicht so, dass João irgendein kleiner Entwickler ist, und es ist wahrscheinlich, dass er nicht allein ist. Es gibt viele Apps im Play Store, die auf die Signaturüberprüfung angewiesen sind, um unzulässige Benutzer zu erkennen.
Mit der neuen Option für Entwickler, ihre eigenen Signaturschlüssel auf Google hochzuladen, werden diese Probleme natürlich zumindest etwas gemildert. Entwickler müssen sich jedoch anmelden, um die Option für jede App zu aktivieren. Wenn dies nicht der Fall ist, schlagen die Interconnects fehl und eine schnelle Unterstützung erfordert das Hochladen eines Bundles auf Google und das Warten auf die Generierung von APKs, bevor das richtige Paket an den Benutzer gesendet werden kann. Außerdem bedeutet es immer noch, dass sie ihren privaten Schlüssel teilen müssen, was uns zu den Bedenken zurückbringt, die wir zuvor besprochen haben.
Lösungen
Dies ist ein altes Problem, da die App-Bundle-Anforderungen bereits vor Monaten veröffentlicht wurden und in der Zwischenzeit zahlreiche Lösungsvorschläge gemacht wurden.
Eine Lösung besteht darin, die Notwendigkeit einer Play App-Signierung zu vermeiden. Anstatt ein App Bundle zu generieren, das Google dann in APKs verarbeitet und signiert, könnte diese Verarbeitung durch Android Studio erfolgen. Dann können Entwickler einfach eine ZIP-Datei voller lokal signierter APKs für jede Konfiguration hochladen, die Google generiert hätte.
Mit dieser Lösung bräuchte Google überhaupt keinen Zugriff auf die Schlüssel der Entwickler. Der Prozess wäre dem klassischen APK-Verteilungsmodell sehr ähnlich, würde jedoch mehrere, kleinere APKs statt nur einer umfassen.
Eine andere Lösung besteht darin, die Verwendung von App Bundles einfach nicht zu verlangen und Entwicklern weiterhin das Hochladen lokal signierter APKs zu ermöglichen. Während App Bundles möglicherweise Um in vielen Fällen ein besseres Erlebnis für den Benutzer zu bieten, profitieren einige Apps nicht wirklich von der Aufteilung nach Konfiguration und minimaler Größe die Ermäßigung.
Wenn Google beide Lösungen implementiert, muss ein Entwickler, der App Bundles verwenden möchte, nicht darauf zurückgreifen Über das Signieren bei Google hinaus, und ein Entwickler, dessen App nicht viel von dem Format profitiert, muss es nicht verwenden alle.
Googles Antworten
Selbstsignierung
Als sie zum ersten Mal gefragt wurden, ob sie Entwicklern erlauben würden, die Signatur für App Bundles zu übernehmen, war die Antwort von Google sehr unverbindlich:
[blockquote author=""]Also habe ich kurz über die Anforderung gesprochen, dass neue Apps nächstes Jahr App-Bundles verwenden müssen, und eine Sache, die damit einhergeht, ist, dass wir im weiteren Sinne Play App Signing verlangen werden. Daher müssen Entwickler entweder den App-Signaturschlüssel bei Play generieren oder ihren eigenen Schlüssel bei Play hochladen … denn das ist eine Voraussetzung für App-Bundles. Wir haben von Entwicklern gehört, dass einige von ihnen das einfach nicht tun wollen. Sie möchten nicht, dass die Schlüssel von Play verwaltet werden. Und das ist derzeit nicht möglich, wenn Sie App-Bundles nutzen möchten.
Aber wir haben dieses Feedback gehört und... ich kann im Moment über nichts sprechen, wir haben nichts zu verkünden, aber wir prüfen, wie wir einige dieser Bedenken ausräumen können. Es muss nicht unbedingt erlaubt sein, beim Hochladen von Bundles den eigenen Schlüssel zu behalten. Wir prüfen verschiedene Optionen. Wir haben im Moment einfach keine Lösung, die wir ankündigen können. Aber bis zur Anforderung haben wir noch etwa ein Jahr Zeit, daher bin ich sehr zuversichtlich, dass wir eine Antwort für Entwickler darauf haben werden.[/blockquote]
Das war Ende November letzten Jahres, und es scheint nichts passiert zu sein. Nur noch wenige Monate bis zum Die Anforderung an App-Bundles tritt in Kraftgibt es für Entwickler immer noch keine Möglichkeit, ihre eigenen Apps zu signieren. Während Google es jetzt möglich gemacht hat hochladen Sie können Ihren eigenen Schlüssel sowohl für neue als auch für bestehende Apps verwenden. Dadurch entfällt die Signierungspartie immer noch aus der Hand des Entwicklers.
Codeänderungen
Obwohl Google ausdrücklich versprochen hat, dass der Play Store den App-Code nicht ändern wird, ist ein Versprechen keine Garantie. Bei App Bundles und App Signing gibt es unseres Wissens keine technische Einschränkung, die Google daran hindern würde, hochgeladene Apps vor der Verteilung zu ändern.
Google hat eingeführt Code-Transparenz als optionale Funktion, und obwohl dies einigermaßen hilfreich ist, bringt es, wie wir bereits besprochen haben, einige Probleme mit sich.
Selbstgemachte Bundles
Als Google gefragt wurde, ob es Entwicklern erlaubt sei, ihre eigenen App-„Bundles“ (ZIPs mit geteilten APKs) zu erstellen, lautete die Antwort im Wesentlichen: „Das werden wir nicht tun“:
Wahrscheinlich nicht so, wie es in der Frage beschrieben wird, da dies den Veröffentlichungsprozess für Entwickler noch schwieriger machen würde und wir ihn eigentlich einfacher und sicherer machen wollen. Allerdings haben wir auch dieses Feedback gehört und werden nach Möglichkeiten suchen, dies zu ermöglichen, allerdings wahrscheinlich nicht auf die hier beschriebene Weise.
Interessanterweise scheint die Begründung von Google darin zu bestehen, dass es die Veröffentlichung komplizierter machen würde. Allerdings könnte Google den Prozess im Rahmen des APK-Generierungsdialogs in Android Studio noch automatisieren. Wenn die betreffende App darüber hinaus in mehreren Stores vertrieben wird, würde sie tatsächlich dazu führen Der Veröffentlichungsprozess wird einfacher, da Entwickler nicht mehrere Signaturschlüssel und Beschwerden verwalten müssen Benutzer.
Und mit der Einführung von Code Transparency scheint es, dass Komplikationen doch nicht unbedingt ein Problem darstellen. Code-Transparenz erfordert zumindest vorerst, dass der Entwickler ein Befehlszeilentool verwendet und dass Benutzer die Gültigkeit der ihnen bereitgestellten App explizit überprüfen. Dies ist komplizierter als der Prozess, Pakete selbst zu erstellen, und es ist unklar, warum Google diese Lösung bevorzugt.
Vorwärts gehen
App Bundles sind ab dem 1. August das erforderliche Vertriebsformat für neue Apps, die bei Google Play eingereicht werden. Während Google die meisten von Entwicklern und Sicherheitsexperten angesprochenen Probleme zumindest teilweise angesprochen hat, lassen die Antworten zu wünschen übrig. App Bundles als Vertriebsformat der nächsten Generation bieten viele offensichtliche Vorteile, es wird jedoch immer noch Bedenken geben, die teilweise oder vollständige Kontrolle über die App-Signatur an Google zu übertragen.
Die Antworten und Bemühungen von Google werden sicherlich geschätzt, aber einige, wie Mark Murphy, sind der Meinung, dass sie nicht weit genug gegangen sind. Da Lösungen wie selbst erstellte Bundles nicht implementiert werden und die Frist für Android App Bundles schnell abläuft Wenn es näher rückt, sieht es nicht danach aus, dass Entwickler bei Google Play für lange Zeit die volle Kontrolle über ihre Apps behalten können länger.
Wir werden später am Nachmittag in einem Twitter-Space über die Auswirkungen der Android App Bundle-Anforderung sprechen, also seien Sie dabei!