SDK-Laufzeit – Übersicht

Hinweis: Dieses Dokument enthält die aktuellen Designvorschläge für die Privacy Sandbox für Android und kann sich noch ändern. Wir freuen uns über Ihr Feedback und Ihre Kommentare, die uns bei dieser Arbeit unterstützen.

Auf der Android-Plattform wird das Konzept der App-Sandbox verwendet, um robuste Ausführungs- und Sicherheitsgrenzen für App-Code entlang von Prozessgrenzen zu wahren. Es ist üblich, dass Apps Code von Drittanbietern enthalten, 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 leicht alleine tun könnten.

Wie bei den meisten Betriebssystemen werden Android-SDKs in der Sandbox der Host-App ausgeführt und erben dieselben Berechtigungen wie die Host-App sowie den Zugriff auf den Arbeitsspeicher und den Speicher der Host-App. Diese Architektur ermöglicht zwar eine flexible Einbindung von SDKs und Apps, birgt aber auch das Risiko, dass nicht offengelegte Nutzerdaten erhoben und weitergegeben werden. Außerdem sind App-Entwickler möglicherweise nicht vollständig über die Funktionen eines Drittanbieter-SDKs und die Daten im Klaren, auf die es zugreift. Das erschwert es, die Datenerhebung und -weitergabe ihrer App zu berücksichtigen.

In Android 14 haben wir eine neue Plattformfunktion hinzugefügt, mit der SDKs von Drittanbietern in einer speziellen Laufzeitumgebung namens SDK Runtime ausgeführt werden können. Die SDK-Laufzeit bietet im Hinblick auf das Erheben und Weitergeben von Nutzerdaten folgende Sicherheitsvorkehrungen und Gewährleistungen:

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

Hinweis :Bei der ersten Version der SDK Runtime konzentrieren wir uns auf die Unterstützung von werbebezogenen SDKs, einschließlich SDKs, die die Anzeigenbereitstellung, die Anzeigenmessung, die Erkennung von Anzeigenbetrug und Missbrauch ermöglichen. Werbebezogene SDKs werden weiter unten in diesem Dokument beschrieben.

Wir suchen aktiv nach Feedback von der Community für mobile App-Werbung zu diesem Design. Wir freuen uns auch über Feedback von der gesamten Entwicklergemeinschaft, um zukünftige Iterationen der SDK-Laufzeit zu gestalten, einschließlich Unterstützung für zusätzliche Anwendungsfälle.

Ziele

Mit diesem Vorschlag sollen die folgenden Ziele erreicht werden:

• Reduzieren Sie den nicht offengelegten Zugriff und die Weitergabe der App-Daten eines Nutzers durch Drittanbieter-SDKs durch Prozessisolierung und eine klar definierte API- und Datenzugriffssteuerung. Weitere Informationen zur Prozessisolierung finden Sie in einem separaten Abschnitt dieses Dokuments.
• Reduzieren Sie das nicht offengelegte Tracking der App-Nutzung eines Nutzers durch Drittanbieter-SDKs, indem Sie den Zugriff von SDKs auf eindeutige, persistente IDs einschränken.
• Beschleunigen Sie die Verteilung von SDK-Updates auf Apps, indem Sie die Belastung für App-Entwickler und Endnutzer reduzieren. Weitere Informationen zum vorgeschlagenen Modell für die vertrauenswürdige SDK-Bereitstellung finden Sie in einem anderen Abschnitt dieses Dokuments.
• App-Entwicklern dabei helfen, den Datenzugriff und die Datenweitergabe ihrer App besser zu berücksichtigen
• SDK-Entwicklern dabei helfen, Manipulationen durch andere SDKs zu verhindern, indem bestimmte unsichere Sprachkonstrukte wie JNI-Code eingeschränkt werden.
• Mithilfe der vollständigen Kontrolle über die Remote-Aufrufe, auf denen Medien präsentiert werden, können SDKs für Anzeigen ungültige Zugriffe und Anzeigenbetrug erkennen und verhindern.
• unnötige Auswirkungen auf App- und SDK-Entwickler so weit wie möglich zu minimieren.

SDKs werden in einem isolierten Prozess ausgeführt

Die vorgeschlagene SDK-Laufzeit ermöglicht es kompatiblen SDKs, die im Folgenden als laufzeitfähige SDKs (RE) bezeichnet werden, in einem separaten Prozess für die App ausgeführt zu werden. Die Plattform ermöglicht die bidirektionale Kommunikation zwischen dem Prozess der App und ihrer SDK-Laufzeit. Weitere Informationen finden Sie im Abschnitt Kommunikation dieses Dokuments. Nicht-RE-SDKs bleiben wie bisher im App-Prozess erhalten. Die folgenden Diagramme veranschaulichen diese Änderungen:

Bevor der SDK-Aufrufcode der SDK-Laufzeit hinzugefügt wird, befindet er sich zusammen mit den SDKs, die die Aufrufe von diesem Code erhalten, im Prozess der App.

---

Nachdem der SDK-Aufrufcode der SDK-Laufzeit hinzugefügt wurde, kommuniziert er im Vordergrundprozess der App mit den SDK-Schnittstellen. Diese Schnittstellen überschreiten dann eine Prozessgrenze in den SDK Runtime-Prozess, um die SDKs selbst aufzurufen.

Neues vertrauenswürdiges Vertriebsmodell für SDKs

