SDK-Laufzeit – Übersicht

Die Android-Plattform verwendet das Konzept der App-Sandbox, um robuste Ausführungs- und Sicherheitsgrenzen für App-Code entlang von Prozessgrenzen aufrechtzuerhalten. Es ist üblich, dass Apps Drittanbietercode enthalten, oft in Form von SDKs wie Anzeigen-SDKs oder Analyse-SDKs. So können sich App-Entwickler auf die Differenzierung ihrer App konzentrieren und gleichzeitig die Arbeit von Fachexperten nutzen, um ihre Ausführung über das hinaus zu skalieren, was sie allein problemlos erreichen könnten.

Wie bei den meisten Betriebssystemen werden SDKs in Android in der Sandbox der Host-App ausgeführt und erben dieselben Berechtigungen und Berechtigungen wie ihre Host-App sowie den Zugriff auf den Arbeitsspeicher und Speicher der Host-App. Diese Architektur ermöglicht zwar eine flexible Integration von SDKs und Apps, birgt aber auch das Potenzial für die nicht offengelegte Erhebung und Weitergabe von Nutzerdaten. Außerdem sind sich App-Entwickler möglicherweise nicht vollständig darüber im Klaren, in welchem Umfang ein Drittanbieter-SDK funktioniert und auf welche Daten es zugreift. Daher ist es schwierig, die Datenerhebung und ‑weitergabe ihrer App zu berücksichtigen.

In Android 14 haben wir eine neue Plattformfunktion eingeführt, mit der Drittanbieter-SDKs in einer dedizierten 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 modifizierte Ausführungsumgebung
  • Klar definierte Berechtigungen und Datenzugriffsrechte für SDKs

Wir freuen uns über Feedback von Werbetreibenden für mobile Apps zu diesem Design. Wir freuen uns auch über Feedback von der gesamten Entwickler-Community, um zukünftige Iterationen der SDK Runtime zu gestalten, einschließlich der Unterstützung für zusätzliche Anwendungsfälle.

Ziele

Mit diesem Vorschlag sollen die folgenden Ziele erreicht werden:

  • Durch Prozessisolation und eine gut definierte API- und Datenzugriffssteuerung können Sie den nicht offengelegten Zugriff auf und die Weitergabe von App-Daten eines Nutzers durch Drittanbieter-SDKs reduzieren. Weitere Informationen zur Prozessisolation finden Sie in einem separaten Abschnitt dieses Dokuments.
  • Reduzieren Sie das nicht offengelegte Tracking der App-Nutzung eines Nutzers durch Drittanbieter-SDKs, indem Sie den Zugriff von SDKs auf eindeutige, dauerhafte Kennungen einschränken.
  • Die Verteilung von SDK-Updates an Apps wird beschleunigt und gleichzeitig werden App-Entwickler und Endnutzer entlastet. Weitere Informationen zum vorgeschlagenen Modell für den vertrauenswürdigen SDK-Vertrieb finden Sie in einem anderen Abschnitt dieses Dokuments.
  • App-Entwickler können so besser berücksichtigen, wie ihre App auf Daten zugreift und sie weitergibt.
  • SDK-Entwickler können Manipulationen durch andere SDKs verhindern, indem sie bestimmte unsichere Sprachkonstrukte wie JNI-Code einschränken.
  • Mit Anzeigen-SDKs lassen sich ungültige Zugriffe und Anzeigenbetrug besser erkennen und verhindern, da Sie die Remote-Ansichten, in denen Media angezeigt werden, vollständig kontrollieren können.
  • Die Auswirkungen auf App- und SDK-Entwickler so weit wie möglich minimieren.

SDKs werden in einem isolierten Prozess ausgeführt

Die vorgeschlagene SDK Runtime ermöglicht es kompatiblen SDKs, die im weiteren Verlauf dieses Dokuments als laufzeitfähige (RE) SDKs bezeichnet werden, in einem separaten Prozess für die App zu laufen. Die Plattform ermöglicht die bidirektionale Kommunikation zwischen dem Prozess der App und der SDK Runtime. Weitere Informationen finden Sie im Abschnitt „Mitteilungen“ in diesem Dokument. Nicht-RE-SDKs würden wie bisher im Prozess der App verbleiben. Die folgenden Diagramme veranschaulichen diese Änderungen:

Vor dem Diagramm, das alles zeigt, was im App-Prozess ausgeführt wird.
Bevor der SDK-aufrufende Code in die SDK Runtime aufgenommen wird, befindet er sich zusammen mit den SDKs, die die Aufrufe von diesem Code empfangen, im Prozess der App.
Nach dem Diagramm, in dem die Prozesse zwischen dem App-Prozess und dem SDK-Laufzeitprozess aufgeteilt sind.
Nachdem der SDK-aufrufende Code in die SDK Runtime aufgenommen wurde, kommuniziert er im Vordergrundprozess der App mit 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

