SDK-Laufzeit

Feedback geben

Die Android-Plattform nutzt das Konzept der Anwendungs-Sandbox, um für Anwendungscode und Prozessgrenzen robuste Ausführungs- und Sicherheitsgrenzen für den Anwendungscode zu wahren. Apps enthalten normalerweise Drittanbietercode, oft in Form von SDKs wie Anzeigen-SDKs oder Analyse-SDKs. Durch diese Wiederverwendung können sich App-Entwickler auf die Differenzierung ihrer App konzentrieren und gleichzeitig die Arbeit von Fachleuten nutzen, um ihre Ausführung über das hinaus zu skalieren, was sie ohne großen Aufwand erledigen könnten.

Wie die meisten Betriebssysteme werden SDKs in Android-SDKs innerhalb der Sandbox der Host-App ausgeführt und übernehmen dieselben Berechtigungen und Berechtigungen der Host-App sowie den Zugriff auf den Arbeitsspeicher und Speicher der Host-App. Diese Architektur ermöglicht zwar eine flexible Integration von SDKs und Anwendungen, bietet aber auch die Möglichkeit, Nutzerdaten offen zu erheben und weiterzugeben. Außerdem sind sich App-Entwickler möglicherweise nicht vollständig über den Umfang der Funktionen eines Drittanbieter-SDKs und die Daten, auf die sie zugreifen, bewusst, was es schwierig macht, die Praktiken der Datenerhebung und -weitergabe ihrer App zu berücksichtigen.

Android 13 hat eine neue Plattformfunktion hinzugefügt, mit der SDKs von Drittanbietern in einer dedizierten Laufzeitumgebung ausgeführt werden können, die als SDK-Laufzeit bezeichnet wird. Die SDK Runtime bietet im Hinblick auf das Erheben und Weitergeben von Nutzerdaten die folgenden stärkeren Sicherheitsmaßnahmen und Sicherstellungen:

  • Eine geänderte Ausführungsumgebung
  • Klar definierte Berechtigungen und Datenzugriffsrechte für SDKs

Zu diesem Design benötigen wir von der Werbe-Community für mobile Apps aktiv Feedback. Wir freuen uns auch über Feedback aus der Entwicklercommunity, das zukünftige Iterationen der SDK Runtime mitgestalten kann, einschließlich des Supports für zusätzliche Anwendungsfälle.

Ziele

Mit diesem Vorschlag sollen die folgenden Ziele erreicht werden:

  • Reduzieren Sie den unbefugten Zugriff auf die App-Daten eines Nutzers und die Weitergabe an diese Daten durch Drittanbieter-SDKs durch Prozessisolation sowie eine klar definierte API- und Datenzugriffssteuerung. Weitere Informationen zur Prozessisolation finden Sie in einem separaten Abschnitt dieses Dokuments.
  • Der Zugriff auf eindeutige, dauerhafte IDs durch SDKs sollte eingeschränkt werden, damit die App-Nutzung eines Nutzers nicht offengelegt wird.
  • Sie können die Bereitstellung von SDK-Updates für Apps sicher beschleunigen, indem Sie App-Entwickler und Endnutzer entlasten. Weitere Informationen zum vorgeschlagenen Trusted SDK-Verteilungsmodell finden Sie in einem weiteren Abschnitt dieses Dokuments.
  • Helfen Sie App-Entwicklern, die Datenzugriffs- und Weitergabepraktiken ihrer App besser zu berücksichtigen.
  • Helfen Sie SDK-Entwicklern, durch die Beschränkung bestimmter unsicherer Sprachkonstrukte wie JNI-Code Manipulationen durch andere SDKs zu verhindern.
  • Durch vollständige Kontrolle über die Remote-Ansichten von Medien helfen Anzeigen-SDKs, ungültige Zugriffe und Anzeigenbetrug zu erkennen und zu verhindern.
  • Minimieren Sie unangemessene Auswirkungen auf App- und SDK-Entwickler so weit wie möglich.

SDKs werden in einem isolierten Prozess ausgeführt

Dank der vorgeschlagenen SDK-Laufzeit können kompatible SDKs – die im restlichen Dokument als laufzeitfähige SDKs bezeichnet werden, in einem separaten Prozess für die App ausgeführt werden. Die Plattform ermöglicht die bidirektionale Kommunikation zwischen dem Prozess der App und ihrer SDK-Laufzeit. Weitere Informationen finden Sie im Abschnitt „Kommunikation“ in diesem Dokument. Nicht-RE SDKs würden wie bisher im App-Prozess bleiben. Diese Änderungen werden in den folgenden Diagrammen veranschaulicht:

Diagramm „Vorher“, das alles zeigt, was den Anwendungsprozess ausführt
Bevor der SDK-Aufrufcode und die SDKs, die Aufrufe von diesem Code empfangen, zur SDK Runtime hinzugefügt werden, befinden sich alle im Prozess der App

Nach dem Diagramm, das die zwischen dem App-Prozess und dem SDK-Laufzeitprozess aufgeteilten Prozesse zeigt
Nachdem der SDK-Aufrufcode im Vordergrundprozess der App in SDK Runtime hinzugefügt wurde, kommuniziert der SDK-Aufrufcode mit den SDK-Schnittstellen. Diese Schnittstellen überschreiten dann eine Prozessgrenze in den SDK-Laufzeitprozess und rufen die SDKs selbst auf.

Neues vertrauenswürdiges Vertriebsmodell für SDKs

Diese vorgeschlagene Trennung des SDK von der App motiviert ein weiteres Trennungskonzept, eines für die SDK- und die App-Bereitstellung. Für unser Angebot ist ein vertrauenswürdiger Vertriebs- und Installationmechanismus erforderlich, mit dem sichergestellt wird, dass die richtigen SDKs in der SDK-Laufzeit einer App installiert werden. So werden Nutzer und App-Entwickler vor dem Laden ungültiger SDKs geschützt. Gleichzeitig können App-Shops den Aufwand für die SDK-Bereitstellung durch App-Entwickler erheblich reduzieren.

