| Key concepts | Set up your development environment | Build an RE SDK | Consume the RE SDK | Testing, and building for distribution |
Conceptos clave
En esta sección, se explica la arquitectura del entorno de ejecución de SDK, cómo se instalan los SDKs habilitados para el entorno de ejecución, la retrocompatibilidad y cómo migrar los SDKs existentes al entorno de ejecución de SDK.
Glosario
- SDK habilitado para el entorno de ejecución (SDK habilitado para el entorno de ejecución): Es un SDK diseñado para ejecutarse en el entorno de ejecución de SDK. entorno y comunicarse con la app a través de la comunicación entre procesos de Google Cloud (IPC).
- SDK compatible con el entorno de ejecución (SDK de RA): Un SDK no habilitado para el entorno de ejecución, vinculado a la app
de forma estática, que puede contener tu código de SDK existente y un código nuevo para llamar al SDK habilitado para el entorno de ejecución.
- A veces, esto también se conoce como vinculado de forma estática o SDK estático.
- Shim: Es una biblioteca de Jetpack que permite la comunicación abstracta en toda la o comunicación entre procesos (IPC), y mantener la misma app-SDK.
Arquitectura del entorno de ejecución de SDK
El entorno de ejecución de SDK adopta un Tipo client-server del modelo.
La principal diferencia es que el "cliente" (app) y el "servidor" (runtime-enabled SDK) se ejecutan en el mismo dispositivo, y esta comunicación se produce en todos los procesos.
Para ayudar con estos desafíos, creamos lo siguiente Bibliotecas y herramientas de Jetpack para simplificar Integración del SDK de la app dentro del entorno de ejecución de SDK:
- Biblioteca de Shim: La biblioteca de wrapper (o corrector de compatibilidad) ayuda a simplificar. entre procesos o entre procesos (IPC). También ayuda a mantener la misma interfaz del SDK de la app.
- Biblioteca Backcompat: Esta biblioteca controla la retrocompatibilidad, lo que hace que asegurarte de que tu SDK sea compatible, independientemente de si el entorno de ejecución de SDK están disponibles o no.
- Biblioteca de la IU: También proporcionamos bibliotecas para controlar la presentación remota, como recuperar la IU del SDK habilitado para el entorno de ejecución o cambiar el tamaño y rediseñar vistas.
Cambios en el flujo de instalación
Cuando compilas tu SDK habilitado para el entorno de ejecución en Android Studio u otras herramientas, puedes crear un Paquete del SDK de Android (ASB), un formato de publicación para SDKs habilitados para el entorno de ejecución.
bundletool procesa el ASB para producir un APK para el SDK habilitado para el entorno de ejecución. Este APK independiente contiene tu el código del SDK, pero no el de la app.
El archivo de manifiesto de la app declara una dependencia del nombre del SDK habilitado para el entorno de ejecución. y la versión, y la app del instalador resuelve esta dependencia.
Una vez que el instalador obtiene el APK del SDK, la instalación comienza con Instalación del APK del SDK. Si el proceso es satisfactorio, el siguiente paso es instalar el APK de la app.
El flujo es diferente si la app está instalada en Android 13 y versiones anteriores, y en dispositivos que no admiten el entorno de ejecución de SDK. En este caso, la tienda instala un solo APK que contenga el SDK habilitado para el entorno de ejecución y el código de la app Lee la sección de distribución para obtener más información.
Cuando una aplicación depende de este SDK en producción, la tienda de aplicaciones el APK del SDK correcto de este ASB y lo instala.
Compatibilidad con versiones anteriores
Como el entorno de ejecución de SDK se introdujo en Android 14, necesitábamos admitir a las versiones anteriores sin generar una sobrecarga para los desarrolladores de SDK o apps.
Para ofrecer retrocompatibilidad en Android 13 y versiones anteriores, presentamos una biblioteca de Jetpack que puede ejecutar sin problemas el SDK habilitado para el entorno de ejecución, independientemente de la compatibilidad del dispositivo con ese entorno.
Si sigues esta guía, el SDK habilitado para el entorno de ejecución será retrocompatible de forma predeterminada, y no deberás realizar ninguna otra acción.
Destacamos las acciones conectadas con la retrocompatibilidad en etapas relevantes, pero, en términos generales, debes asegurarte de haber declarado las dependencias correctas y de usar las clases *Compat cuando corresponda.
Migra los SDKs existentes
Si tienes un SDK existente que quieras migrar al entorno de ejecución, refactorizar toda tu base de código de una sola vez. En su lugar, puedes optar por migrar la lógica del SDK existente de forma incremental al nuevo SDK habilitado para el entorno de ejecución.
Recomendamos las siguientes tres fases para migrar un SDK existente al SDK Tiempo de ejecución:
- Compilar un SDK habilitado para el entorno de ejecución para el período de transición junto con un SDK de gran tamaño adaptado al entorno de ejecución equivalente Esto te permite migrar de forma incremental la lógica empresarial de tu SDK existente y brindarte una plataforma de pruebas para pruebas A/B.
- Traslado de toda la lógica empresarial del SDK existente a un estado estable prolongado con un SDK liviano equivalente compatible con el entorno de ejecución para facilitar la migración de apps.
- Brindar asistencia a apps interesadas con una migración completa para consumir tu SDK habilitado para el entorno de ejecución directamente sin un SDK delgado adaptado al entorno de ejecución
Fase 1 - Período de transición: SDK amplio adaptado al entorno de ejecución
Para comenzar, puedes optar por mantener parte de tu lógica empresarial en el SDK adaptado al entorno de ejecución. Lo llamamos SDK grueso adaptado al entorno de ejecución o wrapper integrado en la app.
Este enfoque te permite mantener todas o algunas de las capacidades de tu SDK estática de la app, junto con un SDK recién compilado habilitado para el entorno de ejecución.
Esto te permite migrar de forma incremental tus casos de uso al entorno habilitado y para probar el SDK habilitado para el entorno de ejecución con el SDK existente.
En esta fase, el desarrollador de la app no necesita cambiar nada en la forma consumir tu SDK, ya que es tu biblioteca estática de apps (SDK adaptado al entorno de ejecución) la que hace el trabajo. necesario para consumir tu SDK adaptado al entorno de ejecución.
Fase 2 - Estado estable: SDK ligero adaptado al entorno de ejecución
A diferencia del SDK pesado adaptado al entorno de ejecución, un wrapper delgado o un SDK delgado adaptado al entorno de ejecución (RA_SDK delgado), solo contiene traducción de API y llamadas a SDK habilitados para el entorno de ejecución en tu SDK de biblioteca vinculada estáticamente.
En esta etapa, ya deberías haber migrado todo el código del SDK de tu de la biblioteca estática de la app y al SDK habilitado para el entorno de ejecución.
Los desarrolladores de apps no tienen que hacer ningún cambio desde la fase 1 porque El SDK delgado adaptado al entorno de ejecución controla las llamadas a tu SDK habilitado para el entorno de ejecución dentro del SDK. Entorno de ejecución.
Fase 3: Migración completa
En esta fase final, migraste todas las capacidades de tu SDK al habilitado para el entorno de ejecución y quitaste todas las bibliotecas estáticas de la app.
En este punto, los clientes de tu app ya no necesitan incluir tus bibliotecas en sus compilaciones, pero solo mencionar las dependencias del SDK en el manifiesto e incluir el Llamadas al SDK en el código de la app.
El sistema enruta las llamadas al SDK al entorno de ejecución de SDK, donde el SDK habilitado para el entorno de ejecución se carga automáticamente.