Die vorgeschlagene Trennung von SDK und App führt zu einem weiteren Trennungskonzept, nämlich für die Verteilung von SDK und App. Dazu ist ein vertrauenswürdiger Verteilungs- und Installationsmechanismus erforderlich, damit die richtigen SDKs in der SDK-Laufzeit einer App installiert werden.

Dieser Mechanismus schützt Nutzer und App-Entwickler vor dem Laden ungültiger SDKs und ermöglicht es App-Stores, die Belastung durch die SDK-Verteilung für App-Entwickler erheblich zu reduzieren.

SDKs müssen nicht mehr statisch verknüpft und zusammen mit ihren Apps verpackt werden, bevor sie zur Verteilung in einen App-Shop hochgeladen werden.

Der Prozess umfasst die folgenden Schritte:

  1. SDK-Entwickler laden ihre versionierten SDKs in die App-Stores hoch, getrennt von den Apps selbst.
  2. App-Entwickler geben ihre SDK-Abhängigkeiten nach Version an, erstellen einen Build und laden einen App-Release hoch, der die tatsächlichen SDK-Abhängigkeiten nicht enthält.
  3. Wenn ein Nutzer diese App herunterlädt, werden die angegebenen SDK-Abhängigkeiten der App für den Installationsvorgang verwendet und dann aus dem App-Store heruntergeladen.

Dieser neue Verteilungsmechanismus ermöglicht unabhängige SDK-Updates unter den folgenden Bedingungen:

  • Abwärtskompatible Fehlerkorrekturen, die keine neuen Funktionen, neuen APIs oder Änderungen an vorhandenen APIs hinzufügen oder Verhaltensänderungen einführen.
  • Abwärtskompatible Verbesserungen der Funktionen zur Betrugserkennung oder ‑bewertung.

Die Implementierung dieser Funktionen hängt vom Store ab.

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

Vor der Einführung der SDK-Laufzeit haben Entwickler ihre SDKs direkt an Apps gesendet.
Bisher senden Entwickler ihre SDKs direkt an Apps.
SDK-Entwickler veröffentlichen ihre SDKs in einem App-Shop. Der App-Store übernimmt dann den Vertrieb von Apps und allen SDK-Abhängigkeiten an Endnutzergeräte.
Mit der SDK-Laufzeit veröffentlichen SDK-Entwickler ihre SDKs in einem App-Shop. Der App-Store würde dann den Vertrieb von Apps und allen SDK-Abhängigkeiten an Endnutzergeräte übernehmen.

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

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

  • Zugriff: Berechtigungen, Arbeitsspeicher, Speicher
  • Ausführung: Sprachen, Laufzeitänderungen, Lebenszyklus, Media-Rendering
  • Kommunikation: App-zu-SDK und SDK-zu-SDK
  • Entwicklung: Informationen zum Erstellen, Debuggen und Testen in diesem Modell
  • Bereitstellung: Apps und SDKs für verschiedene Android-Versionen bereitstellen, aktualisieren und zurücksetzen

Dieses Dokument enthält auch häufig gestellte Fragen, um gängige Fragen zu beantworten.

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

Zugriff

Die Privatsphäre eines Systems zu verwalten bedeutet, zu verwalten, wie verschiedene Parteien auf verschiedene Ressourcen zugreifen können. Um unser Datenschutzversprechen einzuhalten, schlagen wir vor, das Modell für den Zugriff auf Apps, SDKs und Nutzerdaten so zu aktualisieren, dass es dem Prinzip der geringsten Berechtigung entspricht. Dadurch soll der nicht offengelegte Zugriff auf potenziell vertrauliche Daten verhindert werden.

SDK-Berechtigungen

Als separater Prozess hätte die SDK Runtime einen eigenen, genau definierten Satz von Berechtigungen, anstatt die Berechtigungen zu übernehmen, die der Nutzer der App erteilt hat. Basierend auf vorläufigen Untersuchungen zu den von Anzeigen-SDKs verwendeten Berechtigungen schlagen wir vor, dass die folgenden Berechtigungen standardmäßig für SDKs in der SDK Runtime verfügbar sein sollten:

  • INTERNET: Internetzugriff, um mit einem Webdienst kommunizieren zu können.
  • ACCESS_NETWORK_STATE: Informationen zu Netzwerken aufrufen.
  • READ_BASIC_PHONE_STATE: Zugriff auf Informationen zum Telefonstatus, z. B. zum Mobilfunknetztyp.
  • Berechtigungen für den Zugriff auf die datenschutzfreundlichen APIs, die wichtige Werbefunktionen bieten, ohne dass ein Zugriff auf appübergreifende Kennungen erforderlich ist.
  • AD_ID: Möglichkeit, die Werbe-ID anzufordern. Dies hängt auch davon ab, ob die App Zugriff auf diese Berechtigung hat.

Wir prüfen derzeit, ob und wie wir zusätzliche Berechtigungen autorisieren können, um die Auswirkungen auf Endnutzer in Bezug auf Datenschutz und Nutzerfreundlichkeit zu begrenzen. Wir bitten um Feedback zu Anwendungsfällen, die mit diesen Berechtigungen nicht abgedeckt werden.