SDKs müssten nicht mehr statisch mit ihren Apps verknüpft und zusammengepackt werden, bevor sie zur Bereitstellung in einen App-Shop hochgeladen werden müssen. Stattdessen würde der folgende Prozess ausgeführt:

  1. SDK-Entwickler können ihre versionierten SDKs getrennt von den Apps in die App-Shops hochladen.
  2. App-Entwickler können ihre SDK-Abhängigkeiten nach Version angeben und einen App-Release ohne die tatsächlichen SDK-Abhängigkeiten erstellen und hochladen.
  3. Wenn ein Nutzer diese App herunterlädt, kann der Installationsprozess die angegebenen SDK-Abhängigkeiten verwenden, um sie aus dem App Store herunterzuladen.

Dieser neue Mechanismus für die Bereitstellung würde SDK-Entwicklern ermöglichen, abwärtskompatible Änderungen (d. h. keine Änderungen an APIs oder deren Semantik) an ihren SDKs vorzunehmen und diese auf Geräten ohne Beteiligung der App-Entwickler zu verteilen. Diese abwärtskompatiblen SDK-Änderungen können implementiert oder zurückgesetzt werden, ohne dass App-Entwickler ihre Apps mit den neuen SDKs neu erstellen oder auf die Aktualisierung der Apps durch Endnutzer warten müssen. Nicht funktionsgefährdende Änderungen müssten weiterhin von App-Entwicklern aktualisiert werden, aber SDK-Entwickler könnten ihre neuesten abwärtskompatiblen Änderungen erhalten und Fehler schneller und einheitlicher für mehr Nutzer beheben, idealerweise mit einer geringeren Versionsunterstützung.

In den folgenden Diagrammen werden die vorgeschlagenen Änderungen bei der SDK-Bereitstellung veranschaulicht:

Vorher-Diagramm
Vor der Einführung der SDK-Laufzeit senden Entwickler ihre SDKs direkt an Apps.

Nach Diagramm
Nach Einführung der SDK-Laufzeit d, nutzen SDK-Entwickler eine SDK-Upload-Benutzeroberfläche, um ihre SDKs in einem App-Shop zu veröffentlichen. Der App-Shop übernimmt dann die Bereitstellung der Apps sowie aller SDK-Abhängigkeiten für Endnutzergeräte.

Änderungen bei der Erstellung, Ausführung und Verteilung von SDKs und Apps

Dies ist ein erster Vorschlag für eine flexible Technologie für die SDK-Laufzeit und -verteilung. In den folgenden Abschnitten werden eine Reihe von Änderungen für die folgenden allgemeinen Kategorien vorgeschlagen:

  • Zugriff: Berechtigungen, Arbeitsspeicher, Speicher
  • Ausführung: Sprachen, Laufzeitänderungen, Lebenszyklus, Medienrendering
  • Kommunikation: App-zu-SDK und SDK-zu-SDK
  • Entwicklung: Anleitung zum Erstellen, Debuggen und Testen in diesem Modell
  • Verteilung: Verteilung, Aktualisierung und Rollback von Android-Versionen, Apps und SDKs.

Dieses Dokument enthält auch FAQs mit Antworten auf häufig gestellte Fragen.

Dies ist ein erster Designvorschlag und wir sind uns bewusst, dass diese Änderung für einige Mitglieder des Ökosystems von großer Bedeutung sein kann. Deshalb bitten wir Sie um Feedback. Nutzen Sie dazu die Problemverfolgung.

Zugriff

Das Verwalten des Datenschutzes eines Systems beinhaltet die Verwaltung des Zugriffs verschiedener Parteien auf verschiedene Ressourcen. Um unser Nutzenversprechen für den Datenschutz zu erfüllen, schlagen wir vor, das Modell für den Zugriff auf Apps, SDKs und Nutzerdaten gemäß dem Prinzip der geringsten Berechtigung zu aktualisieren, um den nicht offengelegten Zugriff auf potenziell sensible Daten zu verhindern.

SDK-Berechtigungen

Als separater Prozess verfügt die SDK-Laufzeit über eigene, genau definierte Berechtigungen, anstatt diejenigen zu übernehmen, die der Nutzer der App gewährt hat. Auf Grundlage von Vorabuntersuchungen zu den Berechtigungen, die von anzeigenbezogenen SDKs verwendet werden, schlagen wir vor, dass die folgenden Berechtigungen für SDKs in der SDK-Laufzeit standardmäßig zugänglich sind:

  • INTERNET: Zugriff auf das Internet, um mit einem Webdienst zu kommunizieren.
  • ACCESS_NETWORK_STATE: Bietet Zugriff auf Informationen zu Netzwerken.
  • Berechtigungen für den Zugriff auf die datenschutzfreundlichen APIs, die wichtige Werbefunktionen ohne Zugriff auf appübergreifende Kennungen bieten
  • AD_ID: Die Werbe-ID kann angefordert werden. Dies wird auch durch den Zugriff der App auf diese Berechtigung eingeschränkt.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Möglichkeit, die Google Play Install Referrer API zu verwenden, um die Quelle der App-Installation zuzuordnen.

Wir prüfen derzeit, ob und wie zusätzliche Berechtigungen autorisiert werden können, um die Auswirkungen auf Endnutzer sowohl aus Datenschutz- als auch aus Sicht der Nutzerfreundlichkeit zu begrenzen. Wir bitten Sie um Feedback zu allen Anwendungsfällen, die von diesen Berechtigungen nicht abgedeckt werden.

Arbeitsspeicher

Die SDK-Laufzeit hätte aufgrund eines eigenen Prozesses einen eigenen isolierten Arbeitsspeicherbereich. Mit dieser Struktur wird dem SDK-Zugriff auf den Arbeitsspeicher der App standardmäßig verweigert. Ebenso kann die App nicht auf den SDK-Arbeitsspeicher zugreifen. Wir schlagen vor, dieses Standardverhalten beizubehalten, um dem Prinzip der geringsten Berechtigung zu entsprechen.

Speicher

