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:
<ph type="x-smartling-placeholder">. <ph type="x-smartling-placeholder">
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:
<ph type="x-smartling-placeholder"><ph type="x-smartling-placeholder">
Ä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önnenACCESS_NETWORK_STATE
: Auf Informationen zu Netzwerken zugreifenREAD_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 eineDeadObjectException
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:
<ph type="x-smartling-placeholder">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 dieIBinder
-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 entsprechendenSurfaceControlViewHost.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 dieSurfaceView
einbetten. über diesetChildSurfacePackage
API inSurfaceView
.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öglichenSandboxedSdk
-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 aufContentProvider
mitContentResolver
. - 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.
<ph type="x-smartling-placeholder">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