| 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 de RE): Es un SDK creado para ejecutarse en el entorno de ejecución de SDK y comunicarse con la app a través de la comunicación entre procesos (IPC).
- SDK compatible con el entorno de ejecución (SDK RA): Es un SDK no habilitado para el entorno de ejecución, vinculado a la app de forma estática, que puede contener el código de tu SDK existente, así como código nuevo para llamar a tu SDK habilitado para el entorno de ejecución.
- A veces, también se conoce como vinculado de forma estática o SDK estático.
- Shim: Es una biblioteca de Jetpack que ayuda a abstraer la comunicación entre procesos o la comunicación entre procesos (IPC) y a mantener la misma interfaz de SDK de la app.
Arquitectura del entorno de ejecución de SDK
El entorno de ejecución de SDK adopta un tipo de modelo cliente-servidor.
La principal diferencia es que el "cliente" (la app) y el "servidor" (los SDKs habilitados para el tiempo de ejecución) se ejecutan en el mismo dispositivo, y esta comunicación se produce entre procesos.
Para ayudarte con estos desafíos, creamos las siguientes bibliotecas y herramientas de Jetpack para simplificar la integración de SDKs en apps dentro del entorno de ejecución de SDKs:
- Biblioteca de shim: La biblioteca de wrapper (o shim) ayuda a abstraer la comunicación entre procesos o la comunicación entre procesos (IPC). También ayuda a mantener la misma interfaz de SDK de la app.
- Biblioteca de retrocompatibilidad: Esta biblioteca controla la retrocompatibilidad y garantiza que tu SDK sea compatible independientemente de si el entorno de ejecución de SDK está disponible o no.
- Biblioteca de IU: También proporcionamos bibliotecas para controlar la presentación remota, como la recuperación de la IU del SDK habilitado para el tiempo de ejecución o el cambio de tamaño y el nuevo diseño de las vistas.
Cambios en el flujo de instalación
Cuando compilas tu SDK habilitado para el entorno de ejecución en Android Studio o en otras herramientas, creas un paquete de SDK de Android (ASB), un formato de publicación para los SDKs habilitados para el entorno de ejecución.
Bundletool procesa el ASB para generar un APK para tu SDK habilitado para el entorno de ejecución. Este APK independiente contiene el código de tu SDK, pero no el de la app.
El archivo de manifiesto de la app declara una dependencia del nombre y la versión de tu SDK habilitado para el entorno de ejecución, y la app del instalador resuelve esta dependencia.
Una vez que el instalador obtiene el APK del SDK, comienza la instalación con la instalación del APK del SDK. Si se realiza correctamente, se instala 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 contiene tanto tu SDK habilitado para el tiempo de ejecución como el código de la app. Lee la sección de distribución para obtener más información.
Cada vez que una app depende de este SDK en producción, la tienda de aplicaciones crea el APK del SDK correcto a partir de este ASB y lo instala.
Compatibilidad con versiones anteriores
Como el entorno de ejecución de SDK se introdujo en Android 14, debíamos admitir versiones anteriores sin generar una sobrecarga para los desarrolladores de SDKs o apps.
Para controlar la retrocompatibilidad en Android 13 y versiones anteriores, presentamos una biblioteca de Jetpack que puede ejecutar sin problemas tu SDK habilitado para el tiempo de ejecución, independientemente de la compatibilidad del dispositivo con el entorno de ejecución de SDK.
Si sigues esta guía, tu SDK habilitado para el entorno de ejecución será compatible con versiones anteriores de forma predeterminada, y no tendrás que realizar ningún otro paso.
Destacamos las acciones relacionadas con la retrocompatibilidad en las etapas pertinentes, pero, en términos generales, debes asegurarte de haber declarado las dependencias correctas y de usar las clases *Compat siempre que sea aplicable.
Migra SDKs existentes
Si tienes un SDK existente que deseas migrar al entorno de ejecución, no es necesario que refactorices toda tu base de código de una sola vez. En cambio, 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 Runtime:
- Compilar un SDK habilitado para el entorno de ejecución con un período de transición junto con un SDK grueso y compatible con el entorno de ejecución. Esto te permite migrar de forma incremental la lógica empresarial desde tu SDK existente y te proporciona una plataforma de pruebas para las pruebas A/B.
- Trasladar toda la lógica empresarial existente del SDK a un estado estable junto con un SDK delgado y compatible con el entorno de ejecución para facilitar la migración de la app
- Brindamos asistencia a las apps interesadas con la migración completa para que consuman tu SDK habilitado para el entorno de ejecución directamente sin un SDK delgado que tenga conocimiento del entorno de ejecución.
Fase 1: Período de transición: SDK grueso que tiene en cuenta el tiempo de ejecución
Puedes comenzar por conservar parte de tu lógica empresarial en el SDK compatible con el tiempo de ejecución. A esto lo llamamos SDK grueso que reconoce el tiempo de ejecución o wrapper integrado en la app.
Este enfoque te permite conservar todas o algunas de las capacidades de tu SDK en la biblioteca estática de la app, junto con un SDK habilitado para el tiempo de ejecución recién compilado.
Esto te permite migrar de forma incremental tus casos de uso al SDK habilitado para el entorno de ejecución y probar tu SDK habilitado para el entorno de ejecución en comparación con tu SDK existente.
En esta fase, el desarrollador de la app no necesita cambiar nada en la forma en que consume tu SDK, ya que es tu biblioteca de apps estática (SDK compatible con el tiempo de ejecución) la que realiza el trabajo necesario para consumir tu SDK compatible con el tiempo de ejecución.
Fase 2: Estado estable: SDK delgado que tiene en cuenta el tiempo de ejecución
A diferencia del SDK grueso compatible con el entorno de ejecución, un wrapper delgado o un SDK delgado compatible con el entorno de ejecución (SDK delgado RA) solo contiene código de traducción de API y de llamada a SDK habilitado para el entorno de ejecución en tu SDK de biblioteca vinculado de forma estática.
En esta etapa, ya deberías haber migrado todo el código del SDK de tu SDK de biblioteca de la app estática a tu SDK habilitado para el tiempo de ejecución.
Los desarrolladores de apps no tienen que realizar ningún cambio desde la fase 1, ya que tu SDK delgado integrado en la app y compatible con el entorno de ejecución se encarga de llamar a tu SDK habilitado para el entorno de ejecución dentro del entorno de ejecución de SDK.
Fase 3: Migración completa
En esta fase final, migraste todas las capacidades del SDK al SDK habilitado para el tiempo 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, sino que solo deben enumerar las dependencias del SDK en el manifiesto e incluir las llamadas al SDK en el código de la app.
El sistema enruta las llamadas al SDK a través del entorno de ejecución de SDK, en el que se carga automáticamente tu SDK habilitado para el entorno de ejecución.
Paso 2: Configura tu entorno de desarrollo