Diese vorgeschlagene Trennung des SDKs von der App motiviert zu einem weiteren Trennungskonzept, nämlich für die Bereitstellung von SDKs und Apps. Unser Vorschlag erfordert einen vertrauenswürdigen Bereitstellungs- und Installationsmechanismus, um sicherzustellen, 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üssen nicht mehr statisch verknüpft und mit ihren Apps verpackt werden, bevor sie zum Vertrieb in einen App-Shop hochgeladen werden. Stattdessen geschieht Folgendes:

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, eine App-Version erstellen und hochladen, die die tatsächlichen SDK-Abhängigkeiten nicht enthält.
3. Wenn ein Nutzer diese App herunterlädt, können die angegebenen SDK-Abhängigkeiten der App während des Installationsvorgangs verwendet werden, um sie dann aus dem App-Shop herunterzuladen.

Mit diesem neuen Bereitstellungsmechanismus können SDK-Entwickler unterbrechungsfreie Änderungen (d. h. keine Änderungen an APIs oder deren Semantik) an ihren SDKs vornehmen und sie ohne Einbindung von App-Entwicklern auf Geräten bereitstellen. Diese nicht fehlerbehafteten SDK-Änderungen können bereitgestellt oder rückgängig gemacht werden, ohne dass App-Entwickler ihre Apps unbedingt mit den neuen SDKs neu erstellen oder Endnutzer ihre Apps aktualisieren müssen. App-Entwickler müssen weiterhin Updates für bahnbrechende Änderungen vornehmen. SDK-Entwickler können ihre neuesten nicht bahnbrechenden Änderungen und Fehlerkorrekturen jedoch schneller und einheitlicher für mehr Nutzer bereitstellen und so idealerweise die Versionsunterstützung minimieren.

Die folgenden Diagramme veranschaulichen die vorgeschlagenen Änderungen bei der SDK-Bereitstellung:

Vor der Einführung der SDK Runtime haben Entwickler ihre SDKs direkt an Apps gesendet.

---

Nach der Einführung der SDK Runtime können SDK-Entwickler ihre SDKs über eine SDK-Upload-Benutzeroberfläche in einem App-Shop veröffentlichen. Der App-Shop kümmert sich dann um die Bereitstellung von Apps und aller SDK-Abhängigkeiten auf den Geräten der Endnutzer.

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

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

• Zugriff: Berechtigungen, Arbeitsspeicher, Speicherplatz
• Ausführung: Sprachen, Laufzeitänderungen, Lebenszyklus, Medienrendering
• Kommunikation: App-zu-SDK und SDK-zu-SDK
• Entwicklung: Informationen zum Erstellen, Debuggen und Testen in diesem Modell
• Bereitstellung: Informationen zum Bereitstellen, Aktualisieren und Zurückrollen von Android-Versionen, Apps und SDKs

Dieses Dokument enthält auch eine Liste mit häufig gestellten Fragen.

Dies ist ein erster Designvorschlag. Uns ist bewusst, dass dies für einige Mitglieder des Ökosystems eine bedeutende Änderung sein kann. Deshalb möchten wir Sie bitten, uns über den Issue Tracker Feedback zu geben.

Zugriff

Die Verwaltung der Datensicherheit eines Systems bedeutet, zu verwalten, wie verschiedene Parteien auf verschiedene Ressourcen zugreifen können. Um unseren Datenschutzgrundsatz zu erfüllen, schlagen wir vor, das Modell für den Zugriff auf Apps, SDKs und Nutzerdaten so zu aktualisieren, dass es dem Prinzip der geringsten Berechtigung folgt, um den unbefugten Zugriff auf potenziell sensible Daten zu verhindern.

SDK-Berechtigungen

Als separater Prozess hätte die SDK Runtime eigene, klar definierte Berechtigungen, anstatt die Berechtigungen zu übernehmen, die der Nutzer der App gewährt hat. Basierend auf vorläufigen Recherchen zu den Berechtigungen, die von werbebezogenen SDKs verwendet werden, schlagen wir vor, dass SDKs in der SDK Runtime standardmäßig auf die folgenden Berechtigungen zugreifen können:

• INTERNET: Zugriff auf das Internet, um mit einem Webdienst kommunizieren zu können.
• ACCESS_NETWORK_STATE: Zugriff auf Informationen zu Netzwerken.
• READ_BASIC_PHONE_STATE: Zugriff auf Informationen zum Status des Smartphones, z. B. zum Mobilfunknetztyp.
• Berechtigungen für den Zugriff auf die datenschutzfreundlichen APIs, die grundlegende Werbefunktionen bieten, ohne dass Zugriff auf plattformübergreifende Kennungen erforderlich ist.
• AD_ID: Möglichkeit, die Werbe-ID anzufordern. Dies wird auch durch den Zugriff der App auf diese Berechtigung eingeschränkt.

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 Usability-Sicht einzuschränken. Wir bitten um Feedback zu Anwendungsfällen, die mit diesen Berechtigungen möglicherweise nicht abgedeckt werden.

Speicher

Die SDK-Laufzeit hat aufgrund ihres eigenen Prozesses einen eigenen isolierten Arbeitsspeicher. Bei dieser Struktur würde dem SDK standardmäßig der Zugriff auf den Arbeitsspeicher der App verweigert und die Anwendung könnte ebenfalls nicht auf den Arbeitsspeicher des SDKs zugreifen. Wir empfehlen, dieses Standardverhalten beizubehalten, um dem Prinzip der geringsten Berechtigung zu entsprechen.