Mit diesem Vorschlag soll die Notwendigkeit von SDKs, für den normalen Betrieb auf den Speicher zuzugreifen, ausgewogen werden. Außerdem soll das app- und prozessübergreifende Tracking mithilfe des nichtflüchtigen Speichers minimiert werden. Wir schlagen heute das folgende Update für den Zugriff auf den Speicher vor:

  • Eine App kann nicht direkt auf ihren SDK-Speicher zugreifen und umgekehrt.
  • SDKs können nicht auf den externen Speicher des Geräts zugreifen.
  • Innerhalb jeder SDK-Laufzeit ist sowohl Speicher für alle SDKs als auch privater Speicher für ein bestimmtes SDK verfügbar.

Wie beim aktuellen Speichermodell hat auch der Speicher selbst keine willkürlichen Größenbeschränkungen. SDKs können Speicherplatz zum Caching von Assets verwenden. Dieser Speicher wird regelmäßig gelöscht, wenn das SDK nicht aktiv ausgeführt wird.

Umsetzung

Damit ein privates System zwischen Anwendungen, SDKs und Nutzern geschützt ist, muss der Ausführungskontext selbst (Codeformate, Sprachkonstrukte, zugängliche APIs und Systemdaten) diese Datenschutzgrenzen verstärken oder zumindest keine Möglichkeiten zu ihrer Umgehung bieten. Gleichzeitig möchten wir den Zugriff auf die umfangreiche Plattform und die meisten Laufzeitfunktionen von SDKs beibehalten. Hier schlagen wir eine Reihe von Updates für die Laufzeitumgebung vor, um dieses Gleichgewicht zu erreichen.

Code

Android-Code (Apps und SDKs) wird in erster Linie von Android Runtime (ART) interpretiert, unabhängig davon, ob der Code in Kotlin oder Java geschrieben wurde. Der Umfang von ART und die darin enthaltenen Sprachkonstrukte, zusammen mit der Überprüfbarkeit, die er im Vergleich zu Alternativen – insbesondere nativem Code – bietet, scheinen Funktionalität und Datenschutz angemessen abzuwägen. Wir schlagen vor, dass laufzeitfähiger SDK-Code ausschließlich aus Dex-Bytecode besteht und nicht den JNI-Zugriff unterstützt.

Uns ist bewusst, dass es Anwendungsfälle wie die Verwendung eines benutzerdefinierten SQLite-Pakets gibt, das aufgrund der Verwendung von nativem Code durch eine Alternative ersetzt werden muss, z. B. die im Android SDK integrierte SQLite-Version.

SELinux

Unter Android wird jeder Prozess (einschließlich der Prozesse, die als Root ausgeführt werden) mit einem bestimmten SELinux-Kontext ausgeführt. Dadurch kann der Kernel die Zugriffssteuerung auf Systemdienste, Dateien, Geräte und andere Prozesse verwalten. Damit die meisten SDK-Anwendungsfälle erhalten bleiben und gleichzeitig die Umgehung des Datenschutzes möglichst gering gehalten werden kann, schlagen wir folgende Aktualisierungen aus dem SELinux-Kontext einer nicht systemeigenen App für die SDK-Laufzeit vor:

  • Es wäre eine begrenzte Anzahl von Systemdiensten zugänglich. (unter Active Design)
  • SDKs können den Code nur in ihrem APK laden und ausführen.
  • Es wäre eine begrenzte Anzahl von Systemeigenschaften zugänglich. (unter Active Design)

APIs

Die Verwendung von Reflexion- und Aufruf-APIs innerhalb der SDK-Laufzeit ist zulässig. Ein SDK darf jedoch keine Reflexion verwenden oder APIs in einem anderen laufzeitfähigen SDK aufrufen. In einem zukünftigen Update veröffentlichen wir einen vollständigen Vorschlag für unzulässige APIs.

Darüber hinaus wurde in den aktuellen Releases der Android-Plattform der Zugriff auf persistente Kennungen zunehmend eingeschränkt, um den Datenschutz zu verbessern. Für die SDK-Laufzeit schlagen wir eine weitere Einschränkung des Zugriffs auf Kennungen vor, die für appübergreifendes Tracking verwendet werden können.

SDK Runtime APIs sind nur über Apps zugänglich, die im Vordergrund ausgeführt werden. Wenn Sie versuchen, über Apps im Hintergrund auf SdkSandboxManager APIs zuzugreifen, wird SecurityException ausgegeben.

Außerdem können RE-SDKs zu keinem Zeitpunkt Nutzerbenachrichtigungen über die Notifications APIs senden.

Lifecycle

App-SDKs folgen derzeit dem Lebenszyklus ihrer Host-App. Das bedeutet auch, dass die SDKs der App den Vordergrund betreten oder verlassen, heruntergefahren oder durch das Betriebssystem aufgrund von Speicherauslastung beendet werden. Unser Vorschlag, die SDKs einer Anwendung in einen anderen Prozess aufzuteilen, beinhaltet die folgenden Änderungen im Lebenszyklus:

  • Die App kann vom Nutzer oder vom Betriebssystem beendet werden. Die SDK-Laufzeit wird unmittelbar danach automatisch beendet.
  • Die SDK-Laufzeit kann beispielsweise aufgrund von Speicherauslastung oder einer unbehandelten Ausnahme in einem SDK vom Betriebssystem beendet werden.

    Wenn bei Android 13 eine App im Vordergrund ausgeführt wird, hat die SDK-Laufzeit eine hohe Priorität und wird wahrscheinlich nicht beendet. Wenn die App in den Hintergrund versetzt wird, verringert sich die Priorität des SDK-Laufzeitprozesses und die App kann beendet werden. Die Priorität des SDK-Laufzeitprozesses bleibt niedrig, auch wenn die App wieder in den Vordergrund wechselt. Daher ist es im Vergleich zur Anwendung sehr wahrscheinlich, dass sie unter Speicherauslastung beendet wird.

    Bei Android 14 und höher sind die Prozessprioritäten der App und der SDK-Laufzeit aufeinander abgestimmt. Die Prozessprioritäten für ActivityManager.RunningAppProcessInfo.importance für die Anwendung und die SDK-Laufzeit sollten ungefähr gleich sein.

    Wenn die SDK-Laufzeit beendet wird, während die App aktiv ist, z. B. wenn im SDK eine unbehandelte Ausnahme vorliegt, geht der SDK-Laufzeitstatus einschließlich aller zuvor geladenen SDKs und Remote-Ansichten verloren. Der App-Entwickler kann die Beendigung der SDK-Laufzeit mithilfe einer der folgenden Methoden handhaben:

    • Der Vorschlag bietet App-Entwicklern zugehörige Lebenszyklus-Callback-Methoden, mit denen sie erkennen können, wann die SDK-Laufzeit beendet wurde.
    • Wenn die SDK-Laufzeit beendet wird, während Anzeigen ausgeliefert werden, funktionieren Anzeigen möglicherweise nicht wie erwartet. Beispielsweise können Ansichten auf dem Bildschirm eingefroren und nicht mehr interaktiv sein. In der App kann der Anzeigenaufruf entfernt werden, wenn sich dies nicht auf die Nutzererfahrung auswirkt.
    • Die App kann versuchen, SDKs zu laden und Anzeigen anzufordern.
    • Wenn unter Android 14 die SDK-Laufzeit beendet wird, während SDKs geladen sind, und der App-Entwickler die oben genannten Lebenszyklus-Callback-Methoden nicht registriert hat, wird die App standardmäßig beendet. Nur die App-Prozesse mit geladenen SDKs werden normal beendet und beendet.
    • Binder-Objekte, die vom SDK zur Kommunikation zurückgegeben werden (z. B. SandboxedSdk), geben ein DeadObjectException aus, wenn sie von der App verwendet werden.

    Dieses Lebenszyklusmodell kann sich in zukünftigen Updates ändern.

    Bei anhaltenden Fehlern sollte der App-Entwickler eine ordnungsgemäße Herabstufung ohne das SDK einplanen oder den Nutzer benachrichtigen, wenn das SDK für die Hauptfunktion der App entscheidend ist. Weitere Informationen zu dieser Interaktion zwischen App und SDK finden Sie im Abschnitt „Kommunikation“ in diesem Dokument.