Arbeitsspeicher

Die SDK-Laufzeit hätte aufgrund ihres eigenen Prozesses einen eigenen isolierten Speicherplatz. Durch diese Struktur wird dem SDK standardmäßig der Zugriff auf den Speicherplatz der App verweigert. Umgekehrt kann die Anwendung nicht auf den Speicherplatz des SDK zugreifen. Wir schlagen vor, dieses Standardverhalten beizubehalten, um dem Prinzip der geringsten Berechtigung zu entsprechen.

Speicher

Mit diesem Vorschlag soll ein Gleichgewicht zwischen dem Bedarf von SDKs, für den normalen Betrieb auf den Speicher zuzugreifen, und der Minimierung des app- und prozessübergreifenden Trackings mithilfe von persistentem Speicher geschaffen werden. Wir schlagen die folgende Änderung für den Zugriff auf Speicher vor:

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

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

Ausführung

Damit das System zwischen Apps, SDKs und Nutzern privat bleibt, muss der Ausführungskontext selbst (Codeformate, Sprachkonstrukte, zugängliche APIs und Systemdaten) diese Datenschutzgrenzen unterstützen oder zumindest keine Möglichkeiten bieten, sie zu umgehen. Gleichzeitig möchten wir den Zugriff auf die umfangreiche Plattform und die meisten Laufzeitfunktionen, die SDKs derzeit bieten, beibehalten. Wir schlagen hier eine Reihe von Aktualisierungen der Laufzeitumgebung vor, um dieses Gleichgewicht zu erreichen.

Code

Android-Code (Apps und SDKs) wird hauptsächlich von der Android-Laufzeit (ART) interpretiert, unabhängig davon, ob der Code in Kotlin oder Java geschrieben wurde. Die Vielfalt der ART und der darin enthaltenen Sprachkonstrukte in Verbindung mit der Überprüfbarkeit im Vergleich zu Alternativen, insbesondere nativem Code, scheint ein angemessenes Gleichgewicht zwischen Funktionalität und Datenschutz zu bieten. Wir schlagen vor, dass der Code von laufzeitfähigen SDKs ausschließlich aus Dex-Bytecode besteht und keinen JNI-Zugriff unterstützt.

Wir wissen, dass es Anwendungsfälle gibt, z. B. die Verwendung von benutzerdefiniert verpacktem SQLite, die aufgrund der Verwendung von nativem Code durch eine Alternative wie die integrierte Version von SQLite im Android SDK ersetzt werden müssen.

SELinux

Unter Android wird jeder Prozess (auch Prozesse, die als Root ausgeführt werden) mit einem bestimmten SELinux-Kontext ausgeführt. So kann der Kernel die Zugriffssteuerung für Systemdienste, Dateien, Geräte und andere Prozesse verwalten. Um die meisten SDK-Anwendungsfälle zu erhalten und gleichzeitig die Umgehung der Datenschutzmaßnahmen zu minimieren, die wir vorantreiben möchten, schlagen wir die folgenden Aktualisierungen des SELinux-Kontexts einer Nicht-System-App für die SDK-Laufzeit vor:

  • Es wäre nur auf eine begrenzte Anzahl von Systemdiensten zugegriffen werden. (wird gerade entwickelt)
  • SDKs können nur den Code in ihrem APK laden und ausführen.
  • Es wäre nur auf eine begrenzte Anzahl von Systemeigenschaften zugegriffen werden. (wird gerade entwickelt)

APIs

Die Verwendung von Reflection und das Aufrufen von APIs in der SDK-Laufzeit sind zulässig. Ein SDK darf jedoch keine Reflexion verwenden oder APIs in einem anderen SDK aufrufen, das für die Laufzeit aktiviert ist. Wir werden in einem zukünftigen Update einen vollständigen Vorschlag für verbotene APIs veröffentlichen.

Außerdem wurde in den letzten Android-Plattformversionen der Zugriff auf dauerhafte Kennungen eingeschränkt, um den Datenschutz zu verbessern. Für die SDK-Laufzeit schlagen wir vor, den Zugriff auf Kennungen, die für das app-übergreifende Tracking verwendet werden könnten, weiter einzuschränken.

Auf SDK Runtime APIs kann nur über Apps zugegriffen werden, die im Vordergrund ausgeführt werden. Der Versuch, von Apps im Hintergrund auf SdkSandboxManager-APIs zuzugreifen, führt dazu, dass SecurityException ausgelöst wird.

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

