Diese Seite wurde von der Cloud Translation API übersetzt.

SDK-Laufzeit – Übersicht

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 wird die App Entwickelnden sich auf die Alleinstellungsmerkmale ihrer App und nutzen Fachleuten, ihre Ausführung über das hinausgehen, was sie ohne Weiteres tun können. für sich allein.

Wie bei den meisten Betriebssystemen werden auch bei Android-SDKs Sandbox ausführen und dieselben Berechtigungen und Berechtigungen wie die Host-App sowie auf den Arbeitsspeicher und Speicher der Host-App. Obwohl diese Architektur können SDKs und Apps flexibel integriert werden, Erhebung und Weitergabe nicht offengelegter Nutzerdaten. 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 13 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

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 folgende Ziele erreicht werden:

den nicht offengelegten Zugriff auf App-Daten eines Nutzers sowie dessen Freigabe durch Drittanbieter einschränken SDKs durch Prozessisolierung und klar definierte API- und Datenzugriffskontrolle. Weitere Informationen zur Prozessisolation in einem separaten Abschnitt in diesem Dokument.
Sie können das nicht offengelegte Tracking der App-Nutzung eines Nutzers durch Drittanbieter-SDKs reduzieren, indem Sie damit der Zugriff auf eindeutige, dauerhafte IDs durch SDKs eingeschränkt wird.
Die Bereitstellung von SDK-Updates in Apps kann sicher beschleunigt werden, indem die App-Entwickler und Endnutzer. 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 besser zu berücksichtigen ihrer App.
SDK-Entwicklern dabei helfen, Manipulationen durch andere SDKs zu verhindern, indem bestimmte unsichere Sprachkonstrukte wie JNI-Code eingeschränkt werden
Anzeigen-SDKs unterstützen, ungültige Zugriffe und Werbebetrug vollständig zu erkennen und zu verhindern die Steuerung der Remote-Ansichten für Medien.
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 Runtime ermöglicht kompatible SDKs, auf die im gesamten Den Rest dieses Dokuments als laufzeitfähige (RE) SDKs, die in einem einen separaten Prozess für die App. Die Plattform ermöglicht bidirektionale Kommunikation zwischen dem App-Prozess und der SDK-Laufzeit. Weitere Informationen finden Sie in der Kommunikationsabschnitt dieses Dokuments. Nicht-RE-SDKs bleiben im Prozess der Anwendung wie bisher. Die folgenden Diagramme veranschaulichen diese Änderungen:

Diagramm „Vorher“, das alle Ausführungen des Anwendungsprozesses zeigt — 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.

Diagramm, das Prozesse zeigt, die zwischen App- und SDK-Laufzeitprozess aufgeteilt sind — 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 zwischen SDK und App motiviert ein anderes Trennkonzept: eine für SDK und App-Bereitstellung. Unser Vorschlag erfordert eine vertrauenswürdige Vertriebsvereinbarung und Installationsmechanismus, um sicherzustellen, dass die richtigen SDKs in einem SDK-Laufzeit der App festlegen. 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 bevor sie zum Vertrieb in einen App-Shop hochgeladen werden. Stattdessen würde Folgendes passieren:

SDK-Entwickler könnten ihre versionierten SDKs in die App-Shops hochladen, direkt aus den Apps heraus.
App-Entwickler können ihre SDK-Abhängigkeiten angeben, indem sie Version erstellen, erstellen und hochladen, der das eigentliche SDK nicht enthält Abhängigkeiten.
Wenn ein Nutzer diese App herunterlädt, kann der Installationsvorgang folgende Informationen enthalten: und laden sie aus dem App-Shop herunter.

Mit diesem neuartigen Vertriebsmechanismus können SDK-Entwickler abwärtskompatible Änderungen (d. h. keine Änderungen an APIs oder ihrer Semantik) an ihren SDKs und der Bereitstellung auf Geräten ohne Einbindung von App-Entwicklern. 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:

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

Nach dem Diagramm — Nach der Einführung der SDK Runtime d, das SDK Entwickler verwenden eine UI für den SDK-Upload, um ihre SDKs in einem App-Shop zu 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 -Bereitstellung Technologie. 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: Erstellen, Debuggen und Testen in dieses Modell
Bereitstellung: Informationen zum Bereitstellen, Aktualisieren und Zurückrollen von Android-Versionen, Apps und SDKs