Speicher

Mit diesem Vorschlag soll der Zugriff von SDKs auf den Speicher für den normalen Betrieb ausgeglichen und das App- und Prozessübergreifende Tracking mithilfe von nichtflüchtigem Speicher minimiert werden. Wir schlagen folgende Änderungen am aktuellen Zugriff auf den Speicher vor:

• Eine App kann nicht direkt auf den Speicher des SDKs zugreifen und umgekehrt.
• Der externe Speicher des Geräts ist für SDKs nicht zugänglich.
• Innerhalb jeder SDK-Laufzeit gibt es sowohl Speicher, auf den alle SDKs zugreifen können, als auch Speicher, der für ein bestimmtes SDK privat ist.

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

Ausführung

Um ein privates System zwischen Apps, SDKs und Nutzern zu gewährleisten, müssen diese Datenschutzgrenzen durch den Ausführungskontext selbst (Codeformate, Sprachkonstrukte, zugängliche APIs und Systemdaten) verstärkt werden oder es dürfen zumindest keine Möglichkeiten geben, sie zu umgehen. Gleichzeitig möchten wir den Zugriff auf die umfangreiche Plattform und die meisten Laufzeitfunktionen beibehalten, die SDKs derzeit haben. Hier schlagen wir eine Reihe von Änderungen an der Laufzeitumgebung vor, um dieses Gleichgewicht zu erreichen.

Code

Android-Code (Apps und SDKs) wird hauptsächlich von der Android Runtime (ART) interpretiert, unabhängig davon, ob der Code in Kotlin oder Java geschrieben wurde. Die Vielfalt von ART und die von ihm angebotenen Sprachkonstrukte in Kombination mit der Überprüfbarkeit im Vergleich zu Alternativen – insbesondere zu nativem Code – scheinen Funktionalität und Datenschutz in einem angemessenen Verhältnis zu halten. Wir empfehlen, dass laufzeitfähiger SDK-Code ausschließlich aus Dex-Bytecode besteht und keinen JNI-Zugriff unterstützt.

Uns ist bewusst, dass es Anwendungsfälle gibt, z. B. die Verwendung von benutzerdefiniert verpacktem SQLite, die aufgrund der Verwendung von nativem Code durch eine Alternative ersetzt werden müssen, z. B. die integrierte SQLite-Version des Android SDK.

SELinux

Unter Android wird jeder Prozess (einschließlich derjenigen, die als Root ausgeführt werden) mit einem bestimmten SELinux-Kontext ausgeführt, sodass der Kernel die Zugriffssteuerung für Systemdienste, Dateien, Geräte und andere Prozesse verwalten kann. Wir möchten die meisten SDK-Anwendungsfälle beibehalten und gleichzeitig die Umgehung der Datenschutzmaßnahmen minimieren, die wir vorantreiben möchten. Daher schlagen wir die folgenden Änderungen am SELinux-Kontext einer nicht systeminternen App für die SDK-Laufzeit vor:

• Es wäre nur auf eine begrenzte Anzahl von Systemdiensten zuzugreifen. (Aktives Design)
• SDKs könnten dann nur den Code in ihrem APK laden und ausführen.
• Es wäre nur auf eine begrenzte Anzahl von Systemeigenschaften zuzugreifen. (Aktives Design)

APIs

Die Verwendung von Reflection und das Aufrufen von APIs innerhalb der SDK-Laufzeit ist zulässig. Ein SDK darf jedoch keine Reflection verwenden oder APIs in einem anderen runtimefähigen SDK aufrufen. Einen vollständigen Vorschlag für verbotene APIs geben wir in einem zukünftigen Update bekannt.

Außerdem wurde der Zugriff auf persistente IDs in den letzten Android-Plattformversionen zunehmend eingeschränkt, um den Datenschutz zu verbessern. Für die SDK-Laufzeit empfehlen wir, den Zugriff auf Kennungen weiter einzuschränken, die für App-übergreifendes Tracking verwendet werden könnten.

Auf SDK-Laufzeit-APIs kann nur über Apps zugegriffen werden, die im Vordergrund ausgeführt werden. Der Zugriff auf SdkSandboxManager APIs über Apps im Hintergrund führt zu einer SecurityException-Ausnahme.

Außerdem können RE-SDKs die Benachrichtigungs-APIs nicht verwenden, um jederzeit Nutzerbenachrichtigungen zu senden.

Lifecycle

App-SDKs folgen derzeit dem Lebenszyklus ihrer Host-App. Wenn die App also den Vordergrund betritt oder verlässt, heruntergefahren wird oder aufgrund von Speichermangel vom Betriebssystem zwangsweise beendet wird, gilt das auch für die SDKs der App. Unser Vorschlag, die SDKs einer App in einem separaten Prozess zu verwalten, hat die folgenden Änderungen am Lebenszyklus zur Folge:

• Die App kann vom Nutzer oder vom Betriebssystem beendet werden. Die SDK-Laufzeit wird sofort danach automatisch beendet.