Lifecycle

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

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

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

    Unter Android 14 wird die SDK-Laufzeit ausgeführt, wenn sich eine App im Vordergrund befindet. Sie hat eine hohe Priorität und wird wahrscheinlich nicht beendet. Wenn die App in den Hintergrund verschoben wird, sinkt die Priorität des SDK-Laufzeitprozesses und er kann beendet werden. Die Priorität des SDK Runtime-Prozesses bleibt niedrig, auch wenn die App wieder in den Vordergrund geholt wird. Daher ist es sehr wahrscheinlich, dass sie bei Speicherauslastung beendet wird.

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

    Wenn die SDK-Laufzeit beendet wird, während die App noch aktiv ist, z. B. aufgrund einer unbehandelten Ausnahme im SDK, geht der SDK-Laufzeitstatus verloren, einschließlich aller zuvor geladenen SDKs und Remote-Ansichten. Der App-Entwickler kann die Beendigung der SDK-Laufzeit mit einer der folgenden Methoden behandeln:

    • Das Angebot bietet App-Entwicklern zugehörige Methoden für Lifecycle-Callbacks, um zu erkennen, wann die SDK Runtime beendet wurde.
    • Wenn die SDK-Laufzeit beendet wird, während Anzeigen ausgeliefert werden, funktionieren Anzeigen möglicherweise nicht wie erwartet. Beispielsweise können Ansichten auf dem Bildschirm eingefroren sein und nicht mehr interaktiv sein. Die App kann die Anzeigenansicht entfernen, wenn dies keine Auswirkungen auf die Nutzerfreundlichkeit hat.
    • Die App kann einen weiteren Versuch unternehmen, SDKs zu laden und Anzeigen anzufordern.
    • Wenn die SDK-Laufzeit unter Android 14 beendet wird, während SDKs geladen sind, und der App-Entwickler die oben genannten Methoden für den Lebenszyklus-Callback nicht registriert hat, wird die App standardmäßig beendet. Nur die App-Prozesse, in die SDKs geladen wurden, werden beendet und verlassen normal.
    • Binder-Objekte, die vom SDK zurückgegeben werden, um mit ihm zu kommunizieren (z. B. SandboxedSdk), lösen eine DeadObjectException aus, wenn sie von der App verwendet werden.

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

    Bei dauerhaften Fehlern sollte der App-Entwickler einen sanften Abbau ohne das SDK planen oder den Nutzer benachrichtigen, wenn das SDK für die Hauptfunktion der App unerlässlich ist. Weitere Informationen zur Interaktion zwischen App und SDK finden Sie in diesem Dokument im Abschnitt zur Kommunikation.

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

Sonderfälle

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

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

Media-Rendering

Es gibt SDKs, mit denen Inhalte wie Text, Bilder und Videos in einer von der App angegebenen Ansicht gerendert werden. Dazu schlagen wir einen Ansatz für das Remote-Rendering vor, bei dem das SDK die Media in der SDK Runtime rendert, aber die SurfaceControlViewHost API verwendet, damit die Media in einer von der App angegebenen Ansicht gerendert werden können. So kann das SDK diese Media auf eine Weise rendern, die für den Nutzer privat ist. Gleichzeitig können ungültige oder betrügerische Nutzerinteraktionen mit den gerenderten Media verhindert und erkannt werden.

Native Anzeigen, die nicht vom SDK, sondern von der App gerendert werden, werden von SDKs in der SDK-Laufzeit unterstützt. Die Erfassung von Signalen und das Abrufen von Creatives erfolgen wie bei nicht nativen Anzeigen. Dies ist ein aktiver Untersuchungsbereich.

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

Systemzustand

Wir möchten die Auswirkungen der SDK-Laufzeit auf die Systemleistung von Endnutzergeräten minimieren und arbeiten an entsprechenden Lösungen. Wahrscheinlich wird die SDK-Laufzeit jedoch auf einigen Android 14-Einsteigergeräten mit sehr begrenzten Systemressourcen, z. B. Android (Go Edition), aufgrund der Auswirkungen auf die Systemleistung nicht unterstützt. Wir werden in Kürze die Mindestanforderungen für die erfolgreiche Verwendung der SDK-Laufzeit bekannt geben.

Kommunikation

Da Apps und SDKs derzeit im selben Prozess ausgeführt werden, ist die Kommunikation zwischen ihnen ungehindert und ohne Vermittlung möglich. Außerdem ermöglicht Android die Kommunikation zwischen Apps, auch wenn die Kommunikation mit SDKs beginnt und endet. Dieses kostenlose Kommunikationsmodell ermöglicht verschiedene Anwendungsfälle, birgt aber gleichzeitig die Möglichkeit einer nicht offengelegten Datenweitergabe zwischen Apps und zwischen SDKs innerhalb und zwischen Apps. Wir schlagen die folgenden Änderungen an diesem Kommunikationsmodell vor, um ein Gleichgewicht zwischen dem Wert dieser Kommunikation und der Erreichung unserer erklärten Ziele zu schaffen.

App-zu-SDK

Die Schnittstelle zwischen der App und dem SDK ist der häufigste Kommunikationspfad zu einem SDK. Die API eines SDKs ist der Ort, an dem sich ein Großteil der nutzerorientierten Differenzierung und Innovation befindet. Wir möchten, dass SDKs weiterhin innovativ sein und sich differenzieren können. Unser Vorschlag ermöglicht es SDKs, APIs für Apps bereitzustellen, damit Apps von all diesen Innovationen profitieren können.

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

