Diese Seite wurde von der Cloud Translation API übersetzt.

SDK-Laufzeit – Übersicht

Bei der Android-Plattform wird App-Sandbox, damit Ihre App Robuste Ausführungs- und Sicherheitsgrenzen für Anwendungscode entlang von Prozessgrenzen. Es ist üblich, dass Apps Drittanbietercode enthalten, 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. Darüber hinaus dürfen App-Entwickler Sie müssen sich über den Umfang der Funktionen von Drittanbieter-SDKs und die auf die Daten zugegriffen werden kann. Dadurch ist es schwierig, ihrer App zu teilen.

Android 13 ist mit einer neuen Plattformfunktion ausgestattet, die es SDKs, die in einer dedizierten Laufzeitumgebung namens SDK Runtime ausgeführt werden. Die SDK Runtime bietet die folgenden strengeren Absicherungen und Zusicherungen rund um Erhebung und Weitergabe von Nutzerdaten:

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

Wir sind aktiv um Feedback von der Community für App-Werbung in diesem Design. Wir freuen uns auch über Feedback von der Entwickler-Community, die Entwicklung zukünftiger Iterationen der SDK Runtime unterstützen, weitere 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 zu den vorgeschlagenen Vertrauenswürdige SDK-Distribution in einem anderen Abschnitt in diesem Dokument.
App-Entwicklern dabei helfen, den Datenzugriff und die Datenweitergabe besser zu berücksichtigen ihrer App.
Unterstützen Sie SDK-Entwickler dabei, die Manipulation durch andere SDKs durch die Bestimmte unsichere Sprachkonstrukte wie JNI-Code
Anzeigen-SDKs unterstützen, ungültige Zugriffe und Werbebetrug vollständig zu erkennen und zu verhindern die Steuerung der Remote-Ansichten für Medien.
Minimieren Sie die unnötigen Auswirkungen auf App- und SDK-Entwickler so weit wie möglich.

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 zeigen diese Änderungen:

Diagramm „Vorher“, das alle Ausführungen des Anwendungsprozesses zeigt — Bevor der SDK-Aufrufcode zur SDK Runtime hinzugefügt wird, zusammen mit den SDKs, die die Aufrufe von befinden sich alle im Prozess der App.

. <ph type="x-smartling-placeholder">

Diagramm, das Prozesse zeigt, die zwischen App- und SDK-Laufzeitprozess aufgeteilt sind — Nachdem der SDK-Aufrufcode zur SDK-Laufzeit hinzugefügt wurde, im Vordergrundprozess der App, kommuniziert der SDK-Aufrufcode SDK-Schnittstellen Diese Schnittstellen überschreiten dann eine Prozessgrenze in die SDK-Laufzeitprozess zum Aufrufen der SDKs selbst.

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 ungültigen Es werden SDKs geladen, während App-Stores den Aufwand erheblich reduzieren können. SDK-Vertrieb von App-Entwicklern.

SDKs müssen nicht mehr statisch verknüpft und mit bevor sie zum Vertrieb in einen App-Shop hochgeladen werden. Die folgenden würde stattdessen wie folgt aussehen:

SDK-Entwickler konnten ihre versionierten SDKs separat 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 abwärtskompatiblen SDK-Änderungen können bereitgestellt oder zurückgesetzt werden, ohne müssen nicht unbedingt warten, bis App-Entwickler ihre Apps mit den neue SDKs zu erstellen oder darauf zu warten, dass Endnutzer ihre Apps aktualisieren. Nicht abwärtskompatible Änderungen müssen noch von App-Entwicklern aktualisiert werden, aber SDK-Entwickler könnten nicht funktionsgefährdende Änderungen schneller und einheitlicher beseitigt, und im Idealfall weniger Versionsunterstützung.

Die folgenden Diagramme veranschaulichen die vorgeschlagenen Änderungen an der SDK-Distribution:

Vor dem Diagramm — Vor der Einführung der SDK Runtime ihre SDKs direkt in Apps übertragen.

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 übernimmt dann den Vertrieb der Apps und das SDK. bis hin zu Endnutzergeräten.

Änderungen beim Erstellen, Ausführen und Verteilen von SDKs und Apps