• Die SDK-Laufzeit kann beispielsweise aufgrund von Speichermangel oder einer nicht behandelten Ausnahme in einem SDK vom Betriebssystem beendet werden.

  Unter Android 14 wird die SDK-Laufzeit bei einer App im Vordergrund mit hoher Priorität ausgeführt und wird nur selten beendet. Wenn die App in den Hintergrund wechselt, wird die Priorität des SDK-Laufzeitprozesses herabgesetzt und er kann beendet werden. Die Priorität des SDK-Laufzeitprozesses bleibt niedrig, auch wenn die App wieder in den Vordergrund wechselt. Daher ist es sehr wahrscheinlich, dass es im Vergleich zur App bei Speichermangel beendet wird.

  Unter 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 App 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 nicht verarbeitete Ausnahme auftritt, geht der Status der SDK-Laufzeit einschließlich aller zuvor geladenen SDKs und Remote-Ansichten verloren. Der App-Entwickler kann die Beendigung der SDK-Laufzeit mit einer der folgenden Methoden behandeln:

  • Der Vorschlag bietet App-Entwicklern entsprechende Lebenszyklus-Callback-Methoden, mit denen sie erkennen können, wann die SDK-Laufzeit beendet wurde.
  • Wenn die SDK-Laufzeit während der Auslieferung von Anzeigen beendet wird, funktionieren die Anzeigen möglicherweise nicht wie erwartet. So können Ansichten beispielsweise auf dem Bildschirm eingefroren sein und nicht mehr interaktiv sein. Die App kann die Anzeigenansicht entfernen, wenn sie die Nutzerfreundlichkeit nicht beeinträchtigt.
  • Die App kann einen weiteren Versuch unternehmen, 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, die SDKs geladen haben, werden beendet und schließen normal.
  • Binder-Objekte, die vom SDK zurückgegeben werden, um damit zu kommunizieren (z. B. SandboxedSdk), lösen eine DeadObjectException aus, wenn sie von der App verwendet werden.

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

  Bei anhaltenden Fehlern sollte der App-Entwickler eine schrittweise Fehlerbehebung ohne das SDK planen oder den Nutzer benachrichtigen, wenn das SDK für die Hauptfunktionen der App entscheidend ist. Weitere Informationen zu dieser Interaktion zwischen App und SDK finden Sie in diesem Dokument im Abschnitt zu Kommunikationen.

Bei Nicht-RE-SDKs können weiterhin Standard-Betriebssystemprimitive verwendet werden, die für die eingebettete App verfügbar sind, einschließlich Diensten, Aktivitäten und Übertragungen. Bei RE-SDKs ist das nicht möglich.

Sonderfälle

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

• Wenn mehrere Apps dieselbe UID verwenden, funktioniert die SDK-Laufzeit möglicherweise nicht richtig. Die Unterstützung für freigegebene UIDs wird möglicherweise in Zukunft hinzugefügt.
• Bei Apps mit mehreren Prozessen sollte das SDK im Hauptprozess geladen werden.

Medien-Rendering

Es gibt SDKs, die Inhalte wie Text, Bilder und Video in einer von der App angegebenen Ansicht rendern. Dazu schlagen wir ein Remote-Rendering vor, bei dem das SDK die Medien innerhalb der SDK-Laufzeit rendert, aber die SurfaceControlViewHost API verwendet, um das Rendern der Medien in einer app-spezifischen Ansicht zu ermöglichen. So kann das SDK diese Medien auf eine für den Nutzer private Weise rendern und gleichzeitig ungültige oder betrügerische Nutzerinteraktionen mit den gerenderten Medien verhindern und erkennen.

Native Anzeigen, die nicht vom SDK, sondern von der App gerendert werden, werden von SDKs in der SDK-Laufzeit unterstützt. Die Signalerhebung und das Abrufen von Creatives erfolgen bei nicht nativen Anzeigen wie gewohnt. Dieser Bereich ist Gegenstand aktueller Forschung.

In-Stream-Videoanzeigen werden in einem Video in einem Player in einer App ausgeliefert. Da das Video in einem Player in der App und nicht in einem Player oder einer Ansicht im SDK wiedergegeben wird, unterscheidet sich das Rendering-Modell von anderen Anzeigenformaten. Wir arbeiten aktiv an Mechanismen, die sowohl die serverseitige als auch die SDK-basierte Anzeigenbereitstellung unterstützen.

Systemzustand

Wir möchten die Auswirkungen der SDK-Laufzeit auf die Systemintegrität von Endnutzergeräten minimieren und arbeiten an entsprechenden Lösungen. Einige Android 14-Einstiegsgeräte mit sehr begrenzten Systemressourcen, z. B. Android (Go-Version), werden die SDK-Laufzeit aufgrund der Auswirkungen auf die Systemintegrität jedoch höchstwahrscheinlich nicht unterstützen. Bald veröffentlichen wir die Mindestanforderungen für die Verwendung der SDK-Laufzeit.

Kommunikation

Da Apps und SDKs derzeit im selben Prozess ausgeführt werden, ist die Kommunikation zwischen ihnen ungehindert und nicht vermittelt. Außerdem ermöglicht Android die App-übergreifende Kommunikation, auch wenn die Kommunikation mit SDKs beginnt und endet. Dieses kostenlose Kommunikationsmodell ermöglicht verschiedene Anwendungsfälle und bietet gleichzeitig die Möglichkeit zur Freigabe nicht offengelegter Daten zwischen Apps und zwischen SDKs innerhalb und zwischen Apps. Wir schlagen die folgenden Änderungen an diesem Kommunikationsmodell vor, um ein Gleichgewicht zwischen dem Wert dieser Kommunikation und der Erreichung unserer erklärten Ziele zu schaffen.

App-zu-SDK

