Einige Privacy Sandbox-Technologien werden eingestellt.

Weitere Informationen

Privacy Sandbox-Funktionsstatus enthält weitere Informationen zum Status einzelner APIs und Plattformfunktionen.

Diese Seite wurde von der Cloud Translation API übersetzt.

Runtime-fähiges SDK erstellen und nutzen

Key concepts

Wichtige Konzepte

In diesem Abschnitt wird die Architektur der SDK-Laufzeit, die Installation runtimefähiger SDKs, die Abwärtskompatibilität und die Migration vorhandener SDKs zur SDK-Laufzeit erläutert.

Glossar

Laufzeitfähiges SDK (Runtime-enabled SDK, RE SDK): Ein SDK, das in der SDK-Laufzeitumgebung ausgeführt wird und über die Inter-Process-Kommunikation (IPC) mit der App kommuniziert.
Laufzeitbewusstes SDK (Runtime-Aware SDK, RA SDK): Ein nicht laufzeitfähiges SDK, das statisch mit der App verknüpft ist und Ihren vorhandenen SDK-Code sowie neuen Code zum Aufrufen Ihres laufzeitfähigen SDKs enthalten kann.
- Dies wird manchmal auch als statisch verknüpft oder statisches SDK bezeichnet.
Shim: Eine Jetpack-Bibliothek, die die Kommunikation zwischen Prozessen oder die Inter-Process-Kommunikation (IPC) abstrahiert und dieselbe App-SDK-Schnittstelle beibehält.

SDK-Laufzeitarchitektur

Die SDK-Laufzeit verwendet ein Client-Server-Modell.

Der Hauptunterschied besteht darin, dass der „Client“ (App) und der „Server“ (laufzeitfähige SDKs) auf demselben Gerät ausgeführt werden und diese Kommunikation prozessübergreifend erfolgt.

Um diese Herausforderungen zu meistern, haben wir die folgenden Jetpack-Bibliotheken und ‑Tools entwickelt, um die Integration von App-SDKs in der SDK-Laufzeit zu vereinfachen:

Shim-Bibliothek: Die Wrapper-Bibliothek (oder Shim) hilft, die Kommunikation zwischen Prozessen oder die Inter-Process-Kommunikation (IPC) zu abstrahieren. Außerdem wird dadurch die Verwendung derselben App-SDK-Benutzeroberfläche unterstützt.
Abwärtskompatible Bibliothek:Diese Bibliothek sorgt für Abwärtskompatibilität und dafür, dass Ihr SDK unabhängig davon kompatibel ist, ob die SDK-Laufzeit verfügbar ist oder nicht.
UI-Bibliothek:Wir stellen auch Bibliotheken für die Remote-Präsentation bereit, z. B. zum Abrufen der Benutzeroberfläche aus dem runtime-fähigen SDK oder zum Ändern der Größe und Neulayouten von Ansichten.

Architekturübersicht der SDK-Laufzeit — Diagramm, das eine App zeigt, die über verschiedene Bibliotheken mit dem laufzeitfähigen SDK interagiert

Änderungen am Installationsvorgang

Wenn Sie Ihr laufzeitfähiges SDK in Android Studio oder anderen Tools erstellen, erstellen Sie ein Android SDK-Bundle (ASB), ein Veröffentlichungsformat für laufzeitfähige SDKs.

bundletool verarbeitet das ASB, um ein APK für Ihr laufzeitfähiges SDK zu erstellen. Dieses separate APK enthält Ihren SDK-Code, aber keinen App-Code.

In der Manifestdatei der App wird eine Abhängigkeit vom Namen und der Version des laufzeitfähigen SDKs deklariert. Diese Abhängigkeit wird von der Installations-App aufgelöst.

Sobald das SDK-APK vom Installationsprogramm abgerufen wurde, beginnt die Installation mit der Installation des SDK-APK. Nach erfolgreichem Abschluss wird das APK der App installiert.

Der Ablauf ist unterschiedlich, wenn die App auf Android 13 oder niedriger installiert ist und auf Geräten, die die SDK Runtime nicht unterstützen. In diesem Szenario wird im Play Store ein einzelnes APK installiert, das sowohl Ihr runtimefähiges SDK als auch den App-Code enthält. Weitere Informationen finden Sie im Abschnitt Verteilung.

Wenn eine App in der Produktion von diesem SDK abhängig ist, erstellt der App-Shop das richtige SDK-APK aus diesem ASB und installiert es.

Abwärtskompatibilität

Da die SDK-Laufzeit in Android 14 eingeführt wurde, mussten wir frühere Versionen unterstützen, ohne zusätzlichen Aufwand für SDK- oder App-Entwickler zu verursachen.

Für die Abwärtskompatibilität mit Android 13 und niedriger haben wir eine Jetpack-Bibliothek eingeführt, mit der Ihr runtimefähiges SDK unabhängig von der Geräteunterstützung für die SDK-Laufzeit nahtlos ausgeführt werden kann.

