Runtime-fähiges SDK erstellen und nutzen

1
 Key concepts
2
 Set up your development environment
3
 Build an RE SDK
4
 Consume the RE SDK
5
 Testing, and building for distribution

Wichtige Konzepte

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

Glossar

  • Laufzeitfähiges SDK (RE SDK): Ein SDK, das für die Ausführung in der SDK-Laufzeitumgebung entwickelt wurde und über die prozessübergreifende Kommunikation (Inter-Process Communication, IPC) mit der App kommuniziert.
  • Laufzeitfähiges SDK: Ein nicht laufzeitfähiges SDK, das statisch mit der App verknüpft ist und sowohl Ihren vorhandenen SDK-Code als auch neuen Code enthalten kann, um Ihr laufzeitfähiges SDK aufzurufen.
    • 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 Communication (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“ (die App) und der „Server“ (die SDKs mit aktivierter Laufzeit) auf demselben Gerät ausgeführt werden und die 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 die SDK-Laufzeit zu vereinfachen:

  • Shim-Bibliothek:Die Wrapper-Bibliothek (oder Shim) hilft bei der Abstraktion der prozessübergreifenden Kommunikation oder der Inter-Process Communication (IPC). Außerdem wird so die gleiche App-SDK-Schnittstelle beibehalten.
  • Backcompat-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 SDK mit aktivierter Laufzeit oder zum Anpassen der Größe und Neugestalten von Ansichten.
SDK-Laufzeit – Architekturübersicht
Diagramm, das zeigt, wie eine App über verschiedene Bibliotheken mit dem laufzeitfähigen SDK interagiert.

Änderungen am Installationsablauf

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 von Ihrem laufzeitfähigen SDK-Namen und Ihrer SDK-Version deklariert. Diese Abhängigkeit wird von der Installations-App aufgelöst.

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

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

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

Abwärtskompatibilität

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

Um die Abwärtskompatibilität auf Android 13 und niedriger zu gewährleisten, haben wir eine Jetpack-Bibliothek eingeführt, mit der Ihr SDK mit Laufzeit 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 Aktionen im Zusammenhang mit der Abwärtskompatibilität erforderlich sind. Im Allgemeinen sollten Sie jedoch darauf achten, dass Sie die richtigen Abhängigkeiten deklariert haben und die *Compat-Klassen verwenden, wann immer dies möglich ist.

Vorhandene SDKs migrieren

Wenn Sie ein vorhandenes SDK zur Laufzeit migrieren möchten, müssen Sie nicht den gesamten Code auf einmal umgestalten. Stattdessen können Sie die vorhandene SDK-Logik inkrementell in das neue laufzeitfähige SDK migrieren.

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

  1. Entwicklung eines laufzeitfähigen SDK für den Übergangszeitraum zusammen mit einem entsprechenden Thick-SDK, das die Laufzeit berücksichtigt. So können Sie die Geschäftslogik schrittweise aus Ihrem vorhandenen SDK migrieren und haben eine Testplattform für A/B-Tests.
  2. Die gesamte vorhandene SDK-Geschäftslogik wird in einen stabilen Zustand überführt. Außerdem wird ein schlankes, laufzeitfähiges SDK bereitgestellt, um die App-Migration zu erleichtern.
  3. Unterstützung von interessierten Apps bei der vollständigen Migration, damit sie Ihr laufzeitfähiges SDK direkt ohne ein schlankes laufzeitfähiges SDK verwenden können

Phase 1: Übergangszeitraum: Thick Runtime-Aware SDK

Sie können damit beginnen, einen Teil Ihrer Geschäftslogik in Ihrem laufzeitfähigen SDK zu behalten. Wir nennen das ein „Runtime-Aware SDK“ oder einen „In-App-Wrapper“.

So können Sie alle oder einige Funktionen Ihres SDKs in der statischen App-Bibliothek behalten und gleichzeitig ein neues laufzeitfähiges SDK erstellen.

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

In dieser Phase muss der App-Entwickler nichts daran ändern, wie er Ihr SDK verwendet, da Ihre statische App-Bibliothek (laufzeitfähiges SDK) die erforderlichen Schritte ausführt, um Ihr laufzeitfähiges SDK zu verwenden.

Die App ruft ein statisches, laufzeitfähiges SDK in sich selbst auf, das eine Übersetzungsebene enthalten kann, um das laufzeitfähige SDK sowie andere Geschäftslogik darin aufzurufen.
Die App ruft ein statisches, laufzeitfähiges SDK in sich selbst auf, das eine Übersetzungsebene enthalten kann, um das laufzeitfähige SDK sowie andere Geschäftslogik aufzurufen.

Phase 2 – Steady State: schlankes, laufzeitfähiges SDK

Im Gegensatz zum umfangreichen laufzeitfähigen SDK enthält ein schlanker Wrapper oder ein schlankes laufzeitfähiges SDK (Thin RA_SDK) nur API-Übersetzungs- und laufzeitfähigen SDK-Aufrufcode in Ihrem statisch verknüpften Bibliotheks-SDK.

Zu diesem Zeitpunkt sollten Sie den gesamten SDK-Code aus dem statischen App-Bibliotheks-SDK in das SDK mit Laufzeitfunktion migriert haben.

App-Entwickler müssen in Phase 1 keine Änderungen vornehmen, da Ihr schlankes, laufzeitfähiges In-App-SDK Aufrufe in Ihr laufzeitfähiges SDK in der SDK-Laufzeitumgebung verarbeitet.

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

Phase 3: Vollständige Migration

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

An diesem Punkt müssen Ihre App-Clients Ihre Bibliotheken nicht mehr in ihre Builds einbeziehen, 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 in die SDK-Laufzeit weitergeleitet, in der Ihr laufzeitfähiges SDK automatisch geladen wird.

Architektur der vollständigen Migrationsphase, in der der Anzeigencode der App das laufzeitfähige SDK direkt aufruft.
Architektur der vollständigen Migrationsphase, in der der Anzeigencode der App das laufzeitfähige SDK direkt aufruft.


Einführung

Schritt 2: Entwicklungsumgebung einrichten