Die Schnittstelle zwischen der App und dem SDK ist der häufigste Kommunikationspfad zu einem SDK. Die API eines SDKs ist der Ort, an dem sich ein Großteil der nutzerorientierten Differenzierung und Innovation befindet. Wir möchten die Möglichkeit zur Innovation und Differenzierung von SDKs hier erhalten. Mit unserem Vorschlag können SDKs APIs für Apps freigeben und dafür sorgen, dass Apps von all diesen Innovationen profitieren können.

Aufgrund der Prozessgrenzstruktur der SDK-Laufzeit schlagen wir vor, eine Marshalling-Ebene zu erstellen, auf die innerhalb der App zugegriffen werden kann, um die API-Aufrufe und ‑Antworten oder ‑Callbacks über diese Grenze zwischen der App und dem SDK zu leiten. Wir schlagen vor, dass die Schnittstelle zu dieser Marshalling-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 App- und SDK-Entwicklern die Arbeit mit Boilerplate-Marshalling ersparen, SDK-Entwicklern mehr 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 einschlagen, müssen die API-Definitionen und ‑Tools mit Ihrer Unterstützung entwickelt werden.

Das allgemeine Interaktionsmodell sieht so aus:

• Die App ruft das SDK über die Benutzeroberfläche auf und gibt Callbacks ein.
• Das SDK erfüllt die Anfragen asynchron und antwortet über die Callbacks.
• Das kann auf jedes Publisher-Abonnenten-Modell angewendet werden. Das bedeutet, dass eine App Ereignisse im SDK mit Callbacks abonnieren kann. Wenn diese Ereignisse auftreten, werden die Callbacks ausgelöst.

Eine Folge der neuen prozessübergreifenden Struktur dieses Vorschlags ist, dass zwei Prozesslebenszyklen verwaltet werden müssen: einer für die App selbst und einer für die SDK-Laufzeit. Mit unserem Vorschlag soll so viel wie möglich automatisiert werden, um die Auswirkungen auf App- und SDK-Entwickler zu minimieren. Das folgende Diagramm zeigt einen Ansatz, den wir derzeit prüfen:

Abfolgediagramm, das die Interaktionen zwischen App und SDK beim Starten der App und des SDKs zeigt.

Die Plattform würde neue APIs für Apps bereitstellen, um SDKs dynamisch in den SDK Runtime-Prozess zu laden, über Änderungen am Status des Prozesses benachrichtigt zu werden und mit SDKs zu interagieren, die in die SDK Runtime geladen wurden.

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

Die App kommuniziert über die folgenden Schritte mit dem SDK, das im SDK-Laufzeitprozess ausgeführt wird:

1. Bevor eine App mit einem SDK interagieren kann, muss die App die Plattform auffordern, das SDK zu laden. Um die Integrität des Systems zu gewährleisten, geben Apps in ihrer Manifestdatei die SDKs an, die geladen werden sollen. Diese SDKs sind die einzigen, die geladen werden dürfen.

   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 Benutzeroberfläche zurück. Diese Schnittstelle ist für den App-Prozess gedacht. Wenn die Benutzeroberfläche außerhalb der Prozessgrenze freigegeben werden soll, muss sie als IBinder-Objekt zurückgegeben werden.

   Im Leitfaden zu verknüpften Diensten werden verschiedene Möglichkeiten zur Bereitstellung von IBinder beschrieben. Unabhängig von der gewählten Methode muss sie zwischen dem SDK und der aufrufenden App konsistent sein. In den Diagrammen wird AIDL als Beispiel verwendet.

3. Der SdkSandboxManager empfängt die IBinder-Oberfläche und gibt sie an die App 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();
   

Die App kann auch Medien aus dem SDK rendern. Gehe dazu so vor:

1. Wie im Abschnitt zum Rendern von Medien dieses Dokuments erläutert, kann eine App einen Aufruf an requestSurfacePackage() senden und die entsprechende SurfaceControlViewHost.SurfacePackage abrufen, um ein SDK zum Rendern von Medien in einer Ansicht abzurufen.

   Das folgende Code-Snippet zeigt ein API-Beispiel:

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. Die App kann dann die zurückgegebene SurfacePackage über die setChildSurfacePackage API in SurfaceView in die SurfaceView einbetten.

   Das folgende Code-Snippet zeigt ein API-Beispiel:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

Wir schlagen vor, dass die IBinder- und requestSurfacePackage()-APIs generisch sind und nicht direkt von den Apps aufgerufen werden sollen. Stattdessen werden diese APIs von der oben beschriebenen generierten API-Referenz in einer „Shims“-Ebene aufgerufen, um den Aufwand für App-Entwickler zu reduzieren.

SDK-zu-SDK

Zwei SDKs in derselben App müssen oft miteinander kommunizieren. Das kann passieren, wenn ein bestimmtes SDK aus mehreren SDKs besteht, oder wenn zwei SDKs von verschiedenen Parteien zusammenarbeiten müssen, um eine Anfrage von der anrufenden App zu erfüllen.

Es gibt zwei wichtige Fälle:

