Diese Seite wurde von der Cloud Translation API übersetzt.

Runtime-fähiges SDK erstellen und nutzen
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Key concepts

Wichtige Konzepte

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

Glossar

Laufzeitfähiges SDK (RE SDK): Ein SDK, das in der SDK-Laufzeit ausgeführt werden kann und mit der App über prozessübergreifende Kommunikation zu kommunizieren. (IPC).
Runtime-aware SDK (RA SDK): Ein nicht laufzeitfähiges SDK, das mit der App verknüpft ist die Ihren vorhandenen SDK-Code sowie neuen Code zum Aufrufen in Ihrem laufzeitfähigen SDK enthalten kann.
- Dies wird manchmal auch als statisch verknüpftes oder statisches SDK bezeichnet.
Shim: Eine Jetpack-Bibliothek für die abstrakte Kommunikation zwischen Prozessen oder der Inter-Process-Kommunikation (IPC) gerecht werden app-SDK-Schnittstelle.

SDK-Laufzeitarchitektur

Die SDK Runtime verwendet eine Typ client-server des Modells.

Der Hauptunterschied besteht darin, (App) und der „Server“ (runtime-enabled SDKs) auf demselben Gerät ausgeführt werden. Diese Kommunikation erfolgt prozessübergreifend.

Zur Bewältigung dieser Herausforderungen haben wir Jetpack-Bibliotheken und -Tools zur Vereinfachung Integration des App-SDK in die SDK-Laufzeit:

Shim-Bibliothek:Mit der Wrapper-Bibliothek (oder Shim) lassen sich abstrahieren. prozessübergreifende Kommunikation oder Inter-Process-Kommunikation (IPC). Außerdem damit die App-SDK-Oberfläche nicht verändert wird.
Backcompat-Bibliothek:Diese Bibliothek übernimmt die Abwärtskompatibilität, Prüfen Sie, ob Ihr SDK kompatibel ist, unabhängig davon, ob die SDK-Laufzeit ob sie verfügbar sind oder nicht.
UI-Bibliothek:Wir stellen auch Bibliotheken für die Remote-Präsentation bereit, wie das Abrufen der Benutzeroberfläche aus dem laufzeitfähigen SDK oder das Anpassen der Größe und des Layouts Aufrufe.

SDK-Laufzeitarchitektur – Übersicht — Diagramm, das zeigt, wie eine App über verschiedene Bibliotheken mit dem laufzeitfähigen SDK interagiert.

Änderungen am Installationsablauf

Wenn du dein laufzeitfähiges SDK in Android Studio oder anderen Tools erstellst, erstelle ein Android SDK-Bundle ASB, ein Publikationsformat für laufzeitfähige SDKs.

bundletool verarbeitet das ASB um ein APK für dein laufzeitfähiges SDK zu erstellen: Dieses separate APK enthält SDK-Code, aber kein App-Code

Die Manifestdatei der App deklariert eine Abhängigkeit vom Namen Ihres laufzeitfähigen SDK. und Version. Diese Abhängigkeit wird von der Installationsprogramm-App behoben.

Sobald das SDK-APK vom Installationsprogramm abgerufen wurde, beginnt die Installation mit dem SDK-APK-Installation. Bei Erfolg wird das APK der App installiert.

Der Ablauf ist anders, wenn die App unter Android 13 und niedriger installiert ist, und in Geräte, die die SDK Runtime nicht unterstützen. In diesem Szenario installiert der Store ein einzelnes APK, das sowohl Ihr laufzeitfähiges SDK als auch den App-Code enthält. Weitere Informationen findest du im Abschnitt zum Vertrieb.

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 Runtime in Android 14 eingeführt wurde, früheren Versionen ohne zusätzlichen Aufwand für SDK- oder App-Entwickler.

Zur Gewährleistung der Abwärtskompatibilität unter Android 13 und niedriger haben wir eine Jetpack-Bibliothek eingeführt, mit der Ihr laufzeitfähiges SDK unabhängig von der Geräteunterstützung für SDK Runtime nahtlos ausgeführt werden kann.

Wenn Sie diese Anleitung befolgen, ist Ihr laufzeitfähiges SDK standardmäßig abwärtskompatibel. Sie müssen nichts weiter unternehmen.