Dieses Dokument enthält auch FAQs zu häufig gestellten Fragen.

Dies ist ein erster Designvorschlag, der für Sie für einige Mitglieder des Ökosystems. Aus diesem Grund bitten wir aktiv Ihr Feedback und bitten Sie Sie, uns dies über die Tracker.

Zugriff

Für den Datenschutz in einem System ist es wichtig zu bestimmen, wie verschiedene Parteien auf verschiedene Ressourcen zugreifen. 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 einen eigenen, klar definierten Satz an Berechtigungen zu erhalten, anstatt diejenigen zu übernehmen, die der Nutzer der App erteilt hat. Basierend auf ersten Untersuchungen zu den Berechtigungen für Anzeigen-SDKs gezeigt haben, Es wird vorgeschlagen, dass die folgenden Berechtigungen für SDKs im SDK zugänglich wären Standardmäßig Laufzeit:

INTERNET: Zugriff auf das Internet, um mit einem Webdienst kommunizieren zu können.
ACCESS_NETWORK_STATE: Auf Informationen zu Netzwerken zugreifen
READ_BASIC_PHONE_STATE: Hier können Sie auf Informationen zum Telefonstatus zugreifen, z. B. den Typ des Mobilfunknetzes.
Berechtigungen für den Zugriff auf die datenschutzfreundlichen APIs, die grundlegende ohne Zugriff auf App-übergreifende Kennungen.
AD_ID: Berechtigung, 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 und die Auswirkungen auf Endnutzerinnen und -nutzer in Bezug auf Datenschutz und Usability-Perspektive. Mi. Feedback anfordern zu Anwendungsfällen, die von diesen Berechtigungen nicht erfüllt sind.

Speicher

Die SDK-Laufzeit hat aufgrund ihres eigenen Prozesses einen eigenen isolierten Arbeitsspeicher. Diese Struktur würde die SDK-Zugriff auf den App-Arbeitsspeicher. Die App würde dies ebenfalls nicht tun. auf den Arbeitsspeicher des SDKs zugreifen können. Wir schlagen vor, diese Standardeinstellung beizubehalten um mit dem Prinzip der geringsten Berechtigung im Einklang zu stehen.

Speicher

Mit diesem Vorschlag sollen SDKs ausgleichen, die nicht mehr auf den Speicher zugreifen müssen, und das App- und prozessübergreifende Tracking auf ein Minimum reduzieren. nichtflüchtigem Speicher. Wir schlagen folgende Änderungen am aktuellen Zugriff auf den Speicher vor:

Eine App kann nicht direkt auf den Speicher des SDKs zugreifen und umgekehrt.
SDKs können nicht auf den externen Speicher des Geräts zugreifen.
Innerhalb jeder SDK-Laufzeit gäbe es Zugriff auf Speicher für alle SDKs und Speicher, der für ein bestimmtes SDK privat bleibt.

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 der ART und der Sprache, die sie bietet, in Kombination mit der Verlässlichkeit, die sie bietet im Vergleich zu Alternativen, insbesondere nativem Code, scheint es angemessen zu sein, Funktionalität und Datenschutz in Einklang bringen. Wir schlagen vor, dass laufzeitfähiger SDK-Code bestehen ausschließlich aus Dex-Bytecode und unterstützen nicht den JNI-Zugriff.

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 systemeigenen App für die SDK-Laufzeit vor:

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

APIs

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

Darüber hinaus haben neue Android-Plattformversionen Zugriff auf dauerhafte IDs, um den Datenschutz zu verbessern. Für das SDK Laufzeit: Wir schlagen vor, den Zugriff auf Kennungen, die verwendet werden könnten, weiter einzuschränken. für das App-übergreifende Tracking.

Auf SDK-Laufzeit-APIs kann nur über Apps zugegriffen werden, die im Vordergrund ausgeführt werden. Es wird versucht, über Apps auf SdkSandboxManager APIs zuzugreifen im Hintergrund führt zu einer SecurityException wird geworfen.

RE-SDKs können außerdem keine Benachrichtigungs-APIs verwenden, um Nutzerbenachrichtigungen an jederzeit ändern.

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. SDK-Laufzeit wird unmittelbar danach automatisch beendet.
Die SDK-Laufzeit kann beispielsweise aufgrund von Speichermangel oder einer nicht behandelten Ausnahme in einem SDK vom Betriebssystem beendet werden.