Mit diesem Vorschlag möchten wir App- und SDK-Entwicklern die Boilerplate-Marshaling-Arbeit abnehmen und gleichzeitig SDK-Entwicklern Flexibilität bieten. Außerdem soll sichergestellt werden, dass SDK-Code in der SDK-Laufzeit ausgeführt wird, um unsere Datenschutzziele zu erreichen. Sollten wir diesen Weg einschlagen, müssten die API-Definitionsprache und die Tools mit Ihrer Hilfe entwickelt werden.

Das allgemeine Interaktionsmodell sieht so aus:

  • Die App ruft das SDK über die Schnittstelle auf und übergibt Callbacks.
  • Das SDK erfüllt die Anfragen asynchron und antwortet über die Callbacks.
  • Das lässt sich auf jedes Publisher-Subscriber-Modell verallgemeinern. Das bedeutet, dass eine App Ereignisse im SDK mit Callbacks abonnieren kann. Wenn diese Ereignisse eintreten, werden die Callbacks ausgelöst.

Eine Folge der neuen prozessübergreifenden Struktur dieses Vorschlags ist, dass zwei Prozesslebenszyklen verwaltet werden müssen: einer für die App selbst und einer für die SDK-Laufzeit. Unser Vorschlag zielt darauf ab, so viel wie möglich zu automatisieren, um die Auswirkungen auf App- und SDK-Entwickler zu minimieren. Das folgende Diagramm zeigt einen Ansatz, den wir in Erwägung ziehen:

Diagramm der Interaktionen zwischen App und SDK.
Sequenzdiagramm, das die Interaktionen zwischen App und SDK beim Starten der App und des SDK zeigt.

Die Plattform würde neue APIs für Apps bereitstellen, mit denen SDKs dynamisch in den SDK-Laufzeitprozess geladen werden können. Außerdem würden Apps über Änderungen am Status des Prozesses benachrichtigt und könnten mit in die SDK-Laufzeit geladenen SDKs interagieren.

Das Diagramm in der vorherigen Abbildung zeigt die Kommunikation zwischen App und SDK auf einer niedrigeren Ebene, ohne die Marshaling-Ebene.

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

  1. Bevor eine App mit einem SDK interagieren konnte, musste sie die Plattform auffordern, das SDK zu laden. Um die Integrität des Systems zu gewährleisten, würden Apps die SDKs angeben, die sie in ihrer Manifestdatei laden möchten. Nur diese SDKs dürften geladen werden.

    Das folgende Code-Snippet enthält ein Beispiel für die API:

    SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
    OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)

  2. Das SDK wird benachrichtigt, dass es geladen wurde, und gibt seine Schnittstelle zurück. Diese Schnittstelle ist für die Verwendung durch den App-Prozess vorgesehen. Wenn die Schnittstelle außerhalb der Prozessgrenze freigegeben werden soll, muss sie als IBinder-Objekt zurückgegeben werden.

    Im Leitfaden zu gebundenen Diensten finden Sie verschiedene Möglichkeiten, IBinder bereitzustellen. Unabhängig davon, welche Methode Sie wählen, muss sie zwischen dem SDK und der aufrufenden App konsistent sein. In den Diagrammen wird AIDL als Beispiel verwendet.

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

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

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

So kann die App auch Media aus dem SDK rendern:

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

    Das folgende Code-Snippet enthält ein Beispiel für die API:

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

  2. Die App könnte dann die zurückgegebenen SurfacePackage über die setChildSurfacePackage API in SurfaceView einbetten.SurfaceView

    Das folgende Code-Snippet enthält ein Beispiel für die API:

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)

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

SDK-zu-SDK

Zwei SDKs in derselben App müssen oft miteinander kommunizieren. Dies kann passieren, wenn ein bestimmtes SDK so konzipiert ist, dass es aus einzelnen SDKs besteht, und wenn zwei SDKs von verschiedenen Parteien zusammenarbeiten müssen, um eine Anfrage der aufrufenden App zu erfüllen.

Es gibt zwei wichtige Fälle, die berücksichtigt werden müssen:

  • Wenn beide SDKs laufzeitfähig sind: In diesem Fall werden beide SDKs in der SDK-Laufzeit mit allen ihren Schutzmaßnahmen ausgeführt. SDKs können nicht so kommunizieren wie in einer App. Daher wurde eine API in SdkSandboxController hinzugefügt, um das Abrufen von SandboxedSdk-Objekten für alle geladenen RE-SDKs zu ermöglichen. Dadurch kann ein RE-SDK mit anderen SDKs kommunizieren, die in der SDK-Laufzeit geladen sind.
  • Wenn nur ein SDK zur Laufzeit aktiviert ist:
    • Wenn das aufrufende SDK in der App ausgeführt wird, unterscheidet sich dies nicht davon, dass die App selbst das zweite SDK in der SDK Runtime aufruft.
    • Wenn das aufrufende SDK in der SDK Runtime ausgeführt wird, wird in diesem Vorschlag empfohlen, eine Methode mit dem IBinder aus dem Abschnitt „App-zu-SDK“ verfügbar zu machen, auf die Code in der App wartet, die er verarbeitet und auf die er mit den bereitgestellten Callbacks antwortet.
    • Ad-SDKs, die nicht laufzeitfähig sind, können sich möglicherweise nicht selbst registrieren. Wir schlagen vor, ein Mediator-SDK zu erstellen, das alle Partner- oder App-SDKs als direkte Abhängigkeiten der App enthält und die Registrierung übernimmt. Dieses Mediator-SDK stellt die Kommunikation zwischen nicht laufzeitfähigen SDKs oder anderen App-Abhängigkeiten und dem laufzeitfähigen Mediator her, der als Adapter fungiert.

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

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