Wenn Sie dieser Anleitung folgen, ist Ihr laufzeitfähiges SDK standardmäßig abwärtskompatibel. Es sind keine weiteren Schritte erforderlich.

Wir weisen an den entsprechenden Stellen darauf hin, welche Maßnahmen mit der Abwärtskompatibilität verbunden sind. Generell sollten Sie jedoch darauf achten, dass Sie die richtigen Abhängigkeiten deklariert haben und die *Compat-Klassen nach Bedarf verwenden.

Vorhandene SDKs migrieren

Wenn Sie ein vorhandenes SDK zur Laufzeit migrieren möchten, müssen Sie nicht Ihre gesamte Codebasis auf einmal umstrukturieren. Stattdessen können Sie die vorhandene SDK-Logik schrittweise in das neue runtimefähige SDK migrieren.

Wir empfehlen die folgenden drei Phasen für die Migration eines vorhandenen SDKs in die SDK-Laufzeit:

Erstellen Sie ein laufzeitfähiges SDK für die Übergangsphase und ein entsprechendes laufzeitbewusstes SDK. So können Sie die Geschäftslogik schrittweise aus Ihrem vorhandenen SDK migrieren und eine Testplattform für A/B-Tests erhalten.
Alle vorhandenen SDK-Geschäftslogiken in einen stabilen Zustand umwandeln und ein entsprechendes schlankes, runtime-fähiges SDK verwenden, um die App-Migration zu erleichtern
Unterstützung für interessierte Apps mit vollständiger Migration, um Ihr laufzeitfähiges SDK direkt ohne ein schlankes laufzeitfähiges SDK zu verwenden

Phase 1 – Übergangsphase: Dickes runtime-aware SDK

Sie können damit beginnen, einen Teil Ihrer Geschäftslogik in Ihrem runtime-aware SDK beizubehalten. Wir nennen das ein laufzeitabhängiges SDK oder einen In-App-Wrapper.

Mit diesem Ansatz können Sie alle oder einige der Funktionen Ihres SDKs in der statischen App-Bibliothek zusammen mit einem neu erstellten laufzeitfähigen SDK beibehalten.

So können Sie Ihre Anwendungsfälle nach und nach in das laufzeitfähige SDK migrieren und es mit Ihrem vorhandenen SDK vergleichen.

In dieser Phase muss der App-Entwickler nichts an der Verwendung Ihres SDKs ändern, da Ihre statische App-Bibliothek (laufzeitbewusstes SDK) die erforderlichen Schritte für die Verwendung Ihres laufzeitbewussten SDKs ausführt.

Die App ruft ein statisches, runtime-fähiges SDK auf, das eine Übersetzungsschicht enthalten kann, um das runtime-fähige SDK sowie andere Geschäftslogik darin aufzurufen. — Die App ruft ein statisches, laufzeitbewusstes SDK auf, das eine Übersetzungsschicht enthalten kann, um das laufzeitfähige SDK sowie andere Geschäftslogik darin aufzurufen.

Phase 2 – Steady State: schlankes runtime-aware SDK

Im Gegensatz zum vollständigen runtime-aware SDK enthält ein dünner Wrapper oder ein dünnes runtime-aware SDK (thin RA_SDK) nur API-Übersetzung und runtimefähigen SDK-Aufrufcode in Ihrem statisch verknüpften Bibliotheks-SDK.

In dieser Phase sollten Sie Ihren gesamten SDK-Code aus dem SDK der statischen App-Bibliothek in das runtimefähige SDK migriert haben.

App-Entwickler müssen keine Änderungen an Phase 1 vornehmen, da Ihr schlankes, laufzeitbewusstes In-App-SDK den Aufruf Ihres laufzeitfähigen SDKs innerhalb der SDK-Laufzeit übernimmt.

Die App ruft ein statisches SDK auf, das nur eine Übersetzungsschicht enthält.

Phase 3: Vollständige Migration

In dieser letzten Phase haben Sie alle Funktionen Ihres SDKs in das runtimefähige SDK migriert und alle statischen Bibliotheken aus der App entfernt.

Ihre App-Clients müssen Ihre Bibliotheken dann nicht mehr in ihre Builds aufnehmen, sondern nur die SDK-Abhängigkeiten im Manifest auflisten und die SDK-Aufrufe in ihren App-Code einfügen.

Die SDK-Aufrufe werden vom System an die SDK-Laufzeit weitergeleitet, wo Ihr laufzeitfähiges SDK automatisch geladen wird.

Architektur der vollständigen Migrationsphase, in der das laufzeitfähige SDK direkt über den Anzeigencode der App aufgerufen wird. — Architektur der vollständigen Migrationsphase, in der das runtimefähige SDK direkt über den Anzeigencode der App aufgerufen wird.

Einführung

Schritt 2: Entwicklungsumgebung einrichten