Wenn unter Android 13 eine App im Vordergrund ausgeführt wird, wird die SDK Runtime in einer hat eine hohe Priorität und wird wahrscheinlich nicht gekündigt. 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.

Für den Fall, dass die SDK-Laufzeit beendet wird, während die App aktiv ist – für Beispiel: Im SDK gibt es eine unbehandelte Ausnahme – die SDK-Laufzeit geht verloren, einschließlich aller zuvor geladenen SDKs und Remoteansichten. Die können App-Entwickler bei der Beendigung der SDK-Laufzeit folgenden Methoden:
- Das Angebot bietet App-Entwicklern zugehörige Lebenszyklus-Callback-Methoden. um zu erkennen, wann die SDK-Laufzeit beendet wurde.
- Wenn die SDK-Laufzeit beendet wird, während Anzeigen eingeblendet werden, werden Anzeigen möglicherweise nicht wie erwartet funktioniert. So können Ansichten beispielsweise auf dem Bildschirm eingefroren sein und nicht mehr interaktiv sein. Die App kann die Anzeigenansicht entfernen, wenn dies keine Auswirkungen hat. User Experience aus.
- In der App wird unter Umständen noch einmal versucht, 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 beendet und beendet.
- Binder-Objekte, die vom SDK zurückgegeben werden, um mit ihm zu kommunizieren (z. B. SandboxedSdk) löst eine DeadObjectException aus, wenn sie von der App verwendet wird.
Dieses Lebenszyklusmodell kann sich in zukünftigen Updates ändern.

Bei anhaltenden Fehlern sollte der App-Entwickler Graceful Degradation ohne SDK oder Benachrichtigung des Nutzers, falls das SDK für die Hauptfunktion der App. Weitere Informationen App-zu-SDK-Interaktion finden Sie im Abschnitt zur Kommunikation unter in diesem Dokument.

Nicht-RE-SDKs können weiterhin die Standard-Primitive des Betriebssystems nutzen, eingebettete Apps – einschließlich Diensten, Aktivitäten und Broadcasts –, während RE SDKs nicht.

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. Gemeinsame UIDs werden möglicherweise in Zukunft unterstützt.
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. Dafür schlagen wir einen Remote-Rendering-Ansatz vor, das SDK die Medien innerhalb der SDK Runtime rendert, aber die Methode SurfaceControlViewHost-API , damit die Medien in einer App-spezifischen Ansicht gerendert werden können. Hier finden Sie das SDK die Möglichkeit, dieses Medium auf eine Weise zu rendern, die für den Nutzer privat ist, und helfen dabei, ungültige oder betrügerische Interaktionen mit das gerenderte Medium ist.

Bei nativen Anzeigen, die nicht vom SDK, sondern von der App gerendert werden, von SDKs in der SDK Runtime unterstützt werden. 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 nicht in einem Player oder einer Ansicht im SDK, sondern in einem Player in der App wiedergegeben wird, unterscheidet sich das Rendering-Modell von anderen Anzeigenformaten. Wir prüfen derzeit Mechanismen zur Unterstützung von serverseitigen Anzeigen und SDK-basierte Anzeigenbereitstellung.

Systemzustand

Wir möchten die Auswirkungen der SDK-Laufzeit auf den Systemzustand minimieren. Geräte und entwickeln Wege dafür. Höchstwahrscheinlich sind aber auch Anfänger Android 13-Geräte mit sehr begrenzten Systemressourcen wie Android (Go-Edition) wird die SDK-Laufzeit aufgrund der Auswirkungen auf den Systemzustand nicht unterstützt. Wir werden bald die Mindestanforderungen für die erfolgreiche Verwendung der SDK-Laufzeit enthalten.

Kommunikation

Da Apps und SDKs derzeit im selben Prozess ausgeführt werden, ist die Kommunikation zwischen ihnen ungehindert und nicht vermittelt. Außerdem können Apps auch wenn die Kommunikation mit SDKs beginnt und endet. Dieses ein flüssiges Kommunikationsmodell ermöglicht verschiedene Anwendungsfälle damit Daten zwischen Apps und anderen nicht offengelegt werden, zwischen SDKs in 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. Unser Vorschlag ermöglicht es SDKs, APIs und dafür zu sorgen, dass Apps von all diesen Innovationen profitieren können.