Nicht-RE-SDKs können weiterhin Standard-Betriebssystem-Primitive verwenden, die für ihre eingebettete App verfügbar sind, einschließlich Diensten, Aktivitäten und Broadcasts. RE SDKs können dies jedoch nicht.

Sonderfälle

Die folgenden Fälle werden nicht unterstützt und können zu unerwartetem Verhalten führen:

  • Wenn mehrere Anwendungen dieselbe UID haben, funktioniert die SDK-Laufzeit möglicherweise nicht ordnungsgemäß. Die Unterstützung für gemeinsame UIDs wird möglicherweise in Zukunft hinzugefügt.
  • Bei Anwendungen mit mehreren Prozessen sollte das Laden des SDK im Hauptprozess erfolgen.

Medien-Rendering

Es gibt SDKs, die Inhalte wie Text, Bilder und Videos in einer für die App angegebenen Ansicht rendern. Dazu schlagen wir einen Remote-Rendering-Ansatz vor, bei dem das SDK die Medien innerhalb der SDK-Laufzeit rendert, aber die SurfaceControlViewHost API verwendet, damit die Medien in einer von der App angegebenen Ansicht gerendert werden können. Dadurch kann das SDK diese Medien auf eine private Weise für den Nutzer rendern und gleichzeitig ungültige oder betrügerische Nutzerinteraktionen mit den gerenderten Medien verhindern und erkennen.

Native Anzeigen, also Anzeigen, die nicht vom SDK, sondern von der App gerendert werden, werden von SDKs in der SDK-Laufzeit unterstützt. Die Signalerfassung und der Creative-Abruf würden bei nicht nativen Anzeigen konsistent ausgeführt. Dies ist ein aktives Untersuchungsgebiet.

In-Stream-Videoanzeigen werden mit einem Video ausgeliefert und in einem Player innerhalb einer App wiedergegeben. Da das Video in einem Player in der App und nicht in einem Player oder einer Ansicht im SDK wiedergegeben wird, unterscheidet sich das Renderingmodell von anderen Anzeigenformaten. Wir prüfen derzeit Mechanismen zur Unterstützung sowohl der serverseitigen als auch der SDK-basierten Anzeigenbereitstellung.

Systemzustand

Wir versuchen, die Auswirkungen der SDK-Laufzeit auf Endnutzergeräte so gering wie möglich zu halten, und entwickeln entsprechende Möglichkeiten. Höchstwahrscheinlich unterstützen einige Android 13-Einstiegsgeräte mit sehr begrenzten Systemressourcen, wie Android (Go-Edition), die SDK-Laufzeit aufgrund der Auswirkungen auf den Systemzustand nicht. Bald teilen wir Ihnen die Mindestanforderungen für die erfolgreiche Nutzung der SDK-Laufzeit mit.

Kommunikation

Da Anwendungen und SDKs derzeit im selben Prozess ausgeführt werden, ist die Kommunikation zwischen ihnen nicht eingeschränkt und sofort möglich. Außerdem ermöglicht Android die Kommunikation zwischen Apps, selbst wenn die Kommunikation mit SDKs beginnt und endet. Dieses fließende Kommunikationsmodell ermöglicht verschiedene Anwendungsfälle und bietet gleichzeitig die Möglichkeit eines nicht offengelegten Datenaustauschs zwischen Anwendungen und zwischen SDKs innerhalb und zwischen Anwendungen. Wir schlagen die folgenden Aktualisierungen dieses Kommunikationsmodells vor, um ein Gleichgewicht zwischen dem Wert einer solchen Kommunikation und der Realisierung unserer Ziele zu finden.

App-zu-SDK

Die Schnittstelle zwischen der App und dem SDK ist der häufigste Kommunikationspfad zu einem SDK. Ein Großteil der nutzerseitigen Unterscheidung und Innovation liegt in der API eines SDKs. Wir möchten die Innovationsfähigkeit und Differenzierung von SDKs aufrechterhalten. Daher können SDKs mit unserem Angebot APIs für Anwendungen freigeben und so dafür sorgen, dass Anwendungen von all diesen Innovationen profitieren können.

Angesichts der Prozessgrenzenstruktur der SDK-Laufzeit schlagen wir vor, eine Marshalling-Ebene zu erstellen, auf die innerhalb der Anwendung zugegriffen werden kann, um die API-Aufrufe und -Antworten oder -Callbacks über diese Grenze zwischen der App und dem SDK zu übertragen. Wir schlagen vor, dass die Schnittstelle zu dieser Marshaling-Ebene von SDK-Entwicklern definiert und von offiziellen Open-Source-Build-Tools generiert wird, die wir entwickeln würden.