Dies ist ein erster Vorschlag für eine flexible SDK-Laufzeit und -Bereitstellung Technologie. In den folgenden Abschnitten wird eine Reihe von Änderungen im folgenden allgemeinen Kategorien:

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
Verbreitung: Bereitstellung, Aktualisierung, Rollback für Versionen von Android, Apps und SDKs durchführen

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 unser Angebot zum Datenschutz zu erfüllen, schlagen wir vor, Aktualisierung des Modells für den Zugriff auf Apps, SDKs und Nutzerdaten, um den Prinzip der geringsten Berechtigung, um den nicht offengelegten Zugriff potenziell sensible Daten.

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 die auf diese Berechtigung zugreifen.

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 hätte ihren eigenen isolierten Arbeitsspeicher da sie ihren eigenen Prozess hat. 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 Änderung bei der Speichernutzung vor Zugriff heute:

Eine App kann nicht direkt auf ihren SDKs-Speicher 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 Beschränkungen. nicht so groß sein. SDKs können Speicher für das Caching von Assets verwenden. Dieser Speicher 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 schaffen, selbst (Codeformate, Sprachkonstrukte, zugängliche APIs und Systemdaten) diese Datenschutzgrenzen zu verstärken oder zumindest keine um sie zu umgehen. Gleichzeitig möchten wir den Zugang der umfangreichen Plattform und den meisten Laufzeitfunktionen, die SDKs nutzen, aktuell haben. Hier schlagen wir eine Reihe von Aktualisierungen für die Laufzeitumgebung vor, ein ausgewogenes Verhältnis zu erreichen.

Code

Android-Code (Apps und SDKs) wird hauptsächlich von der Android Runtime interpretiert (ART), 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, wie etwa die Verwendung von SQLite, das aufgrund der Verwendung von nativem Code durch ein wie die im Android SDK integrierte SQLite-Version.

SELinux

Unter Android wird jeder Prozess (auch solche, die als Root ausgeführt werden) mit einem bestimmten SELinux-Kontext, der es dem Kernel ermöglicht, die Zugriffssteuerung auf das System zu verwalten Dienste, Dateien, Geräten und anderen Prozessen. Wenn wir versuchen, der meisten SDK-Anwendungsfälle unter Berücksichtigung der Umgehung des Datenschutzes zu schützen, schlagen wir Folgendes vor: Updates aus dem SELinux-Kontext einer Nicht-System-App für die SDK-Laufzeit:

Es wäre eine begrenzte Anzahl von Systemdiensten zugänglich. (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 Reflexions- und Aufruf-APIs innerhalb der SDK-Laufzeit ist zulässig. Ein SDK darf jedoch keine Reflexion verwenden oder APIs auf einem anderen laufzeitfähiges SDK. Wir werden in einem für zukünftige Updates.

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.

SDK Runtime APIs sind nur über Apps zugänglich, die im Vordergrund ausgeführt werden. Es wird versucht, über Apps auf SdkSandboxManager APIs zuzugreifen im Hintergrund führt zu einer SecurityException wird geworfen.

Außerdem können RE-SDKs die Notifications APIs nicht verwenden, um Nutzerbenachrichtigungen an jederzeit ändern.

Lifecycle

App-SDKs folgen derzeit dem Lebenszyklus ihrer Host-App. den Vordergrund betritt oder verlässt, sich abschaltet oder durch den des Betriebssystems aufgrund von Speicherauslastung reagieren können, tun dies auch die SDKs der App. Unsere die Aufteilung der SDKs einer App in separate Prozesse impliziert, folgenden Lebenszyklusänderungen:

Die App kann vom Nutzer oder vom Betriebssystem beendet werden. SDK-Laufzeit wird unmittelbar danach automatisch beendet.
Die SDK-Laufzeit kann aufgrund von Arbeitsspeicher vom Betriebssystem beendet werden oder eine unbehandelte Ausnahme in einem SDK.

Wenn bei 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 die im Hintergrund ab, sinkt die Priorität des SDK-Laufzeitprozesses gekündigt werden kann. Die Priorität des SDK-Laufzeitprozesses bleibt selbst wenn die App wieder in den Vordergrund wechselt. Daher ist es sehr wichtig, dass sie unter Speicherauslastung beendet wird,

Bei Android 14 und höher: die Prozessprioritäten der App und des SDKs Laufzeiten übereinstimmen. Prozessprioritäten für ActivityManager.RunningAppProcessInfo.importance für die App und den Die SDK-Laufzeit sollte 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. Beispielsweise können Aufrufe auf dem Bildschirm eingefroren und noch interaktiver gestalten. 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 wenn der App-Entwickler den oben genannten Lebenszyklus -Rückrufmethoden, 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 haben, funktioniert die SDK Runtime möglicherweise nicht ordnungsgemäß funktioniert. Möglicherweise werden in Zukunft auch freigegebene UIDs unterstützt.
Bei Apps mit mehreren Prozessen sollte das SDK im Hauptprozess geladen werden. .

Medienrendering

Es gibt SDKs, die Inhalte wie Text, Bilder und Videos in einem die in der App angegebene Ansicht enthält. 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. 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. Signalerfassung und Creative würde bei nicht nativen Anzeigen ständig passieren. Dies ist ein aktiven Untersuchungsbereich.

In-Stream-Videoanzeigen werden zusammen mit einem Video geschaltet und erscheinen in einem Player. in einer App. Da das Video in einem Player der App abgespielt wird, als ein Player oder eine Wiedergabe im SDK, unterscheidet sich das Rendering-Modell von anderen Anzeigen. Formaten. 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 ungehemmt und unvermittelt. 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 haben einige Änderungen für dieses Kommunikationsmodells einsetzen, das darauf abzielt, ein Gleichgewicht zwischen dem Wert eines solchen Kommunikation und die Umsetzung unserer Ziele.

App-to-SDK

Die Schnittstelle zwischen der App und dem SDK ist der gängigste Kommunikationspfad. und bei der API eines SDKs wird ein Großteil der nutzerseitigen Unterscheidung und Innovation angesiedelt sind. Wir bemühen uns, die Innovationsfähigkeit und unterscheiden können. 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 sind Es wird vorgeschlagen, dass die Schnittstelle zu dieser Marshalling-Ebene vom SDK definiert wird. und mit offiziellen Open-Source-Build-Tools generiert, zu entwickeln.

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 -Schnittstelle auf und gibt Rückrufe weiter.
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. Unser Vorschlag zielt darauf ab, möglichst wenig zu tun und 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 Schritten:

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 Schnittstelle zurück. Diese Oberfläche ist für die Nutzung durch den App-Prozess vorgesehen. Benutzeroberfläche freigeben Außerhalb der Prozessgrenze muss er als IBinder-Objekt zurückgegeben werden.

Der Leitfaden zu gebundenen Diensten bietet verschiedene Möglichkeiten, IBinder bereitzustellen. Unabhängig von der gewählten Methode müssen das SDK und die Anrufer-App. 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();

In der App können auch Medien über das SDK gerendert werden. Gehen Sie 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 könnte dann das zurückgegebene SurfacePackage in die SurfaceView einbetten. über die setChildSurfacePackage API in SurfaceView.

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 API-Funktionen über die oben beschriebene generierte API-Referenz in einem "Shim" um App-Entwickler zu entlasten.

SDK-zu-SDK

Zwei SDKs in derselben App müssen oft miteinander kommunizieren. Dies kann passieren, wenn eine bestimmte SDK besteht aus einzelnen SDKs und kann verwendet werden, SDKs verschiedener Parteien müssen zusammenarbeiten, um einer Anfrage der Anruf-App.

Dabei sind zwei wichtige Fälle zu berücksichtigen:

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. Dadurch kann ein RE-SDK mit anderen in der SDK Runtime geladenen SDKs zu kommunizieren.
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 dieses Angebot empfiehlt, eine Methode mit der in der App zu SDK beschriebenen IBinder bereitzustellen Abschnitt, den der Code in der App überwacht, verarbeitet und mit Callbacks angegeben.
- 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 andere App-Abhängigkeiten und der laufzeitfähige Vermittler, der als Adapter.

Die Funktionen für die SDK-SDK-Kommunikation wurden folgendermaßen aufgeteilt: Kategorien:

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)

Die folgenden Anwendungsfälle werden berücksichtigt, da die Primitiven Design:

Vermittlung und Gebote: Viele Werbe-SDKs bieten Vermittlung oder Bidding Funktion, bei der das SDK verschiedene andere SDKs für eine Anzeigenimpression aufruft (Vermittlung) oder zum Erfassen von Signalen zur Durchführung einer Auktion (Gebote). Normalerweise ruft das koordinierende SDK andere SDKs über einen Adapter auf, der vom koordinierenden SDK. Angesichts der oben aufgeführten Primitiven kann das koordinierende SDK, RE oder nicht, sollten für den normalen Betrieb auf alle RE und Nicht-RE SDKs zugreifen können. Das Rendering ist in diesem Kontext ein aktives Untersuchungsgebiet.
Funktionen entdecken Einige SDK-Produkte bestehen aus kleineren SDKs, Durch Erkennung zwischen SDKs können Sie die ultimativen Funktionen bestimmen. die dem App-Entwickler angezeigt wird. Registrierungs- und Erkennungsprimitive die diesen Anwendungsfall ermöglichen.
Abomodelle für Verlage und Webpublisher Einige SDKs haben eine zentrale Publisher von Ereignissen, die andere SDKs oder Apps abonnieren können Benachrichtigungen über Rückrufe. 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-Laufzeit keine direkten Kommunikationskanal mit einer anderen App als der Clientanwendung oder mit SDKs in einer anderen SDK-Laufzeit, die für eine andere App erstellt wurde. Dies ist auf folgende Weise erreicht:

Das SDK kann keine Komponenten wie <service>, <contentprovider> oder <activity>.
Das SDK kann keine ContentProvider veröffentlichen oder einen Broadcast 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 zugreifen. ContentProvider (z. B. com.android.providers.settings.SettingsProvider), sofern Daten enthalten keine Kennungen und können nicht zur Erstellung eines Fingerabdrucks des Nutzers verwendet werden. 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 ist, parst PackageManager das Manifest des SDK und schlägt fehl um das SDK zu installieren, falls gesperrte 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. Fehlerhafte Tags 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 Build-Zeit-Tools angewendet werden, die das SDK verwendet, um beim Erstellen des SDK-Bundles 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. 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, muss es eine Instanz des Typs SdkSandboxActivityHandler, die verwendet wird, um über das Erstellen von Aktivitäten benachrichtigt zu werden, wenn ruft die App SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) auf, um beginnen Sie mit der Aktivität.

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

Entwicklung

Ein Hauptprinzip dieses Vorschlags ist die Minimierung der Auswirkungen auf die Entwickelnden soweit dies möglich ist. Dieses Angebot umfasst Entwicklern ein umfassendes Angebot an Entwicklertools zum Schreiben, Erstellen und Debuggen von Apps und SDKs. Um die Integrität dieses Angebots sicherzustellen, einige Änderungen an der Konfiguration, Entwicklung 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 unserer Lösung die Entwickelnden vor.

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 SDK.
Zertifikats-Digest:Der Zertifikat-Digest des SDK-Builds. Für eine bestimmte erstellt haben, schlagen wir vor, dass der SDK-Entwickler diesen Wert über die App-Shops relevant sind.

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 SDKs oder der Bibliothek.
Hauptversion:Hauptversionscode des SDK.
Nebenversion:Code der Nebenversion des SDKs.

Sollten RE SDK-Entwickler andere RE SDKs als Abhängigkeiten bei der Erstellung nutzen, Sie müssen sie in der Regel genauso deklarieren, wie ein App-Entwickler die gleiche Abhängigkeit deklarieren. RE-SDKs, die von Nicht-RE-SDKs abhängig sind, statisch zu verknüpfen. Dies kann zu Problemen führen, die während oder bei Testdurchläufen, wenn die Nicht-RE-SDKs Funktionen benötigen, SDK Runtime wird nicht unterstützt oder muss während des App-Prozesses ausgeführt werden.

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, das für Einsteigergeräte mit Android 13 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, ob lokal verteilt oder in Apps für das Linting auf der Maschine bereits im Store-Vertrieb (RE oder nicht) Kompilierung und Builds. Wir schlagen vor, dass Android Studio diese vom App-Entwickler bei normaler Nutzung erhalten und diese Informationen transparent machen. wie möglich.