Angesichts der Prozessgrenzenstruktur der SDK Runtime schlagen wir vor, Erstellen einer in der App zugänglichen Marshalling-Ebene für die API-Aufrufe Antworten oder Callbacks über diese Grenze zwischen App und SDK hinweg. 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 die Standard-Marshaling-Arbeiten aus der App entfernen. und SDK-Entwicklern. Gleichzeitig bieten sie Flexibilität für SDK-Entwickler und dass SDK-Code in der SDK-Laufzeit ausgeführt wird, um unsere datenschutzbezogenen Ziele zu erreichen. Sollten wir müssen die API-Definitionssprache und die Tools Design mit Ihren Eingaben.

Das allgemeine Interaktionsmodell sähe so aus:

Die App ruft das SDK über die Benutzeroberfläche auf und gibt Callbacks ein.
Das SDK beantwortet die Anfragen asynchron und antwortet mithilfe der Rückrufe.
Das lässt sich für jedes Publisher-Abonnentenmodell verallgemeinern, Ereignisse im SDK mit Callbacks abonnieren. Wenn diese Ereignisse eintreten, werden die Callbacks ausgelöst.

Eine Folge der neuen prozessübergreifenden Struktur dieses Angebots ist, dass zwei Prozesslebenszyklen, die verwaltet werden müssen: einer für die App und das andere 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. Die Das folgende Diagramm zeigt einen Ansatz, den wir in Betracht ziehen:

Die Plattform würde neue APIs für Anwendungen zur Verfügung stellen, um SDKs dynamisch in den SDK-Laufzeitprozess, Sie werden über Änderungen am Prozessstatus informiert, und mit SDKs interagieren, die in die SDK Runtime geladen sind.

Das Diagramm in der vorherigen Abbildung zeigt die App-zu-SDK-Kommunikation an einem ohne die Marshalling-Ebene.

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

Bevor eine App mit einem SDK interagieren kann, fordert die App an, dass das über die Plattform geladen werden. Um die Integrität des Systems zu gewährleisten, enthalten Apps die SDKs, die sie laden möchten, in ihrer Manifest-Datei. Diese SDKs sind die 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)
```
Das SDK wird benachrichtigt, dass es geladen wurde, und gibt seine Benutzeroberfläche zurück. Diese Schnittstelle soll vom App-Prozess verwendet werden. Benutzeroberfläche freigeben Außerhalb der Prozessgrenze muss er als IBinder-Objekt zurückgegeben werden.

Im Leitfaden zu gebundenen 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.
SdkSandboxManager empfängt die IBinder-Schnittstelle und gibt sie an in der App.

Die App ruft die IBinder ab und wandelt sie in die SDK-Schnittstelle um. Dabei wird ihre Funktionen:

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:

Wie im Abschnitt zum Medien-Rendering dieser Anleitung erläutert, Damit eine App ein SDK zum Rendern von Medien in einer Ansicht erhält, muss die App könnte requestSurfacePackage() aufrufen und die entsprechenden SurfaceControlViewHost.SurfacePackage.

Das folgende Code-Snippet zeigt ein API-Beispiel:
```
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
        Executor executor,
        OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
```
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)
```

Unser Vorschlag sieht vor, dass die APIs IBinder und requestSurfacePackage() die 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 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 die SDK Runtime mit allen ihren Schutzmaßnahmen. SDKs können nicht als wie sie heute in einer App funktionieren. Folglich kann eine API in SdkSandboxController wurde hinzugefügt, um das Abrufen zu ermöglichen SandboxedSdk-Objekte für alle geladenen RE-SDKs. So 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 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.
- Nicht laufzeitfähige Anzeigen-SDKs können sich möglicherweise nicht selbst registrieren. empfehlen wir die Erstellung eines Vermittler-SDKs, das alle Partner oder Apps SDKs als direkte Abhängigkeiten der App und übernimmt die Registrierung. 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 aktuellen Version Entwicklervorschau)
SDK-SDK-Kommunikation zwischen der App und der SDK-Laufzeit (verfügbar in der neueste Entwicklervorschau)
Wie Datenansichten und Remote-Rendering für die Vermittlung funktionieren sollten (Angebot in Entwicklung)

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