Mit diesem Vorschlag möchten wir das Boilerplate-Marshaling-Verfahren von App- und SDK-Entwicklern eliminieren, SDK-Entwicklern gleichzeitig Flexibilität bieten und dafür sorgen, dass SDK-Code in der SDK-Laufzeit ausgeführt wird, um unsere Datenschutzziele zu erreichen. Wenn wir diesen Weg gehen, müssen die API-Definitionssprache und -Tools mit Ihrer Eingabe entwickelt werden.

Das allgemeine Interaktionsmodell sieht so aus:

  • Die App ruft das SDK über die Schnittstelle auf und übergibt Callbacks.
  • Das SDK erfüllt die Anfragen asynchron und antwortet mithilfe der Callbacks.
  • Dies kann für jedes Publisher-Abonnenten-Modell verallgemeinert werden. Das bedeutet, dass eine App Ereignisse im SDK mit Callbacks abonnieren kann. Wenn diese Ereignisse eintreten, werden die Callbacks ausgelöst.

Die neue prozessübergreifende Struktur dieses Angebots besteht darin, dass zwei Prozesslebenszyklen verwaltet werden müssen: eine für die Anwendung selbst und eine für die SDK-Laufzeit. Mit unserem Vorschlag soll dieser Vorgang möglichst automatisiert werden, sodass die Auswirkungen für App- und SDK-Entwickler minimiert werden. Das folgende Diagramm zeigt einen Ansatz, den wir in Betracht ziehen:

Diagramm
Sequenzdiagramm, das die App-zu-SDK-Interaktionen beim Start der App und des SDK zeigt.

Über die Plattform werden neue APIs für Anwendungen bereitgestellt, um SDKs dynamisch in den SDK-Laufzeitprozess zu laden, über Änderungen am Prozessstatus informiert zu werden und mit SDKs zu interagieren, die in die SDK-Laufzeit geladen werden.

Das Diagramm in der vorherigen Abbildung zeigt die App-zu-SDK-Kommunikation auf einer niedrigeren Ebene ohne die Marshalling-Ebene.

Die App kommuniziert über die folgenden Schritte mit dem SDK, das während des SDK-Laufzeitprozesses ausgeführt wird:

  1. Bevor eine App mit einem SDK interagieren kann, fordert die App das Laden des SDK von der Plattform an. Um die Integrität des Systems zu gewährleisten, geben Apps in ihrer Manifestdatei die SDKs an, die sie laden möchten. Es dürfen dann nur diese SDKs geladen werden.

    Das folgende Code-Snippet zeigt ein API-Beispiel:

    SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
        OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
    
  2. Das SDK wird benachrichtigt, dass es geladen wurde, und gibt seine Schnittstelle zurück. Diese Schnittstelle ist für die Verwendung im App-Prozess vorgesehen. Wenn die Schnittstelle außerhalb der Prozessgrenze geteilt werden soll, muss sie als IBinder-Objekt zurückgegeben werden.

    Im Leitfaden für gebundene Dienste werden verschiedene Möglichkeiten zur Bereitstellung von IBinder beschrieben. In beiden Fällen muss das SDK und die aufrufende App einheitlich sein. In den Diagrammen wird als Beispiel AIDL verwendet.

  3. Der SdkSandboxManager empfängt die IBinder-Schnittstelle und gibt sie an die Anwendung zurück.

  4. Die App ruft die IBinder ab, wandelt sie in die SDK-Schnittstelle um und ruft ihre Funktionen auf:

    IBinder binder = sandboxSdk.getInterface();
    ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
    mySdkInterface.something();
    

Mit der App können auch Medien vom SDK gerendert werden. Gehen Sie dazu so vor:

  1. Wie im Abschnitt zum Medien-Rendering dieses Dokuments erläutert, könnte die App einen Aufruf an requestSurfacePackage() senden und die entsprechende SurfaceControlViewHost.SurfacePackage abrufen, damit eine App ein SDK zum Rendern von Medien in einer Ansicht erhält.

    Das folgende Code-Snippet zeigt ein API-Beispiel:

    SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
            Executor executor,
            OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
    
  2. Die Anwendung könnte dann das zurückgegebene SurfacePackage über die setChildSurfacePackage API in SurfaceView in SurfaceView einbetten.

    Das folgende Code-Snippet zeigt ein API-Beispiel:

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
    

Unser Vorschlag ist, die APIs IBinder und requestSurfacePackage() allgemein zu halten und nicht für den direkten Aufruf durch die Apps gedacht. Stattdessen werden diese APIs von der oben beschriebenen generierten API-Referenz in einer "Shim"-Ebene aufgerufen, um die Belastung für App-Entwickler zu verringern.

SDK zu SDK

Zwei SDKs in derselben App müssen häufig miteinander kommunizieren. Dies kann passieren, wenn ein bestimmtes SDK aus einzelnen SDKs besteht oder wenn zwei SDKs verschiedener Parteien zusammenarbeiten müssen, um eine Anfrage der aufrufenden App zu bearbeiten.

Es gibt zwei wichtige Fälle zu berücksichtigen:

  • Wenn beide SDKs laufzeitfähig sind. In diesem Fall werden beide SDKs mit allen Schutzmaßnahmen in der SDK-Laufzeit ausgeführt. SDKs können nicht mehr so wie aktuell innerhalb einer App kommunizieren. Daher wurde in SdkSandboxController eine API hinzugefügt, mit der SandboxedSdk-Objekte für alle geladenen RE-SDKs abgerufen werden können. Dadurch kann ein RE-SDK mit anderen SDKs kommunizieren, die in der SDK-Laufzeit geladen werden.
  • Wenn nur ein SDK laufzeitfähig ist
    • Wenn das aufrufende SDK in der App ausgeführt wird, funktioniert dies genauso wie die App selbst, die innerhalb der SDK-Laufzeit das zweite SDK aufruft.
    • Wenn das aufrufende SDK innerhalb der SDK-Laufzeit ausgeführt wird, empfiehlt dieser Vorschlag, eine Methode mit dem IBinder verfügbar zu machen, der im Abschnitt zur Übertragung von SDKs für die App beschrieben ist. Der Code in der App wartet auf sie, verarbeitet sie und antwortet mit den bereitgestellten Callbacks.
    • Anzeigen-SDKs, die nicht laufzeitfähig sind, können sich möglicherweise nicht selbst registrieren. Wir schlagen die Erstellung eines Mediator-SDKs vor, das Partner- oder App-SDKs als direkte Abhängigkeiten von der App enthält und die Registrierung abwickelt. Dieses Mediator SDK stellt die Kommunikation zwischen nicht laufzeitfähigen SDKs oder anderen Anwendungsabhängigkeiten und dem laufzeitfähigen Vermittler her, der als Adapter fungiert.