Wir heben in den jeweiligen Phasen hervor, welche Aktionen mit der Abwärtskompatibilität verbunden sind. Grundsätzlich sollten Sie jedoch darauf achten, dass Sie die richtigen Abhängigkeiten deklariert haben und gegebenenfalls die *Compat-Klassen verwenden.

Vorhandene SDKs migrieren

Wenn Sie ein vorhandenes SDK zur Laufzeit migrieren möchten, haben Sie Ihre gesamte Codebasis auf einmal refaktorieren. Stattdessen können Sie die vorhandene SDK-Logik schrittweise zum neuen laufzeitfähigen SDK migrieren.

Wir empfehlen die folgenden drei Phasen, um ein vorhandenes SDK zum SDK zu migrieren Laufzeit:

Erstellen eines laufzeitfähigen SDK für den Übergangszeitraum mit einem umfassenden, laufzeitfähigen SDK So können Sie die Geschäftslogik schrittweise von Ihrem bestehenden SDK migrieren und eine Testplattform für A/B-Tests erhalten.
Die gesamte vorhandene SDK-Geschäftslogik in einen ständigen Zustand mit einem Gegenstück zu einem Thin Runtime-Aware SDK verschieben, um die App-Migration zu vereinfachen
Unterstützung interessierter Apps durch vollständige Migration, um Ihr laufzeitfähiges SDK direkt ohne ein Thin Runtime-Aware SDK zu nutzen

Phase 1 – Übergangsphase: Thick laufzeitfähiges SDK

Sie können damit beginnen, einen Teil Ihrer Geschäftslogik in Ihrem laufzeitfähigen SDK beizubehalten. Wir nennen dies ein „dickes“, laufzeitfähiges SDK oder einen In-App-Wrapper.

Auf diese Weise können Sie alle oder einige Funktionen Ihres SDK im eine statische App-Bibliothek und ein neu erstelltes laufzeitfähiges SDK.

So können Sie Ihre Anwendungsfälle schrittweise zu laufzeitfähigen SDK und testen Sie Ihr laufzeitfähiges SDK mit Ihrem vorhandenen SDK.

In dieser Phase muss der App-Entwickler nichts an der Art und Weise ändern, Ihr SDK verwenden, da es Ihre statische App-Bibliothek (runtime-aware SDK) ist, die die Arbeit erledigt um Ihr laufzeitfähiges SDK zu nutzen.

Die App ruft ein statisches, laufzeitfähiges SDK auf, das eine Übersetzungsebene zum Aufrufen des laufzeitfähigen SDK sowie anderer darin enthaltener Geschäftslogik enthalten kann. — Die App ruft ein statisches, laufzeitfähiges SDK auf, das eine Übersetzungsebene enthalten kann, um das laufzeitfähige SDK sowie andere darin enthaltene Geschäftslogik aufzurufen.

Phase 2: Stabiler Zustand: laufzeitfähiges Thin SDK

Im Gegensatz zum dicken, laufzeitabhängigen SDK kann ein Thin Wrapper oder ein Thin-SDK (Thin RA_SDK), enthält nur API-Übersetzung und laufzeitfähige SDK-Aufrufe in Ihrem statisch verknüpften Bibliotheks-SDK.

Jetzt sollten Sie Ihren gesamten SDK-Code aus Ihrem in Ihr laufzeitfähiges SDK einbinden.

App-Entwickler müssen in Phase 1 keine Änderungen vornehmen, da Ihre In-App- Das Thin Runtime-Aware SDK verarbeitet Aufrufe an dein laufzeitfähiges SDK innerhalb des SDK. Laufzeit:

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

Phase 3: Vollständige Migration

In dieser letzten Phase haben Sie alle Funktionen Ihres SDK in die laufzeitfähiges SDK. Außerdem wurden alle statischen Bibliotheken aus der App entfernt.

Jetzt müssen Ihre App-Clients Ihre Bibliotheken nicht mehr in ihre Builds, aber listen Sie nur die SDK-Abhängigkeiten im Manifest auf und fügen Sie die SDK-Aufrufe im App-Code

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

Architektur der vollständigen Migrationsphase, in der das laufzeitfähige SDK direkt durch den Anzeigencode der App aufgerufen wird.

Einführung

Schritt 2: Entwicklungsumgebung einrichten