• Wenn beide SDKs laufzeitfähig sind In diesem Fall werden beide SDKs in der SDK-Laufzeit mit allen Schutzmaßnahmen ausgeführt. SDKs können nicht so kommunizieren wie innerhalb einer App. Daher wurde eine API in SdkSandboxController hinzugefügt, um SandboxedSdk-Objekte für alle geladenen RE-SDKs abzurufen. So kann ein RE-SDK mit anderen SDKs kommunizieren, die in der SDK-Laufzeit geladen werden.
• Wenn nur ein SDK zur Laufzeit aktiviert ist
  • Wenn das aufrufende SDK in der App ausgeführt wird, funktioniert das nicht anders als wenn die App selbst das zweite SDK innerhalb der SDK Runtime aufruft.
  • Wenn das aufrufende SDK innerhalb der SDK-Laufzeit ausgeführt wird, wird in diesem Vorschlag empfohlen, eine Methode mit der im Abschnitt „App-zu-SDK“ beschriebenen IBinder bereitzustellen, auf die der Code in der App wartet, sie verarbeitet und mit den bereitgestellten Callbacks antwortet.
  • Anzeigen-SDKs, die nicht zur Laufzeit aktiviert sind, können sich möglicherweise nicht selbst registrieren. Wir empfehlen, ein Mediator-SDK zu erstellen, das alle Partner- oder App-SDKs als direkte Abhängigkeiten der App enthält und die Registrierung übernimmt. Dieses Mediator-SDK stellt die Kommunikation zwischen nicht laufzeitfähigen SDKs oder anderen App-Abhängigkeiten und dem laufzeitfähigen Mediator her, der als Adapter dient.

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 Runtime (verfügbar in der neuesten Entwicklervorschau)
• So sollten Ansichten und Remote-Rendering für die Vermittlung funktionieren (Vorschlag in der Entwicklung)

Bei der Entwicklung der Primitiven werden die folgenden Anwendungsfälle berücksichtigt:

1. Vermittlung und Gebotseinstellung Viele Werbe-SDKs bieten eine Vermittlungs- oder Gebotsfunktion, bei der das SDK verschiedene andere SDKs für eine Anzeigenimpression (Vermittlung) oder für die Signalerfassung zum Ausführen einer Auktion (Gebotsfunktion) aufruft. Normalerweise ruft das koordinierende SDK andere SDKs über einen Adapter auf, der vom koordinierenden SDK bereitgestellt wird. Unter Berücksichtigung der oben genannten Primitiven sollte das koordinierende SDK, unabhängig davon, ob es sich um ein RE-SDK handelt, für den normalen Betrieb auf alle RE- und Nicht-RE-SDKs zugreifen können. Das Rendering in diesem Kontext ist ein aktives Forschungsgebiet.
2. Merkmalerkennung Einige SDK-Produkte bestehen aus kleineren SDKs, die durch einen Prozess der SDK-übergreifenden Erkennung den endgültigen Funktionsumfang bestimmen, der dem App-Entwickler zur Verfügung gestellt wird. Registrierungs- und Discovery-Primitive sollen diesen Anwendungsfall ermöglichen.
3. Abomodelle von Publishern Einige SDKs sind so konzipiert, dass es einen zentralen Publisher von Ereignissen gibt, die andere SDKs oder Apps über Callbacks abonnieren können, um Benachrichtigungen 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 miteinander kommunizieren, ein runtimefähiges SDK. Dies ist ein potenzieller Vektor für die Weitergabe nicht offengelegter Daten. Daher kann die SDK Runtime keinen direkten Kommunikationskanal mit anderen Apps als der Clientanwendung oder mit SDKs in einer anderen SDK-Laufzeit herstellen, die für eine andere App erstellt wurde. Dies geschieht auf folgende Weise:

• Das SDK kann keine Komponenten wie <service>, <contentprovider> oder <activity> in seinem Manifest definieren.
• Das SDK kann keine ContentProvider veröffentlichen oder eine Übertragung senden.
• Das SDK kann eine Aktivität starten, die zu einer anderen App gehört, aber es gibt Einschränkungen bei dem, was im Intent gesendet werden kann. Beispielsweise können diesem Intent keine Extras oder benutzerdefinierten Aktionen hinzugefügt werden.
• Das SDK kann nur gestartet oder an eine Zulassungsliste von Diensten gebunden werden.
• Das SDK kann nur auf einen Teil des Systems ContentProvider zugreifen (z. B. com.android.providers.settings.SettingsProvider), bei dem die abgerufenen Daten keine IDs haben und nicht zum Erstellen eines Fingerabdrucks des Nutzers verwendet werden können. Diese Prüfungen gelten auch für den Zugriff auf ContentProvider über ContentResolver.
• Das SDK kann nur auf einen Teil der geschützten Broadcast-Empfänger zugreifen, z. B. android.intent.action.AIRPLANE_MODE.

Manifest-Tags

Wenn das SDK installiert wird, analysiert PackageManager das Manifest des SDKs und installiert es nicht, wenn verbotene Manifest-Tags vorhanden sind. Das SDK definiert beispielsweise möglicherweise keine Komponenten wie <service>, <activity>, <provider> oder <receiver> und deklariert im Manifest keine <permission>. Tags, die nicht installiert werden können, werden in der SDK-Laufzeit nicht unterstützt. Tags, die bei der Installation nicht fehlschlagen, aber ignoriert werden, werden möglicherweise in zukünftigen Android-Versionen unterstützt.

Diese Prüfungen können auch von allen Buildzeit-Tools angewendet werden, die vom SDK zum Erstellen des SDK-Bundles verwendet werden, und beim Hochladen in den App-Shop.

Unterstützung bei Aktivitäten

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

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

Hinweis: Das von der Plattform übergebene Activity-Objekt ist vom Typ android.app.Activity, der nicht mit androidx kompatibel ist, z. B. appcompat oder Compose.