Die folgenden Anwendungsfälle werden bei der Entwicklung der Primitiven berücksichtigt:

  1. Vermittlung und Gebote Viele Werbe-SDKs bieten eine Vermittlungs- oder Gebotsfunktion, bei der das SDK verschiedene andere SDKs für eine Anzeigenimpression (Vermittlung) oder zum Erfassen von Signalen für die Durchführung einer Auktion (Gebote) aufruft. In der Regel ruft das koordinierende SDK andere SDKs über einen Adapter auf, der vom koordinierenden SDK bereitgestellt wird. Angesichts 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. Die Darstellung in diesem Kontext ist ein aktives Forschungsgebiet.
  2. Funktionen entdecken: Einige SDK-Produkte bestehen aus kleineren SDKs, die durch einen Prozess der SDK-Erkennung das endgültige Funktionsset bestimmen, das dem App-Entwickler zur Verfügung steht. Registrierungs- und Ermittlungsprimitive sollen diesen Anwendungsfall ermöglichen.
  3. Abo-Modelle für Publisher Einige SDKs sind so konzipiert, dass sie einen zentralen Publisher von Ereignissen haben, den andere SDKs oder Apps abonnieren können, um Benachrichtigungen über Callbacks zu erhalten. Die oben genannten Primitiven sollten diesen Anwendungsfall unterstützen.

App-to-App

Bei der App-zu-App-Kommunikation ist mindestens einer der beiden kommunizierenden Prozesse ein SDK mit aktivierter Laufzeit. Sie ist ein potenzieller Vektor für die nicht offengelegte Weitergabe von Daten. Daher kann die SDK Runtime keinen direkten Kommunikationskanal zu einer anderen App als der Clientanwendung oder zu SDKs in einer anderen SDK Runtime herstellen, die für eine andere App erstellt wurde. Dies wird auf folgende Weise erreicht:

  • Das SDK kann Komponenten wie <service>, <contentprovider> oder <activity> nicht in seinem Manifest definieren.
  • Das SDK kann keine ContentProvider veröffentlichen oder eine Broadcast-Nachricht senden.
  • Das SDK kann eine Aktivität starten, die zu einer anderen App gehört. Allerdings gibt es Einschränkungen hinsichtlich der Inhalte, die im Intent gesendet werden können. Dieser Intent können beispielsweise keine Extras oder benutzerdefinierten Aktionen hinzugefügt werden.
  • Das SDK kann nur eine Verbindung zu Diensten in einer Zulassungsliste herstellen oder diese starten.
  • Das SDK kann nur auf eine Teilmenge des Systems ContentProvider zugreifen, z. B. auf com.android.providers.settings.SettingsProvider. Die abgerufenen Daten enthalten keine IDs und können nicht verwendet werden, um einen Fingerabdruck des Nutzers zu erstellen. Diese Prüfungen gelten auch für den Zugriff auf ContentProvider über ContentResolver.
  • Das SDK kann nur auf eine Teilmenge geschützter Broadcast-Empfänger zugreifen, z. B. android.intent.action.AIRPLANE_MODE.

Manifest-Tags

Wenn das SDK installiert ist, parst PackageManager das Manifest des SDK und kann das SDK nicht installieren, wenn verbotene Manifest-Tags vorhanden sind. Das SDK definiert beispielsweise möglicherweise keine Komponenten wie <service>, <activity>, <provider> oder <receiver> und deklariert im Manifest keine <permission>. Tags, die nicht installiert werden können, werden in der SDK-Laufzeit nicht unterstützt. Tags, die nicht zu einem Installationsfehler führen, sondern automatisch ignoriert werden, werden möglicherweise in zukünftigen Android-Versionen unterstützt.

Diese Prüfungen können auch von Build-Zeit-Tools durchgeführt werden, die das SDK zum Erstellen des SDK-Bundles verwendet, sowie beim Hochladen in den App-Store.

Unterstützung bei Aktivitäten

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

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

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

Der Ablauf zum Anfordern einer Aktivität wird im folgenden Diagramm dargestellt.

Ein Diagramm, das den Ablauf der Anfrage einer Aktivität zeigt.
Ablaufdiagramm für den Start einer Aktivität.