Die Funktionen für die SDK-SDK-Kommunikation wurden in die folgenden Kategorien unterteilt:

  • SDK-SDK-Kommunikation innerhalb der SDK-Laufzeit (verfügbar in der neuesten Entwicklervorschau)
  • SDK-SDK-Kommunikation zwischen einer App und der SDK-Laufzeit (verfügbar in der neuesten Entwicklervorschau)
  • Funktionsweise von Ansichten und Remote-Rendering für die Vermittlung (Vorschlag in der Entwicklung)

Beim Entwerfen der Primitiven werden die folgenden Anwendungsfälle in Betracht gezogen:

  1. Vermittlung und Gebote: Viele Werbe-SDKs bieten eine Vermittlungs- oder Gebotsfunktion, mit der das SDK verschiedene andere SDKs für eine Anzeigenimpression (Vermittlung) oder zum Erfassen von Signalen für eine Auktion (Gebote) aufruft. In der Regel ruft das koordinierende SDK andere SDKs über einen vom koordinierenden SDK bereitgestellten Adapter auf. Angesichts der obigen Primitive sollte das koordinierende SDK, ob RE oder nicht, für den normalen Betrieb auf alle RE- und Nicht-RE SDKs zugreifen können. Das Rendering ist in diesem Zusammenhang ein aktives Untersuchungsgebiet.
  2. Erkennung von Funktionen: Einige SDK-Produkte bestehen aus kleineren SDKs, die über einen Erkennungsprozess zwischen SDKs bestimmen, welcher Funktionssatz dem App-Entwickler letztendlich zur Verfügung gestellt wird. Die Registrierungs- und Erkennungsprimitive sollten diesen Anwendungsfall ermöglichen.
  3. Publisher-Abomodelle: Einige SDKs sind so konzipiert, dass sie einen zentralen Publisher von Ereignissen haben, die andere SDKs oder Apps abonnieren können, um Benachrichtigungen über Callbacks zu erhalten. Die oben genannten Primitive sollten diesen Anwendungsfall unterstützen.

App-zu-App

Bei der App-zu-App-Kommunikation ist mindestens einer der beiden Prozesse, die kommunizieren, ein laufzeitfähiges SDK und ein möglicher Vektor für die nicht offengelegte Datenfreigabe. Daher kann die SDK-Laufzeit keinen direkten Kommunikationskanal zu anderen Anwendungen als der Clientanwendung oder mit SDKs in einer anderen SDK-Laufzeit einrichten, die für eine andere Anwendung erstellt wurde. Dies wird auf folgende Weise erreicht:

  • Das SDK kann keine Komponenten wie <service>, <contentprovider> oder <activity> in seinem Manifest definieren.
  • Mit dem SDK kann kein ContentProvider veröffentlicht oder kein Broadcast gesendet werden.
  • Das SDK kann eine Aktivität starten, die zu einer anderen App gehört, jedoch mit Einschränkungen dafür, was im Intent gesendet werden kann. Diesem Intent können beispielsweise keine Extras oder benutzerdefinierten Aktionen hinzugefügt werden.
  • Das SDK kann nur Dienste starten oder an eine Zulassungsliste von Diensten binden.
  • Das SDK kann nur auf einen Teil der System-ContentProvider (z. B. com.android.providers.settings.SettingsProvider) zugreifen, wenn die abgerufenen Daten keine Kennungen haben und nicht zum Erstellen eines Fingerabdrucks des Nutzers verwendet werden können. Diese Prüfungen gelten auch für den Zugriff auf ContentProvider mit ContentResolver.
  • Das SDK kann nur auf einen Teil der geschützten Übertragungsempfänger zugreifen (z. B. android.intent.action.AIRPLANE_MODE).

Manifest-Tags

Wenn das SDK installiert ist, parst PackageManager das Manifest des SDK und kann das SDK nicht installieren, wenn gesperrte Manifest-Tags vorhanden sind. Das SDK definiert beispielsweise keine Komponenten wie <service>, <activity>, <provider> oder <receiver> und darf im Manifest keinen <permission> deklarieren. Tags, deren Installation fehlschlägt, werden in der SDK-Laufzeit nicht unterstützt. Tags, bei denen die Installation nicht fehlschlägt, aber im Hintergrund ignoriert werden, werden möglicherweise in zukünftigen Android-Versionen unterstützt.

Diese Prüfungen können auch von jedem Build-Zeit-Tool durchgeführt werden, das das SDK zum Erstellen des SDK-Bundles und beim Hochladen in den App-Shop verwendet.

Unterstützung bei Aktivitäten

SDKs in der SDK-Laufzeitumgebung können ihrer Manifestdatei kein Aktivitäts-Tag hinzufügen und keine eigenen Aktivitäten mit Context.startActivity starten. Stattdessen erstellt die Plattform auf Anfrage die Aktivitäten für die SDKs und gibt sie an SDKs weiter.

Die Plattformaktivität hat den Typ android.app.Activity. Die Plattformaktivität beginnt mit einer der Aktivitäten der App und ist Teil der App-Aufgabe. FLAG_ACTIVITY_NEW_TASK wird nicht unterstützt.

Damit ein SDK eine Aktivität starten kann, sollte es eine Instanz vom Typ SdkSandboxActivityHandler registrieren. Diese wird verwendet, um über die Aktivitätserstellung informiert zu werden, wenn die App SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) zum Starten der Aktivität aufruft.