Hinweis: Die Context des bereitgestellten Activity darf nicht von SDKs verwendet werden. Stattdessen sollte das SDK SandboxedSdkProvider#getContext() verwenden, um die richtige Context abzurufen.

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

Der Ablauf der Anfrage einer Aktivität ist in der folgenden Grafik dargestellt.

Abfolgediagramm, das den Ablauf zum Starten einer Aktivität zeigt

Entwicklung

Ein wichtiges Prinzip dieses Vorschlags besteht darin, die Auswirkungen auf das Entwickler-Ökosystem so weit wie möglich zu minimieren. Dieser Vorschlag bietet Entwicklern eine umfassende Palette von Entwicklungstools zum Erstellen, Erstellen und Debuggen von RE-Apps 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.

Hinweis: Dieser Abschnitt befindet sich noch in der frühen Designphase, sodass weniger Details untersucht wurden und sich vieles ändern könnte. Unser Ziel ist es, unsere Absicht basierend auf dem zu teilen, was wir derzeit für möglich halten, um frühzeitig Feedback zu erhalten.

In der Erstellung

Android Studio und zugehörige Tools werden so aktualisiert, dass sie die SDK-Laufzeit unterstützen. So können Entwickler ihre RE-Apps und SDKs korrekt konfigurieren und alte oder nicht unterstützte Aufrufe gegebenenfalls auf neuere Alternativen umstellen. Während der Erstellungsphase müssen Entwickler einige Schritte ausführen, die in unserem Vorschlag vorgesehen sind.

App-Entwickler

Apps müssen ihre RE SDK- und SDK-Zertifikatsabhängigkeiten im App-Manifest angeben. In unserem Vorschlag behandeln wir dies als die Quelle der Wahrheit des Anwendungsentwicklers. Beispiel:

• Name:Paketname des SDK oder der Bibliothek.
• Hauptversion:Hauptversionscode des SDKs.
• Zertifikat-Digest:Der Zertifikat-Digest des SDK-Builds. Wir empfehlen SDK-Entwicklern, diesen Wert für einen bestimmten Build über den entsprechenden App-Shop abzurufen und zu registrieren.

Dies gilt nur für über App-Shops verteilte SDKs, unabhängig davon, ob sie RE sind oder nicht. Apps, die SDKs statisch verknüpfen, verwenden die aktuellen Abhängigkeitsmechanismen.

Da wir die Auswirkungen auf Entwickler so gering wie möglich halten möchten, ist es wichtig, dass App-Entwickler nach der Angabe einer Ziel-API-Ebene, die die SDK-Laufzeit unterstützt, nur einen einzigen 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 Entwickler von RE SDKs im Manifest explizit ein neues Element deklarieren, das das SDK oder die Bibliothek darstellt. Außerdem müssen ähnliche Werte wie für die Abhängigkeit angegeben werden, einschließlich einer Minor-Version:

• Name:Paketname des SDK oder der Bibliothek.
• Hauptversion:Hauptversionscode des SDKs.
• Nebenversion:Nebenversionscode des SDKs.

Wenn Entwickler von RE SDKs andere RE SDKs als Buildzeitabhängigkeiten haben, müssen sie diese wahrscheinlich auf dieselbe Weise deklarieren, wie ein App-Entwickler die gleiche Abhängigkeit deklarieren würde. RE-SDKs, die von Nicht-RE-SDKs abhängen, würden diese statisch verknüpfen. Dies kann zu Problemen führen, die beim Build oder während der Tests 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.

RE SDK-Entwickler sollten die Unterstützung für Geräte ohne RE weiterhin aufrechterhalten, z. B. für Android 12 oder niedriger und wie im Abschnitt Systemgesundheit des Dokuments erwähnt, für Einstiegsgeräte mit Android 14 und sehr begrenzten Systemressourcen. Wir arbeiten an Lösungen, damit SDK-Entwickler eine einzige Codebasis für die Unterstützung von RE- und Nicht-RE-Umgebungen beibehalten können.

Builds

App-Entwickler

Wir gehen davon aus, dass sich der Build-Schritt für App-Entwickler kaum ändern wird. SDK-Abhängigkeiten, unabhängig davon, ob sie lokal oder über den App-Shop verteilt werden (RE oder nicht), müssen auf dem Computer vorhanden sein, um Linting, Kompilierung und Builds ausführen zu können. Wir schlagen vor, dass Android Studio diese Details bei normaler Nutzung von den App-Entwicklern abstrahiert und dies so transparent wie möglich macht.

Wir gehen davon aus, dass ein DEBUG-Build alle Code- und Symbole enthalten muss, die für die Fehlerbehebung erforderlich sind. Bei RELEASE-Builds werden optional alle im App-Shop angebotenen SDKs (RE oder nicht) aus dem endgültigen Artefakt entfernt.

Wir befinden uns noch in der frühen Phase der Designentwicklung und werden weitere Informationen bekannt geben, sobald es Neuigkeiten gibt.

SDK-Entwickler

Wir arbeiten daran, dass nicht-RE- und RE-Versionen eines SDKs in ein einzelnes Artefakt für den Vertrieb eingebunden werden können. So müssen App-Entwickler keine separaten Builds für RE- und Nicht-RE-Versionen eines SDKs unterstützen.