Vermittlung und Gebote: 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. 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 ist in diesem Kontext ein aktives Untersuchungsgebiet.
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 Erkennungsprimitive die diesen Anwendungsfall ermöglichen.
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 obigen Primitive sollten diese Verwendung unterstützen Fall.

App-zu-App

Bei der App-zu-App-Kommunikation wird mindestens einer der beiden Prozesse Kommunikation ist ein laufzeitfähiges SDK und ein potenzieller Vektor für nicht offengelegte Datenweitergabe. 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>.
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 mit Einschränkungen was im Intent gesendet werden kann. Zum Beispiel dürfen keine Extras oder benutzerdefinierten Aktionen diesem Intent hinzugefügt werden.
Das SDK kann nur eine Zulassungsliste mit Diensten starten oder eine Bindung an eine solche Liste vornehmen.
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 mit ContentResolver.
Das SDK kann nur auf eine Untergruppe von Protected Broadcast Receivern zugreifen, z. B. als 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 kann beispielsweise Sie dürfen keine Komponenten wie <service>, <activity>, <provider> oder <receiver> definieren. und darf im Manifest kein <permission> deklarieren. Tags, die nicht installiert werden können, werden in der SDK-Laufzeit nicht unterstützt. Tags, die nicht fehlschlagen werden, die bei der Installation aber unbemerkt ignoriert werden, in zukünftigen Android-Versionen Versionen.

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ützte Aktivitäten

SDKs in der SDK-Laufzeitumgebung können ihrem Manifest kein Aktivitäts-Tag hinzufügen Datei und können keine eigenen Aktivitäten mit Context.startActivity starten. Stattdessen erstellt die Plattform auf Anfrage die Aktivitäten für die SDKs und an SDKs weitergegeben.

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.

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.

In der folgenden Grafik sehen Sie, wie eine Aktivität angefordert wird.

Entwicklung

Ein Hauptprinzip dieses Vorschlags besteht darin, die Auswirkungen auf die Entwickelnden zu minimieren. soweit dies möglich ist. Dieses Angebot umfasst Entwickler:innen eine umfassende Auswahl an Entwicklertools zum Schreiben, Erstellen und Debuggen von REM 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.

In der Erstellung

Android Studio und die zugehörigen Tools werden auf SDK Runtime-sensitive, dass Entwickler ihre RE-Apps richtig konfiguriert und und dafür zu sorgen, dass alte oder nicht unterstützte Aufrufe auf neuere gegebenenfalls Alternativen. Während der Erstellungsphase werden einige Schritte dass unser Vorschlag von Entwickelnden durchgeführt werden müsste.

App-Entwickler

Apps müssen ihr RE SDK und ihr SDK-Zertifikat angeben. im App-Manifest der Abhängigkeiten. In unserem Vorschlag behandeln wir dies als Quelle vom Anwendungsentwickler geben. Beispiel:

Name:Paketname des SDKs oder der Bibliothek.
Hauptversion: Hauptversionscode des SDKs.
Zertifikats-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 den App-Shop vertriebene SDKs, unabhängig davon, ob RE oder nicht. Für Apps, die SDKs statisch verknüpfen, würden aktuelle Abhängigkeitsmechanismen verwendet.

Da wir die Auswirkungen auf Entwickler möglichst gering halten wollen, ist es wichtig, Das Ziel-API-Level, das die SDK-Laufzeit unterstützt, ist angegeben, nur App-Entwickler brauchen nur einen Build, ob auf Geräten, unterstützen die SDK-Laufzeit nicht.

SDK-Entwickler

In unserem Designvorschlag müssen RE SDK-Entwickler explizit Im Manifest wird ein neues Element deklariert, das für das SDK oder die Bibliotheksentität steht. Darüber hinaus müsste ein ähnlicher Satz von Werten wie die Abhängigkeit sein. sowie eine Nebenversion zur Verfügung gestellt:

Name: Paketname des SDK oder der Bibliothek.
Hauptversion:Hauptversionscode des SDK.
Nebenversion:Code der Nebenversion 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 möchten wahrscheinlich weiterhin Support für nicht RE-aktivierte wie Android 12 oder niedriger und, wie im Artikel Systemzustand des Dokuments, Android 13-Einstiegsgeräte mit begrenzte Systemressourcen. Wir arbeiten an verschiedenen Ansätzen, Entwickelnde können eine einzige Codebasis beibehalten, um RE- und Nicht-RE-Umgebungen zu unterstützen.