Entwicklung

Ein wichtiger Grundsatz dieses Vorschlags ist es, die Auswirkungen auf das Entwickler-Ökosystem so weit wie möglich zu minimieren. Dieses Angebot bietet Entwicklern eine umfassende Reihe von Entwicklungstools zum Schreiben, Erstellen und Debuggen von RE-Apps und SDKs. Damit dieser Vorschlag umgesetzt werden kann, müssen einige Änderungen an der Konfiguration, Erstellung und Entwicklung von RE-Apps und ‑SDKs vorgenommen werden.

In der Erstellung

Android Studio und die zugehörigen Tools werden aktualisiert, um die SDK-Laufzeit zu unterstützen. So können Entwickler ihre RE-Apps und SDKs richtig konfigurieren und alte oder nicht unterstützte Aufrufe werden bei Bedarf durch neuere Alternativen ersetzt. Während der Erstellungsphase sind einige Schritte erforderlich, die Entwickler im Rahmen unseres Vorschlags ausführen müssten.

App-Entwickler

Apps müssen ihre RE SDK- und SDK-Zertifikatsabhängigkeiten in ihrem App-Manifest angeben. In unserem Vorschlag gehen wir davon aus, dass dies die Quelle der Wahrheit des Anwendungsentwicklers ist. Beispiel:

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

Dies gilt nur für SDKs, die über den App-Shop vertrieben werden, unabhängig davon, ob sie RE-kompatibel sind oder nicht. Apps, die SDKs statisch verknüpfen, würden die aktuellen Abhängigkeitsmechanismen verwenden.

Da wir Entwickler so wenig wie möglich beeinträchtigen möchten, ist es wichtig, dass App-Entwickler nach der Angabe eines Ziel-API-Levels, das die SDK-Laufzeit unterstützt, nur einen Build benötigen, unabhängig davon, ob dieser Build auf Geräten ausgeführt wird, die die SDK-Laufzeit unterstützen oder nicht.

SDK-Entwickler

In unserem Vorschlag müssen RE SDK-Entwickler im Manifest explizit ein neues Element deklarieren, das die SDK- oder Bibliotheksentität darstellt. Außerdem muss ein ähnlicher Satz von Werten wie die Abhängigkeit sowie eine Nebenversionsnummer angegeben werden:

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

Wenn RE SDK-Entwickler andere RE SDKs als Build-Zeit-Abhängigkeiten haben, müssen sie diese wahrscheinlich auf dieselbe Weise deklarieren wie ein App-Entwickler. RE‑SDKs, die von Nicht‑RE‑SDKs abhängen, würden sie statisch verknüpfen. Dadurch können Probleme entstehen, die bei der Erstellung oder während der Testläufe erkannt würden, wenn für die nicht RE-SDKs Funktionen erforderlich sind, 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 Geräte ohne RE-Unterstützung unterstützen, z. B. Geräte mit Android 12 oder niedriger und, wie im Abschnitt „System Health“ des Dokuments erwähnt, Android 14-Einstiegsgeräte mit sehr begrenzten Systemressourcen. Wir arbeiten an Ansätzen, mit denen SDK-Entwickler eine einzige Codebasis für RE- und Nicht-RE-Umgebungen beibehalten können.

Builds

App-Entwickler

Wir gehen davon aus, dass sich für App-Entwickler im Build-Schritt nur wenig ändern wird. SDK-Abhängigkeiten, unabhängig davon, ob sie lokal oder über den App-Store verteilt werden (RE oder nicht), müssen auf dem Computer für Linting, Kompilierung und Builds vorhanden sein. Wir schlagen vor, dass Android Studio diese Details bei normaler Nutzung für den App-Entwickler abstrahiert und so transparent wie möglich macht.

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

Wir befinden uns hier noch in der Designphase und werden weitere Informationen veröffentlichen, sobald sie verfügbar sind.

SDK-Entwickler

Wir arbeiten an einer Lösung, mit der Nicht-RE- und RE-Versionen eines SDK in ein einzelnes Artefakt für die Verteilung eingebunden werden können. Dadurch müssten App-Entwickler keine separaten Builds für RE- und Nicht-RE-Versionen eines SDKs unterstützen.

Ähnlich wie bei Apps müssen alle über den App-Store verteilten SDKs für Abhängigkeiten auf dem Computer vorhanden sein, damit Linting, Kompilierung und Builds möglich sind. Wir gehen davon aus, dass Android Studio dies nahtlos ermöglicht.

Test

App-Entwickler

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

SDK-Entwickler

SDK-Entwickler verwenden in der Regel interne Test-Apps auf Geräten und Emulatoren, um ihre Entwicklung zu testen. Unser Vorschlag ändert daran nichts. Die In-App-Validierung würde denselben Schritten folgen, die oben für App-Entwickler beschrieben sind, mit einem einzigen Build-Artefakt für RE- und Nicht-RE-Apps. SDK-Entwickler können ihren Code durchgehen, unabhängig davon, ob er in der SDK-Laufzeit enthalten ist oder nicht. Bei erweiterten Debugging- und Profiling-Tools kann es jedoch einige Einschränkungen geben. Dies ist ein aktiver Untersuchungsbereich.