Der Ablauf für die Anforderung einer Aktivität ist in der folgenden Grafik dargestellt.

Diagramm
Sequenzdiagramm, das den Ablauf zum Starten einer Aktivität zeigt.

Entwicklung

Ein Hauptprinzip dieses Vorschlags besteht darin, die Auswirkungen auf die Entwicklerumgebung so weit wie möglich zu minimieren. Dieser Vorschlag bietet Entwicklern eine umfassende Reihe von Entwicklungstools zum Schreiben, Erstellen und Debuggen von RE-Anwendungen und SDKs. Um die Integrität dieses Vorschlags zu gewährleisten, gibt es einige Änderungen an der Konfiguration, Erstellung und Erstellung von RE-Apps und SDKs.

In der Erstellung

Android Studio und die zugehörigen Tools werden aktualisiert, sodass sie SDK laufzeitabhängig sind. So können Entwickler ihre RE-Apps und SDKs richtig konfigurieren und alte oder nicht unterstützte Aufrufe werden gegebenenfalls mit den neueren Alternativen aktualisiert. In der Erstellungsphase gibt es einige Schritte, die Entwickler für unseren Vorschlag ausführen müssen.

App-Entwickler*innen

Apps müssen ihre RE SDK- und SDK-Zertifikatabhängigkeiten im App-Manifest angeben. In unserem Vorschlag betrachten wir dies als zentrale Datenquelle des Anwendungsentwicklers. Beispiel:

  • Name:Paketname des SDKs oder der Bibliothek.
  • Hauptversion:Code der Hauptversion des SDKs.
  • Zertifikat-Digest:Der Zertifikat-Digest des SDK-Builds. Für einen bestimmten Build empfehlen wir dem SDK-Entwickler, diesen Wert im entsprechenden App-Shop abzurufen und zu registrieren.

Dies gilt nur für im App-Shop vertriebene SDKs, unabhängig davon, ob es sich um RE handelt oder nicht. Bei Apps, die statisch verknüpfte SDKs verwenden, werden die aktuellen Abhängigkeitsmechanismen verwendet.

Da die Auswirkungen für Entwickler so gering wie möglich sind, ist es wichtig, dass App-Entwickler nach Angabe eines Ziel-API-Levels, das die SDK-Laufzeit unterstützt, immer nur einen einzelnen Build benötigen, unabhängig davon, ob dieser Build auf Geräten ausgeführt wird, die die SDK-Laufzeit unterstützen oder nicht.

SDK-Entwickler

In unserem vorgeschlagenen Design müssen RE SDK-Entwickler explizit ein neues Element deklarieren, das das SDK oder die Bibliotheksentität im Manifest darstellt. Darüber hinaus muss ein ähnlicher Satz von Werten wie die Abhängigkeit sowie eine Nebenversion angegeben werden:

  • Name:Paketname des SDKs oder der Bibliothek.
  • Hauptversion:Code der Hauptversion des SDKs.
  • Nebenversion:Code der Nebenversion des SDKs.

Wenn RE SDK-Entwickler andere RE SDKs als Abhängigkeiten bei der Erstellung haben, müssen sie diese wahrscheinlich auf dieselbe Weise deklarieren, wie ein App-Entwickler diese Abhängigkeit deklarieren würde. RE SDKs, die von Nicht-RE SDKs abhängig sind, verlinken sie statisch. Dies kann zu Problemen führen, die beim Build oder bei Testdurchläufen erkannt werden, wenn die Nicht-RE SDKs Funktionen erfordern, die von der SDK-Laufzeit nicht unterstützt werden, oder wenn sie im Prozess der App ausgeführt werden müssen.

Entwickler von RE SDKs werden wahrscheinlich weiterhin Unterstützung für nicht RE-fähige Geräte wie Android 12 oder niedriger und, wie im Abschnitt „Systemzustand“ des Dokuments erwähnt, für Android 13-Einstiegsgeräte mit sehr begrenzten Systemressourcen wünschen. Wir arbeiten an Ansätzen, damit SDK-Entwickler eine einzige Codebasis behalten können, um RE- und Nicht-RE-Umgebungen zu unterstützen.

Builds

App-Entwickler*innen

Wir gehen davon aus, dass App-Entwickler wenige Änderungen im Build-Schritt feststellen werden. SDK-Abhängigkeiten müssen für Linting, Kompilierung und Builds auf dem Computer vorhanden sein, egal ob lokal verteilt oder im App-Shop verteilt (RE oder nicht). Wir schlagen vor, dass Android Studio diese Details bei normaler Verwendung vom App-Entwickler abstrahiert und sie so transparent wie möglich macht.

Obwohl wir erwarten, dass ein FEHLERBEHEBUNGS-Build den gesamten Code und die Symbole enthalten müsste, die im FEHLERBEHEBUNGS-Build vorhanden sind, um Fehler zu beheben, würden bei RELEASE-Builds optional alle im App-Shop vertriebenen SDKs (RE oder nicht) aus dem endgültigen Artefakt entfernt werden.

Wir befinden uns hier bereits in der Designphase und werden Ihnen demnächst weitere Informationen geben.

SDK-Entwickler

Wir arbeiten an einem Pfad, um sicherzustellen, dass Nicht-RE- und RE-Versionen eines SDK zur Verteilung in ein einzelnes Artefakt integriert werden können. Dadurch wird verhindert, dass App-Entwickler separate Builds für RE- und Nicht-RE-Versionen eines SDKs unterstützen müssen.

Ähnlich wie bei Apps müssen für App-Shops verteilte Abhängigkeits-SDKs für Linting, Kompilierung und Builds auf dem Computer vorhanden sein. Android Studio sollte dies nahtlos ermöglichen.

Testen

App-Entwickler*innen

Wie in unserem Vorschlag beschrieben, können App-Entwickler ihre Apps auf Geräten mit Android 13 wie gewohnt testen. Nachdem die App erstellt wurde, kann sie auf einem RE-Gerät oder Emulator installiert werden. Dadurch wird sichergestellt, dass die richtigen SDKs in der SDK-Laufzeit für das Gerät oder den Emulator installiert werden, unabhängig davon, ob die SDKs aus einem Remote SDK-Repository oder aus dem Cache des Build-Systems abgerufen wurden.