Wir gehen zwar davon aus, dass eine DEBUG-Build-Funktion den gesamten Code und alle Symbole im DEBUG-Build enthalten sein müssen, um die Fehlersuche zu erleichtern, alle über den App-Shop vertriebenen SDKs (RE oder nicht) aus dem des finalen Artefakts.

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. Dies würde verhindern, dass App-Entwickler separate Builds für RE und Nicht-RE-Versionen eines SDKs.

Ä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 wie gewohnt auf Geräten mit Android 13. 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. Dies ist ein aktives Untersuchungsgebiet.

Vertrieb

Unser Entwurf zur Trennung einer App von ihren SDKs hat die Möglichkeit für die Bereitstellung von SDKs im App-Shop. Das ist eine allgemeine Möglichkeit, nicht eindeutig für einen bestimmten App-Shop sind. Die Vorteile liegen auf der Hand:

Die Qualität und Konsistenz der SDKs müssen gewährleistet sein.
Optimieren Sie die Veröffentlichung für SDK-Entwickler.
Beschleunigen Sie die Einführung von SDK-Nebenversionsupdates für installierte Apps.

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

Ein Mechanismus, mit dem SDK-Entwickler ihre über den App-Shop vertriebenen SDKs hochladen können in den Store hochladen, aktualisieren, Rollback durchführen und sie möglicherweise entfernen.
Einen Mechanismus zur Sicherstellung der Integrität eines SDKs und seiner Herkunft sowie einer App und deren Herkunft und Auflösung ihrer Abhängigkeiten.
Ein Mechanismus, mit dem sie einheitlich und zuverlässig auf Geräten auf künstlerische Weise auftreten.

Im Laufe der Zeit ändernde Einschränkungen

Wir gehen davon aus, dass sich die Einschränkungen, mit denen Code in der SDK-Laufzeit konfrontiert ist, später ändern werden. Versionen von Android. Um die Kompatibilität der Anwendungen sicherzustellen, ändern wir diese nicht Einschränkungen mit Mainline-Modulaktualisierungen für ein bestimmtes SDK-Level. 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. Es ist davon auszugehen, dass sich die Einschränkungen bei verschiedenen Android SDK-Versionen häufig ändern, insbesondere in den ersten Releases.

Außerdem entwickeln wir einen Canary-Mechanismus, Tester einer Gruppe beitreten, die die vorgeschlagenen Einschränkungen für die Android-Version. Dies hilft uns, Feedback zu erhalten und Vertrauen in die vorgeschlagene Änderungen an den Einschränkungen.

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 zählen unter anderem Analyse-SDKs, mit denen Nutzer Gruppen können für nachfolgendes Targeting, SDKs für die Anzeigenbereitstellung und zum Schutz vor Missbrauch erstellt werden. und SDKs zum Schutz vor Betrug für Anzeigen, Interaktions-SDKs und Attributions-SDKs.
Kann jedes SDK in der SDK-Laufzeit ausgeführt werden?

Obwohl der Schwerpunkt anfangs auf anzeigenbezogene SDKs liegt, werden Entwickler von nicht anzeigenbezogene SDKs, die eine datenschutzfreundliche Haltung anstreben und glauben, dass sie unter den oben beschriebenen Bedingungen Feedback zu ihren SDKs geben in der SDK-Laufzeit ausgeführt wird. 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 mehrjährigen Aufwand ohne Erfolgsgarantie. Daher enthält die Datenschutzrichtlinie Sandbox nutzt Prozessgrenzen, eine bewährte und bekannte Technologie.
Würde das Verschieben von SDKs in den SDK-Laufzeitprozess eine Downloadgröße oder Speicherplatz sparen?

Wenn mehrere Apps mit laufzeitfähigen SDKs derselben kann die Downloadgröße und der Speicherplatz reduziert werden.
Bei welchen App-Lebenszyklus-Ereignissen, z. B. wenn die App die Hintergrund: Haben SDKs in der SDK Runtime Zugriff darauf?

Wir sind Aktiv an der Designunterstützung für die Benachrichtigung der SDK-Laufzeit auf App-Ebene Lebenszyklus-Ereignisse seiner Clientanwendung (z.B. eine App, die in den Hintergrund geht, App im Vordergrund). 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