Builds

App-Entwickler

Wir gehen davon aus, dass sich bei App-Entwicklern das Erstellen eines Build-Schritts. SDK-Abhängigkeiten, unabhängig davon, ob sie lokal oder über den App-Shop verteilt werden (RE oder nicht), müssen auf dem Computer für das Linting, die Kompilierung und die Builds vorhanden sein. 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 hier bereits in der Designphase und werden immer mehr zu diesem Thema mit Ihnen teilen.

SDK-Entwickler

Wir arbeiten an einem Weg, um sicherzustellen, dass Nicht-RE- und RE-Versionen eines SDK zur Verteilung in ein einzelnes Artefakt integriert werden. 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 Abhängigkeits-SDKs, die über den App-Shop verteilt werden, für Linting, Kompilierung und Builds auf der Maschine bestehen. Wir erwarten, dass Android Studio sollte dies problemlos ermöglichen.

Test

App-Entwickler

Wie in unserem Vorschlag beschrieben, können App-Entwickler ihre Apps wie gewohnt auf Geräten mit Android 13 testen. Nachdem sie könnte sie auf einem RE-Gerät oder Emulator installiert werden. Durch diesen Installationsvorgang wird sichergestellt, dass die richtigen SDKs im SDK-Laufzeit für das Gerät oder den Emulator, unabhängig davon, ob die SDKs von einem Remote SDK-Repository oder -Cache vom Build-System.

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 und Für die In-App-Validierung gelten dieselben Schritte wie für App-Entwickler beschrieben. mit einem einzelnen Build-Artefakt für RE- und Nicht-RE-Anwendungen. SDK können Entwickler ihren Code durchgehen – unabhängig davon, ob er sich im SDK befindet. Laufzeit oder nicht, auch wenn erweiterte Fehlerbehebung und Tools zur Profilerstellung. Dieser Bereich wird derzeit intensiv erforscht.

Vertrieb

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

Die Qualität und Konsistenz der SDKs müssen gewährleistet sein.
Die Veröffentlichung für SDK-Entwickler wird optimiert.
Beschleunigen Sie die Einführung von SDK-Nebenversionsupdates 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. Verhalten die mit einem bestimmten targetSdkVersion verknüpft sind, wird so lange aufbewahrt, bis dies unterstützt wird. targetSdkVersion wurde aufgrund einer App-Shop-Richtlinie eingestellt und targetSdkVersion wird möglicherweise schneller eingestellt als 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 erhalten wir Feedback und können die vorgeschlagenen Änderungen an den Einschränkungen besser beurteilen.

FAQ

Was ist ein werbebezogenes SDK?

Ein anzeigenbezogenes SDK erleichtert das Targeting von Nutzer mit Nachrichten zu kommerziellen Zwecken in Apps, die nicht Eigentum des Werbetreibenden. 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.
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 nicht kompatibel mit der mit allen SDK-Designs. Über die dokumentierten Einschränkungen hinaus Die Laufzeit ist wahrscheinlich ungeeignet für SDKs, die Echtzeit oder einen hohen Durchsatz benötigen Kommunikation mit der Hosting-App.
Warum sollten Sie sich für die Prozess-Isolierung statt der Isolierung innerhalb eines Prozesses entscheiden? Java-basierte Laufzeit?

Derzeit vereinfacht die Java-basierte Laufzeit nicht ohne Weiteres die Sicherheit für die Datenschutzbestimmungen, die für Android erwünscht sind. Nutzenden. 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.
Würde das Verschieben von SDKs in den SDK-Laufzeitprozess eine Downloadgröße oder Speicherplatzersparnis?

Wenn mehrere Apps mit runtimefähigen SDKs derselben Version integriert sind, kann dies die Downloadgröße und den Speicherplatz verringern.
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 einem Entwicklervorschau verfügbar.

Persönliche Empfehlungen

Hinweis: Der Linktext wird angezeigt, wenn JavaScript deaktiviert ist.
Entwicklerleitfaden für die SDK-Laufzeit