SDK-Entwickler

SDK-Entwickler verwenden in der Regel interne Test-Apps auf Geräten und Emulatoren, um ihre Entwicklung zu testen. In unserem Vorschlag ändert sich das nichts. Die In-App-Validierung würde dieselben Schritte wie oben für App-Entwickler ausführen, mit einem einzelnen Build-Artefakt für RE- und Nicht-RE-Anwendungen. SDK-Entwickler können ihren Code durchgehen, unabhängig davon, ob er sich in der SDK-Laufzeit befindet oder nicht. Allerdings gibt es möglicherweise Einschränkungen bei erweiterten Tools zur Fehlerbehebung und Profilerstellung. Dies ist ein aktives Untersuchungsgebiet.

Verbreitung

Unser Designvorschlag zur Trennung einer App von ihren SDKs hat die Möglichkeit geschaffen, SDKs über den App-Shop zu vertreiben. Das ist eine allgemeine Möglichkeit, sie ist nicht spezifisch für einen bestimmten App-Shop. Die Vorteile liegen auf der Hand:

  • Qualität und Konsistenz der SDKs gewährleisten
  • Optimierung der Veröffentlichung für SDK-Entwickler
  • Beschleunigte Einführung von Updates von SDK-Nebenversionen für installierte Apps

Zur Unterstützung der SDK-Bereitstellung muss ein App-Shop wahrscheinlich die meisten der folgenden Funktionen bereitstellen:

  • Ein Verfahren für SDK-Entwickler, mit dem sie ihre über den App-Shop verteilbaren SDKs in den Store hochladen, sie aktualisieren, Rollbacks durchführen und möglicherweise entfernen können.
  • Ein Mechanismus, um die Integrität eines SDKs und seiner Herkunft sowie einer App und ihrer Herkunft zu gewährleisten und deren Abhängigkeiten aufzulösen.
  • Einen Mechanismus, um sie auf zuverlässige und leistungsstarke Weise auf Geräten bereitzustellen

Neue Einschränkungen im Laufe der Zeit

Wir gehen davon aus, dass sich die Einschränkungen, denen der Code in der SDK-Laufzeit unterliegt, mit neueren Android-Versionen weiterentwickeln. Zur Gewährleistung der Anwendungskompatibilität ändern wir diese Einschränkungen nicht mit Mainline-Modulupdates für ein bestimmtes SDK-Level. Das mit einer bestimmten targetSdkVersion verknüpfte Verhalten bleibt erhalten, bis die Unterstützung für diese targetSdkVersion durch die App Store-Richtlinie eingestellt wird. Die Einstellung von targetSdkVersion kann dann schneller als bei Anwendungen erfolgen. Die Einschränkungen werden sich in den Android SDK-Versionen häufig ändern, insbesondere in den ersten Releases.

Darüber hinaus erstellen wir einen Canary-Mechanismus, mit dem externe und interne Tester einer Gruppe beitreten können, die die vorgeschlagenen Einschränkungen für die nächste Android-Version erhält. So können wir Feedback und Vertrauen in die vorgeschlagenen Änderungen an den Einschränkungen erhalten.

Häufig gestellte Fragen

  1. Was ist ein werbebezogenes SDK?

    Ein anzeigenbezogenes SDK ermöglicht jegliches Targeting von Nutzern mit Nachrichten für kommerzielle Zwecke in Apps, die nicht dem Werbetreibenden gehören. Dazu zählen unter anderem Analyse-SDKs, in denen Nutzergruppen für die nachfolgende Ausrichtung erstellt werden können, Ad Serving-SDKs, SDKs zum Schutz vor Missbrauch und Betrug für Anzeigen sowie SDKs für Interaktionen und Attributions-SDKs.

  2. Kann ein beliebiges SDK in der SDK-Laufzeit ausgeführt werden?

    Obwohl der Schwerpunkt zu Beginn auf anzeigenbezogene SDKs liegt, können Entwickler von nicht werbebezogenen SDKs, die datenschutzfreundlich sind und der Ansicht sind, dass sie unter den oben beschriebenen Bedingungen verwendet werden können, Feedback zu ihren SDKs geben, die in der SDK-Laufzeit ausgeführt werden. Die SDK-Laufzeit ist jedoch nicht mit allen SDK-Designs kompatibel. Abgesehen von den dokumentierten Einschränkungen ist die SDK-Laufzeit wahrscheinlich nicht für SDKs geeignet, die eine Kommunikation mit der Hosting-App in Echtzeit oder mit hohem Durchsatz benötigen.

  3. Welche Vorteile bietet die Prozessisolation anstelle der Isolierung innerhalb der Java-basierten Laufzeit eines Prozesses?

    Derzeit erleichtert die Java-basierte Laufzeit die Sicherheitsgrenzen, die für die Datenschutzgarantien für Android-Nutzer erforderlich sind. Der Versuch, so etwas zu implementieren, würde wahrscheinlich mehrjährige Anstrengungen erfordern, ohne eine Erfolgsgarantie zu bieten. Daher nutzt die Privacy Sandbox Anwendungsgrenzen, eine bewährte und gut verständliche Technologie.

  4. Lassen sich durch das Verschieben von SDKs in die SDK-Laufzeit die Downloadgröße oder Speicherplatzeinsparungen erzielen?

    Wenn in mehrere Anwendungen laufzeitfähige SDKs derselben Version eingebunden sind, kann dies die Downloadgröße und den Speicherplatz reduzieren.

  5. Auf welche Art von App-Lebenszyklus-Ereignissen, z. B. wenn die App in den Hintergrund geht, haben SDKs in der SDK-Laufzeit Zugriff?

    Wir arbeiten aktiv an der Designunterstützung für die Benachrichtigung der SDK-Laufzeit über Lebenszyklusereignisse ihrer Clientanwendung auf App-Ebene (z.B. App, die im Hintergrund ausgeführt wird, oder App, die im Vordergrund ausgeführt wird). Das Design und der Beispielcode werden demnächst in einer Entwicklervorschau veröffentlicht.