Vertrieb

Durch die Trennung einer App von ihren SDKs können SDKs über App-Stores vertrieben werden. Dies ist eine Plattformfunktion, die nicht auf einen bestimmten Vertriebskanal beschränkt ist.

Das bietet folgende Vorteile:

  • Qualität und Konsistenz von SDKs sicherstellen
  • Veröffentlichung für SDK-Entwickler optimieren
  • Die Einführung wichtiger Patch-Updates für SDKs in installierten Apps beschleunigen.

Zur Unterstützung der SDK-Verteilung muss ein Vertriebskanal die folgenden Funktionen unterstützen:

  • SDK-Entwickler können ihre SDKs im Store oder auf der Plattform veröffentlichen und Wartungsarbeiten durchführen.
  • Sorgen Sie für die Integrität von SDKs und Apps und beheben Sie ihre Abhängigkeiten.
  • SDKs zuverlässig und leistungsstark auf Geräten bereitstellen

Sich im Laufe der Zeit entwickelnde Einschränkungen

Wir gehen davon aus, dass sich die Einschränkungen für Code in der SDK-Laufzeit mit späteren Versionen von Android weiterentwickeln werden. Um die Anwendungskompatibilität zu gewährleisten, werden diese Einschränkungen bei Mainline-Modul-Updates für ein bestimmtes SDK-Level nicht geändert. Das Verhalten, das mit einem bestimmten targetSdkVersion verknüpft ist, bleibt erhalten, bis die Unterstützung für dieses targetSdkVersion durch die App-Shop-Richtlinie eingestellt wird. Die Einstellung von targetSdkVersion kann schneller erfolgen als bei Apps. Die Einschränkungen werden sich in den verschiedenen Android-SDK-Versionen häufig ändern, 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 Android-Version erhält. So können wir Feedback zu den vorgeschlagenen Änderungen an den Einschränkungen erhalten und uns von ihrer Richtigkeit überzeugen.

FAQ

  1. Was ist ein werbebezogenes SDK?

    Ein anzeigenbezogenes SDK ist ein SDK, das die Ausrichtung von Nutzern mit kommerziellen Botschaften in Apps, die nicht dem Werbetreibenden gehören, unterstützt. Dazu gehören unter anderem Analyse-SDKs, mit denen Nutzergruppen für das nachfolgende Targeting erstellt werden können, SDKs für die Anzeigenbereitstellung, SDKs zur Missbrauchs- und Betrugsbekämpfung für Anzeigen, SDKs für Interaktionen und SDKs für die Zuordnung.

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

    Der Fokus liegt zwar zunächst auf Anzeigen-SDKs, aber Entwickler von nicht anzeigenspezifischen SDKs, die eine datenschutzfreundliche Ausrichtung anstreben und glauben, dass sie unter den oben genannten Bedingungen arbeiten können, können Feedback zu ihren SDKs geben, die in der SDK-Laufzeit ausgeführt werden. Die SDK-Laufzeit ist jedoch nicht mit allen SDK-Designs kompatibel. Abgesehen von den dokumentierten Einschränkungen ist die SDK-Laufzeit wahrscheinlich nicht für SDKs geeignet, die eine Echtzeitkommunikation oder einen hohen Durchsatz mit der Host-App erfordern.

  3. Warum sollte ich die Prozessisolation anstelle der Isolation innerhalb der Java-basierten Laufzeit eines Prozesses wählen?

    Derzeit bietet die Java-basierte Laufzeit nicht ohne Weiteres die Sicherheitsgrenzen, die für die Datenschutzgarantien erforderlich sind, die für Android-Nutzer gewünscht werden. Die Umsetzung eines solchen Projekts würde wahrscheinlich mehrere Jahre dauern und es gäbe keine Erfolgsgarantie. Daher werden in der Privacy Sandbox Prozessgrenzen verwendet, eine bewährte und gut verstandene Technologie.

  4. Würde das Verschieben von SDKs in den SDK-Laufzeitprozess zu einer geringeren Downloadgröße oder zu Speicherplatzersparnissen führen?

    Wenn mehrere Apps in Laufzeit-fähige SDKs derselben Version eingebunden sind, kann dies die Downloadgröße und den Speicherplatzbedarf verringern.

  5. Auf welche Arten von App-Lebenszyklusereignissen, z. B. wenn die App in den Hintergrund wechselt, haben SDKs in der SDK Runtime Zugriff?

    Wir arbeiten aktiv an der Unterstützung von Benachrichtigungen für die SDK-Laufzeit über App-Ereignisse auf App-Ebene des Lebenszyklus der Clientanwendung (z.B. App wird in den Hintergrund verschoben, App wird in den Vordergrund verschoben). Design und Beispielcode werden in einer kommenden Developer Preview veröffentlicht.