Ähnlich wie bei Apps müssen alle im App-Shop angebotenen Abhängigkeits-SDKs für das Linting, die Kompilierung und die Builds auf dem Computer vorhanden sein. Wir gehen davon aus, dass Android Studio dies nahtlos ermöglichen wird.

Test

App-Entwickler

Wie in unserem Vorschlag beschrieben, können App-Entwickler ihre Apps wie gewohnt auf Geräten mit Android 14 testen. Nachdem die App erstellt wurde, kann sie auf einem RE-Gerät oder Emulator installiert werden. Bei diesem Installationsprozess werden die richtigen SDKs in der SDK-Laufzeit für das Gerät oder den Emulator installiert, 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. Unser Vorschlag ändert daran nichts. Die In-App-Validierung würde den oben für App-Entwickler beschriebenen Schritten folgen, mit einem einzigen Build-Artefakt sowohl für Apps mit als auch ohne Realtime-Elemente. SDK-Entwickler können ihren Code Schritt für Schritt durchgehen, unabhängig davon, ob er sich in der SDK-Laufzeit befindet. Es kann jedoch einige Einschränkungen bei erweiterten Tools zur Fehlerbehebung und zum Profiling geben. Dieser Bereich wird derzeit intensiv erforscht.

Vertrieb

Unser Designvorschlag zur Trennung einer App von ihren SDKs hat die Möglichkeit für die App-Shop-Bereitstellung von SDKs geschaffen. Diese Möglichkeit ist allgemein und nicht auf einen bestimmten App-Shop beschränkt. Die Vorteile liegen auf der Hand:

• Qualität und Konsistenz von SDKs sicherstellen
• Die Veröffentlichung für SDK-Entwickler wird optimiert.
• Beschleunigen Sie das Roll-out von SDK-Minor-Versionen für installierte Apps.

Um den SDK-Vertrieb zu unterstützen, muss ein App-Shop wahrscheinlich die meisten der folgenden Funktionen bereitstellen:

• Ein Mechanismus, mit dem SDK-Entwickler ihre im App-Shop verteilbaren SDKs in den Store hochladen, aktualisieren, rückgängig machen und gegebenenfalls entfernen können.
• Ein Mechanismus, der die Integrität eines SDK und seiner Herkunft sowie einer App und ihrer Herkunft sicherstellt und ihre Abhängigkeiten auflöst.
• Einen Mechanismus zum zuverlässigen und leistungsstarken Bereitstellen auf Geräten.

Im Laufe der Zeit ändernde Einschränkungen

Wir gehen davon aus, dass sich die Einschränkungen für Code in der SDK-Laufzeit mit den nächsten Android-Versionen weiterentwickeln werden. Um die Anwendungskompatibilität zu gewährleisten, ändern wir diese Einschränkungen nicht durch Mainline-Modulupdates für eine bestimmte SDK-Ebene. Das Verhalten, das mit einer bestimmten targetSdkVersion verknüpft ist, bleibt erhalten, bis die Unterstützung für diese targetSdkVersion aufgrund von App-Shop-Richtlinien eingestellt wird. Die Einstellung von targetSdkVersion kann schneller erfolgen als bei Apps. Die Einschränkungen ändern sich häufig zwischen den Android SDK-Versionen, insbesondere in den ersten Releases.

Außerdem entwickeln 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 Version von Android erhält. So können wir Feedback zu den vorgeschlagenen Änderungen an den Einschränkungen erhalten und diese gegebenenfalls anpassen.

FAQ

1. Was ist ein werbebezogenes SDK?

   Ein werbebezogenes SDK ermöglicht die Ausrichtung von Nutzern auf kommerzielle Inhalte in Apps, die nicht dem Werbetreibenden gehören. Dazu gehören unter anderem Analyse-SDKs, mit denen Nutzergruppen für das spätere Targeting erstellt werden können, Anzeigenbereitstellungs-SDKs, Anti-Missbrauchs- und Anti-Betrugs-SDKs für Anzeigen, Engagement-SDKs und Attributions-SDKs.

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

   Der Schwerpunkt liegt zwar auf Anzeigen-SDKs, aber auch Entwickler von nicht werbebezogenen SDKs, die datenschutzfreundlich sind und der Meinung sind, dass sie die oben genannten Bedingungen erfüllen, können Feedback zu ihren SDKs geben, die in der SDK Runtime 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 Echtzeit- oder Hochdurchsatzkommunikation mit der Hosting-App erfordern.

3. Warum sollten Sie die Prozessisolierung anstelle der Isolation innerhalb der Java-basierten Laufzeit eines Prozesses wählen?

   Derzeit bietet die Java-basierte Laufzeit nicht die Sicherheitsgrenzen, die für die Datenschutzanforderungen von Android-Nutzern erforderlich sind. Der Versuch, so etwas zu implementieren, würde wahrscheinlich mehrere Jahre in Anspruch nehmen und ist nicht garantiert erfolgreich. Daher werden in der Privacy Sandbox Prozessgrenzen verwendet, eine bewährte und gut verstandene Technologie.

4. Würde der Wechsel von SDKs in den SDK-Laufzeitprozess zu Einsparungen bei der Downloadgröße oder beim Speicherplatz führen?

   Wenn mehrere Apps mit runtimefähigen SDKs derselben Version integriert sind, kann dies die Größe des Downloads und den Speicherplatz verringern.

5. Auf welche Art von App-Lebenszyklusereignissen, z. B. wenn die App im Hintergrund ausgeführt wird, haben SDKs in der SDK Runtime Zugriff?

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