Créer et utiliser un SDK compatible avec l'environnement d'exécution

Concepts clés

Cette section explique l'architecture SDK Runtime, comment installer les SDK compatibles avec l'environnement d'exécution, la rétrocompatibilité et comment migrer les SDK existants vers SDK Runtime.

Glossaire

• SDK compatible avec l'environnement d'exécution (RE-SDK) : SDK conçu pour s'exécuter dans l'environnement SDK Runtime et communiquer avec l'application via la communication entre processus (IPC).
• SDK compatible avec le Runtime (RA SDK) : SDK non compatible avec le Runtime, associé statiquement à l'application, qui peut contenir votre code SDK existant ainsi que du nouveau code pour appeler votre SDK compatible avec le Runtime.
  • On parle aussi parfois de SDK à liaison statique ou de SDK statique.
• Shim : bibliothèque Jetpack qui permet d'abstraire la communication entre les processus ou la communication interprocessus (IPC, inter-process communication) et de conserver la même interface application-SDK.

Architecture SDK Runtime

Le SDK Runtime adopte un modèle de type client/serveur.

La principale différence réside dans le fait que le "client" (application) et le "serveur" (SDK compatibles avec l'exécution) s'exécutent sur le même appareil, et que cette communication se produit entre les processus.

Pour vous aider à relever ces défis, nous avons créé les bibliothèques et outils Jetpack suivants afin de simplifier l'intégration des applications et des SDK dans le SDK Runtime :

• Bibliothèque Shim : la bibliothèque wrapper (ou shim) permet d'abstraire la communication entre les processus ou la communication interprocessus (IPC). Il permet également de conserver la même interface entre l'application et le SDK.
• Bibliothèque Backcompat : cette bibliothèque gère la rétrocompatibilité, en s'assurant que votre SDK est compatible, que le SDK Runtime soit disponible ou non.
• Bibliothèque d'UI : nous fournissons également des bibliothèques pour gérer la présentation à distance, comme la récupération de l'UI à partir du SDK compatible avec le runtime, ou le redimensionnement et la réorganisation des vues.

Modifications apportées au processus d'installation

Lorsque vous compilez votre SDK compatible avec l'environnement d'exécution dans Android Studio ou d'autres outils, vous créez un Android SDK Bundle (ASB), un format de publication pour les SDK compatibles avec l'environnement d'exécution.

bundletool traite l'ASB pour produire un APK pour votre SDK compatible avec l'environnement d'exécution. Cet APK distinct contient le code de votre SDK, mais pas le code de l'application.

Le fichier manifeste de l'application déclare une dépendance vis-à-vis du nom et de la version de votre SDK compatible avec l'environnement d'exécution, et cette dépendance est résolue par l'application d'installation.

Une fois que l'APK du SDK est fourni par le programme d'installation, l'installation commence par l'installation de l'APK du SDK. Si l'opération réussit, le fichier APK de l'application est installé.

Le flux est différent si l'application est installée sur Android 13 ou une version antérieure, et sur des appareils qui ne sont pas compatibles avec le SDK Runtime. Dans ce scénario, le Play Store installe un seul APK contenant à la fois votre SDK compatible avec l'environnement d'exécution et le code de l'application. Pour en savoir plus, consultez la section sur la distribution.

Chaque fois qu'une application dépend de ce SDK en production, la plate-forme de téléchargement d'applications crée l'APK du SDK approprié à partir de cet ASB et l'installe.

Rétrocompatibilité

Étant donné que le SDK Runtime a été introduit dans Android 14, nous devions prendre en charge les versions antérieures sans générer de surcharge pour les développeurs de SDK ou d'applications.

Pour gérer la rétrocompatibilité sur Android 13 et les versions antérieures, nous avons introduit une bibliothèque Jetpack qui peut exécuter de manière transparente votre SDK compatible avec le runtime, quelle que soit la compatibilité de l'appareil avec SDK Runtime.

En suivant ce guide, vous rendez votre SDK compatible avec l'environnement d'exécution par défaut. Aucune autre étape n'est requise.

Nous mettons en évidence les actions liées à la rétrocompatibilité aux étapes concernées, mais en termes généraux, vous devez vous assurer d'avoir déclaré les bonnes dépendances et d'utiliser les classes *Compat chaque fois que cela est possible.

Migrer les SDK existants

Si vous disposez d'un SDK existant que vous souhaitez migrer vers le Runtime, vous n'avez pas besoin de refactoriser l'intégralité de votre code en une seule fois. Vous pouvez choisir de migrer la logique du SDK existant de manière incrémentielle vers le nouveau SDK compatible avec le Runtime.

Nous vous recommandons de suivre les trois phases suivantes pour migrer un SDK existant vers le SDK Runtime :

1. Compiler un SDK compatible avec l'environnement d'exécution de la période de transition, ainsi qu'un SDK épais homologue compatible avec l'environnement d'exécution. Cela vous permet de migrer progressivement la logique métier depuis votre SDK existant et de disposer d'une plate-forme de test pour les tests A/B.
2. Déplacer toute la logique métier du SDK existant vers un état stable avec un SDK fin homologue compatible avec l'environnement d'exécution pour faciliter la migration des applications
3. Aider les applications intéressées à effectuer une migration complète pour consommer directement votre SDK compatible avec l'environnement d'exécution sans SDK léger compatible avec l'environnement d'exécution

Phase 1 : Période de transition : SDK épais compatible avec le runtime

Vous pouvez commencer par choisir de conserver une partie de votre logique métier dans votre SDK compatible avec l'exécution. Nous appelons cela un SDK ou un wrapper intégré à l'application, qui est "épais" et tient compte du runtime.

Cette approche vous permet de conserver tout ou partie des fonctionnalités de votre SDK dans la bibliothèque d'application statique, en plus d'un SDK compatible avec l'environnement d'exécution nouvellement créé.

Cela vous permet de migrer progressivement vos cas d'utilisation vers le SDK compatible avec l'environnement d'exécution et de tester votre SDK compatible avec l'environnement d'exécution par rapport à votre SDK existant.

Au cours de cette phase, le développeur de l'application n'a rien à changer dans la façon dont il consomme votre SDK, car c'est votre bibliothèque d'application statique (SDK compatible avec le runtime) qui effectue le travail nécessaire pour consommer votre SDK compatible avec le runtime.

Phase 2 : État stable : SDK léger compatible avec le runtime

Contrairement au SDK épais compatible avec le runtime, un wrapper fin ou un SDK fin compatible avec le runtime (thin RA_SDK) ne contient que du code d'appel de SDK compatible avec le runtime et de traduction d'API dans votre SDK de bibliothèque lié statiquement.

À ce stade, vous devriez avoir migré tout votre code SDK hors de votre SDK de bibliothèque d'application statique et dans votre SDK compatible avec le runtime.

Les développeurs d'applications n'ont pas besoin d'apporter de modifications par rapport à la phase 1, car votre SDK léger intégré à l'application et compatible avec l'environnement d'exécution gère l'appel à votre SDK compatible avec l'environnement d'exécution dans le SDK Runtime.

Phase 3 : Migration complète

Dans cette dernière phase, vous avez migré toutes les fonctionnalités de votre SDK vers le SDK compatible avec l'exécution et supprimé toutes les bibliothèques statiques de l'application.

À ce stade, les clients de votre application n'ont plus besoin d'inclure vos bibliothèques dans leurs builds. Ils doivent uniquement lister les dépendances du SDK dans le fichier manifeste et inclure les appels du SDK dans le code de leur application.

Les appels de SDK sont acheminés par le système vers le SDK Runtime, où votre SDK compatible avec l'environnement d'exécution est automatiquement chargé.

arrow_back_iosIntroduction

Étape 2 : Configurez votre environnement de développementarrow_forward_ios