Se usó la API de Cloud Translation para traducir esta página.

Descripción general del entorno de ejecución de SDK

La plataforma de Android usa el concepto de zona de pruebas de apps a fin de mantener límites sólidos de ejecución y seguridad para el código de apps, además de límites del proceso. Es común que las apps incluyan código de terceros, a menudo en forma de SDK, como SDK de anuncios o de estadísticas. Esta reutilización permite que los desarrolladores de apps se enfoquen en la diferenciación de sus apps, a la vez que aprovechan el trabajo de expertos en la materia para escalar con facilidad su ejecución más allá de lo que podrían hacer por su cuenta.

Al igual que la mayoría de los sistemas operativos, los SDKs de Android se ejecutan dentro de la zona de pruebas de la app host y heredan los mismos privilegios y permisos de esa app host, además de acceso a su memoria y almacenamiento. Si bien esta arquitectura permite que los SDKs y las apps se integren de manera flexible, también crea el potencial de recopilar y compartir datos no divulgados por los usuarios. Además, es posible que los desarrolladores de apps no sean del todo conscientes de la extensión de la funcionalidad de un SDK de terceros y de los datos a los que accede, lo que dificulta la recopilación de datos y las prácticas de uso compartido de su app.

En Android 14, agregamos una nueva función de plataforma que permite que los SDKs de terceros se ejecuten en un entorno de ejecución dedicado llamado entorno de ejecución de SDK. El entorno de ejecución de SDK proporciona las siguientes protecciones y garantías más sólidas en torno a la recopilación y el uso compartido de los datos de los usuarios:

Un entorno de ejecución modificado
Permisos bien definidos y derechos de acceso a los datos para SDKs

Estamos buscando activamente comentarios de la comunidad publicitaria de apps para dispositivos móviles sobre este diseño. También aceptamos comentarios de la comunidad de desarrolladores más amplia para ayudar a definir las iteraciones futuras del entorno de ejecución del SDK, incluida la compatibilidad con casos de uso adicionales.

Objetivos

La propuesta tiene los siguientes objetivos:

Reducir el acceso no divulgado y el uso compartido de los datos de app de un usuario con SDKs de terceros mediante el aislamiento de procesos y un control de acceso a datos y APIs bien definido Obtén más información sobre el aislamiento de procesos en una sección separada de este documento
Limitar el acceso de los SDKs únicos y persistentes con el objetivo de reducir el seguimiento no divulgado que hacen los SDKs de terceros del uso de apps por parte de un usuario
Acelerar la distribución de forma segura de las actualizaciones de SDKs para apps a través de la reducción de la carga de los desarrolladores y usuarios finales. Obtén más información sobre el modelo de distribución del SDK de confianza propuesto en otra sección de este documento
Ayudar a los desarrolladores de apps a comprender mejor las prácticas de acceso y uso compartido de datos de sus apps
Ayudar a los desarrolladores de SDKs a evitar alteraciones por parte de otros SDKs con el límite de ciertas construcciones de lenguaje no seguras, como el código JNI
Ayudar a los SDKs de anuncios a detectar y evitar el tráfico no válido y el fraude publicitario con un control total sobre las vistas remotas en las que se muestra contenido multimedia
Minimizar el impacto indebido de los desarrolladores de apps y SDKs tanto como sea posible

Los SDKs se ejecutan en un proceso aislado

El entorno de ejecución de SDK propuesto permite que los SDKs compatibles, a los que se hace referencia en el resto de este documento como SDKs habilitados para el entorno de ejecución, funcionen en un proceso separado para la app. La plataforma facilita la comunicación bidireccional entre el proceso de la app y su entorno de ejecución de SDK. Consulta la sección de comunicaciones de este documento para obtener más detalles. Los SDKs que no estén habilitados para el entorno de ejecución permanecerán en el proceso de la app como lo hacen actualmente. En los siguientes diagramas, se ilustran estos cambios:

Diagrama anterior que muestra todo lo que ejecuta el proceso de la app — Antes de agregarse al entorno de ejecución de SDK, el código de llamada del SDK, junto con los SDKs que reciben las llamadas de este código, residen en el proceso de la app.

Diagrama posterior que muestra los procesos divididos entre el proceso de la app y el proceso del entorno de ejecución del SDK — Después de agregarse al entorno de ejecución de SDK, el código de llamada del SDK, en el proceso en primer plano de la app, se comunica con las interfaces del SDK. Estas interfaces luego cruzan un límite de proceso en el proceso del entorno de ejecución de SDK para llamar a los SDKs.

Nuevo modelo de distribución confiable para SDKs

Esta separación propuesta del SDK y la app motiva otro concepto de separación, uno para la distribución del SDK y la app. Nuestra propuesta requiere un mecanismo de instalación y distribución confiable para garantizar que se instalen los SDKs correctos en el entorno de ejecución del SDK de una app. Esto ayuda a proteger a los usuarios y los desarrolladores pues evita que se carguen apps de los SDKs no válidos y, al mismo tiempo, permite que las tiendas de aplicaciones reduzcan de manera significativa la carga de distribución de SDKs de los desarrolladores.

Ya no es necesario vincular ni empaquetar los SDKs de forma estática junto con sus apps antes de subirlos a una tienda de aplicaciones para su distribución. En su lugar, se produce el siguiente proceso:

Los desarrolladores de SDKs pueden subir sus SDKs con versiones a las tiendas de apps, separados de las apps en sí.
Los desarrolladores de apps pueden especificar sus dependencias de SDK por versión o compilación, y subir una versión de la app que no incluya las dependencias reales de SDK.
Cuando un usuario descarga esta app, el proceso de instalación puede usar las dependencias del SDK especificadas en la app para descargarlas desde la tienda de aplicaciones.

Este mecanismo de distribución nuevo permite que los desarrolladores de SDKs realicen cambios no rotundos (es decir, no debe haber cambios en las APIs ni su semántica) en sus SDKs y los distribuyan a dispositivos sin la participación de los desarrolladores de apps. Estos cambios no rotundos de SDK se pueden implementar o revertir, sin necesidad de esperar a que los desarrolladores de apps vuelvan a compilar sus apps con los SDKs nuevos ni que los usuarios finales actualicen sus apps. Los desarrolladores de apps deberán actualizar los cambios rotundos, pero los desarrolladores de SDKs podrían enviar los cambios no rotundos más recientes y las correcciones de manera más rápida y uniforme a más personas, lo que minimizaría la compatibilidad de versión.

En los siguientes diagramas, se ilustran los cambios propuestos para la distribución de SDKs:

Diagrama de antes — Antes de la introducción del entorno de ejecución de SDK, los desarrolladores enviaban sus SDKs directamente a las apps.

Diagrama de después — Después de la introducción del entorno de ejecución de SDK, los desarrolladores de SDKs usaban una IU de carga de SDK para publicar sus SDKs en una tienda de aplicaciones. La tienda de aplicaciones se encargará de distribuir las apps, junto con cualquier dependencia del SDK, a los dispositivos de usuario final.

Cambios en la compilación, ejecución y distribución de SDKs y apps

Esta es una propuesta inicial para un entorno de ejecución de SDK y una tecnología de distribución flexibles. En las secciones que siguen, se propone una serie de cambios en las siguientes categorías generales:

Acceso: Permisos, memoria y almacenamiento
Ejecución: Lenguajes, cambios en el entorno de ejecución, ciclo de vida, procesamiento de contenido multimedia
Comunicaciones: De app a SDK y de SDK a SDK
Desarrollo: Cómo compilar, depurar y probar en este modelo
Distribución: Cómo distribuir, actualizar y revertir entre versiones de Android, apps y SDKs

En este documento, también se incluyen Preguntas frecuentes.

Esta es una propuesta de diseño inicial, y comprendemos que puede ser un cambio significativo para algunos miembros del ecosistema. Por eso, solicitamos activamente tus comentarios y te pedimos que los envíes usando la Herramienta de seguimiento de errores.

Acceso

Administrar la privacidad de un sistema implica administrar cómo distintas partes pueden acceder a diferentes recursos. Para cumplir con nuestra propuesta de valor de privacidad, proponemos actualizar el modelo para acceder a apps, SDKs y datos de usuarios para seguir el principio de privilegio mínimo y evitar el acceso no divulgado de datos potencialmente sensibles.

Permisos de SDK

Como un proceso separado, el entorno de ejecución de SDK tendrá su propio conjunto bien definido de permisos, en lugar de heredar los que el usuario otorgó a la app. Según una investigación preliminar de los permisos que usan los SDKs relacionados con anuncios, proponemos que los siguientes permisos sean accesibles para los SDKs en el entorno de ejecución de SDK de forma predeterminada:

INTERNET: Se refiere al acceso a Internet para poder comunicarse con un servicio web.
ACCESS_NETWORK_STATE: Se refiere al acceso a información sobre las redes.
READ_BASIC_PHONE_STATE: Accede a información sobre el estado del teléfono, por ejemplo, el tipo de red móvil.
Permisos para acceder a las APIs que preservan la privacidad, que proporcionan capacidades de publicidad principales sin necesidad de acceder a identificadores de apps múltiples.
AD_ID: Permite solicitar el ID de publicidad. También se verá restringido el acceso de la app a este permiso.

Estamos investigando si se pueden autorizar permisos adicionales y cómo hacerlo, lo que limitará el impacto en los usuarios finales desde una perspectiva de privacidad y usabilidad. Esperamos recibir comentarios sobre cualquier caso de uso que no se cumpla con este conjunto de permisos.

Memoria

El entorno de ejecución de SDK tiene su propio espacio de memoria aislado, ya que tiene su propio proceso. De forma predeterminada, esta estructura prohibiría el acceso de SDK al espacio de memoria de la app y la aplicación no podría acceder de manera similar al espacio de memoria del SDK. Proponemos mantener este comportamiento predeterminado para conservar el principio de privilegio mínimo.

Almacenamiento

El objetivo de esta propuesta es equilibrar la necesidad de que los SDK accedan al almacenamiento para funcionar con normalidad y minimizar el seguimiento entre apps y durante el proceso usando el almacenamiento continuo. Proponemos la siguiente actualización sobre cómo se accede al almacenamiento hoy:

Una app no podrá acceder directamente al almacenamiento de sus SDKs y viceversa.
Los SDKs no podrán acceder al almacenamiento externo del dispositivo.
Dentro de cada entorno de ejecución de SDK, parte del almacenamiento estará disponible para que accedan todos los SDKs, mientras que otra parte será privada de cada uno.

Al igual que el modelo de almacenamiento actual, el almacenamiento en sí no tendrá límites arbitrarios de tamaño. Los SDKs pueden usar el almacenamiento para almacenar recursos en caché. Este almacenamiento se borra periódicamente cuando el SDK no se ejecuta de forma activa.

Ejecución

Para garantizar un sistema privado entre apps, SDKs y usuarios, el contexto de ejecución en sí mismo (formatos de código, construcciones de lenguaje, APIs accesibles y datos del sistema) debe reforzar estos límites de privacidad o, al menos, no presentar oportunidades para eludirlos. Al mismo tiempo, deseamos preservar el acceso a la plataforma enriquecida y a la mayoría de las capacidades del entorno de ejecución que los SDK tienen actualmente. Aquí proponemos un conjunto de actualizaciones de entorno de ejecución para lograr este equilibrio.

Código

Android Runtime (ART) es el principal intérprete del código de Android (apps y SDKs), ya sea escrito en Kotlin o Java. La riqueza de ART y las construcciones de lenguaje que ofrece, junto con la verificabilidad que brinda en comparación con las alternativas (en un código nativo en particular), parecen equilibrar adecuadamente la funcionalidad y la privacidad. Proponemos que el código del SDK habilitado para el entorno de ejecución conste exclusivamente de código de bytes Dex, en lugar de compatibilidad con acceso de JNI.

Sabemos que existen casos de uso, como el de los paquetes empaquetados personalizados, que, en función del código nativo, se deberán reemplazar por una alternativa, como la versión integrada del SDK de Android de SQLite.

SELinux

En Android, cada proceso (incluidos los que se ejecutan como raíz) se ejecuta con un contexto de SELinux específico, lo que permite que el kernel administre el control de acceso a los servicios del sistema, archivos, dispositivos y otros procesos. A fin de preservar la mayoría de los casos de uso del SDK y minimizar la elusión de las protecciones de la privacidad en las que intentamos hacer progreso, proponemos las siguientes actualizaciones desde el contexto SELinux desde una app que no sea del sistema para el entorno de ejecución del SDK:

Se puede acceder a un conjunto limitado de servicios del sistema. (en proceso de diseño activo)
Los SDK solo pueden cargar y ejecutar el código en su APK.
Se puede acceder a un conjunto limitado de propiedades del sistema. (en proceso de diseño activo)

APIs

Se permite el uso de APIs de reflexión e invocación dentro del entorno de ejecución de SDK. Sin embargo, un SDK no podrá usar APIs de reflexión ni de invocación en otro SDK habilitado para el entorno de ejecución. En una actualización futura, compartiremos la propuesta completa de APIs prohibidas.

Además, las versiones recientes de la plataforma de Android restringen cada vez más el acceso a los identificadores persistentes para mejorar la privacidad. Para el entorno de ejecución de SDK, proponemos una limitación adicional del acceso a los identificadores que podrían usarse en el seguimiento entre apps.

Solo se puede acceder a las APIs de entorno de ejecución de SDK desde apps que se ejecutan en primer plano. Si intentas acceder a las APIs de SdkSandboxManager desde apps en segundo plano, se arrojará una SecurityException.

Por último, los SDKs habilitados para el entorno de ejecución no pueden usar las APIs de notificaciones para enviar notificaciones a los usuarios en ningún momento.

Ciclo de vida

Los SDKs de apps actualmente siguen el ciclo de vida de su app host, por lo que, cuando la app ingresa al primer plano o sale de él, se cierra o el sistema operativo fuerza su detención debido a la presión de la memoria, sus SDKs también lo hacen. Nuestra propuesta de separar los SDKs de una app en un proceso diferente implica los siguientes cambios en el ciclo de vida:

El usuario o el sistema operativo pueden finalizar la app. El entorno de ejecución de SDK finalizará automáticamente después de manera inmediata.
El sistema operativo puede cancelar el entorno de ejecución de SDK debido a, por ejemplo, la presión de la memoria o una excepción no controlada en un SDK.

Para Android 14, cuando una app está en primer plano, el entorno de ejecución de SDK se ejecuta en una prioridad alta y es poco probable que se cancele. Cuando la app pasa a segundo plano, la prioridad del proceso del entorno de ejecución de SDK disminuye y se convierte en apta para cancelarse. La prioridad del proceso del entorno de ejecución de SDK permanece baja incluso si la app vuelve al primer plano. En consecuencia, es muy probable que se cancele con la presión de memoria en comparación con la app.

Para Android 14 y versiones posteriores, las prioridades de proceso de la app y el entorno de ejecución de SDK están alineados. Las prioridades de proceso de ActivityManager.RunningAppProcessInfo.importance para la app y el entorno de ejecución de SDK deberían ser aproximadamente iguales.

En caso de que el entorno de ejecución de SDK se cancele mientras la app está activa (por ejemplo, si hay una excepción no controlada en el SDK), se pierde el estado del entorno de ejecución de SDK, incluidos los SDKs cargados previamente y las vistas remotas. El desarrollador de la app puede abordar la cancelación del entorno de ejecución de SDK mediante cualquiera de los siguientes métodos:
- La propuesta ofrece métodos de devolución de llamada de ciclo de vida relacionados a los desarrolladores de apps para detectar cuándo se produce la cancelación del entorno de ejecución de SDK.
- Si el entorno de ejecución de SDK se cancela mientras se están mostrando los anuncios, es posible que estos no funcionen como se espera. Por ejemplo, es posible que las vistas se inmovilicen en la pantalla y dejen de ser interactivas. La app puede quitar la vista de un anuncio si no afecta la experiencia del usuario.
- La app puede volver a intentar cargar los SDKs y solicitar anuncios.
- En el caso de Android 14, si el entorno de ejecución de SDK se cancela mientras tiene cargados SDKs y el desarrollador de la app no registró los métodos de devolución de llamada de ciclo de vida mencionados, la app se cancela de forma predeterminada. Solo los procesos de la app que cargaron SDKs se cancelan y finalizan con normalidad.
- Los objetos de Binder que muestra el SDK para comunicarse con él (como SandboxedSdk) arrojan una DeadObjectException si la app la usa.
Este modelo de ciclo de vida está sujeto a cambios en futuras actualizaciones.

En caso de fallas persistentes, el desarrollador de la app debe planificar una degradación elegante sin el SDK o notificar al usuario si este es indispensable para la funcionalidad principal de la app. Para obtener más detalles sobre esta interacción de app a SDK, consulta la sección de comunicaciones de este documento.

Los SDKs que no estén habilitados para el entorno de ejecución podrán seguir usando las primitivas estándar del SO disponibles para su app incorporada (incluidos servicios, actividades y transmisiones), mientras que los SDKs habilitados no podrán hacerlo.

Casos especiales

Los siguientes casos no son compatibles y pueden generar un comportamiento inesperado:

Si varias apps comparten el mismo UID, es posible que el entorno de ejecución de SDK no funcione correctamente. Puede que en el futuro se agregue compatibilidad con UID compartidos.
En el caso de las apps con varios procesos, el SDK se debe cargar en el proceso principal.

Renderización de contenido multimedia

Hay SDK que procesan contenido como texto, imágenes y video en una vista especificada por la app. Para lograr esto, proponemos un enfoque de procesamiento remoto en el que el SDK renderizará el contenido multimedia desde el entorno de ejecución del SDK, pero usa la API de SurfaceControlViewHost a fin de permitir lo siguiente: el contenido multimedia que se renderizará en una vista especificada por la app. Esto ofrece al SDK la capacidad de renderizar este contenido de manera privada para el usuario y, al mismo tiempo, ayuda a prevenir y detectar interacciones no válidas o fraudulentas con el contenido multimedia renderizado.

Los anuncios nativos, que no son renderizados por el SDK, sino por la app, serían compatibles con los SDKs en el entorno de ejecución de SDK. El proceso de recopilación de indicadores y recuperación de creatividades se realizaría de manera coherente con los anuncios no nativos. Esta es un área de investigación activa.

Los anuncios de video in-stream son los que se publican in-stream con un video y se muestran en un reproductor dentro de una app. Dado que el video se reproduce dentro de un reproductor en la app y no en la vista o el reproductor del SDK, el modelo de renderización difiere de otros formatos de anuncios. Estamos explorando de forma activa mecanismos para admitir la inserción de anuncios del servidor y basada en el SDK.

Estado del sistema

Buscamos minimizar el impacto en el estado del sistema que tiene el entorno de ejecución de SDK en los dispositivos del usuario final y estamos diseñando formas de hacerlo. Sin embargo, es probable que algunos dispositivos Android 14 de entrada con recursos del sistema muy limitados, como Android (edición Go), no admitan el entorno de ejecución de SDK debido al impacto en el estado del sistema. Pronto compartiremos los requisitos mínimos necesarios para usar correctamente el entorno de ejecución de SDK.

Comunicaciones

Dado que las apps y los SDK se ejecutan en el mismo proceso, la comunicación entre ellos es desinhibida y no mediada. Además, Android permite la comunicación entre apps incluso si la comunicación comienza y termina con los SDK. Este modelo de comunicación de flujo libre habilita varios casos de uso y, al mismo tiempo, presenta la posibilidad de uso compartido de datos no divulgado entre apps y entre SDK dentro y entre las apps. Proponemos las siguientes actualizaciones en este modelo de comunicación para lograr un equilibrio entre el valor de esa comunicación y el cumplimiento de los objetivos que declaramos.

App a SDK

La interfaz entre la app y el SDK es la ruta de comunicación más común de un SDK. La API de un SDK es donde reside la diferenciación y la innovación para el usuario. En este artículo, buscamos preservar la capacidad de los SDK de innovar y diferenciarse. En consecuencia, nuestra propuesta permite que los SDKs expongan las APIs a las apps y se aseguren de que estas se puedan beneficiar de toda esa innovación.

Dada la estructura del límite de procesos del entorno de ejecución de SDK, proponemos compilar una capa de ordenamiento, accesible dentro de la app, para llevar las llamadas a la API y las respuestas o las devoluciones de llamada a través de este límite entre la app y el SDK. Proponemos que los desarrolladores de SDKs definan la interfaz de esta capa de ordenamiento, y que la generen las herramientas oficiales de compilación de código abierto que desarrollaremos.

El objetivo de esta propuesta es quitar el trabajo de ordenamiento estándar de los desarrolladores de apps y SDKs y, al mismo tiempo, proporcionar flexibilidad para los desarrolladores de SDKs y asegurarnos de que el código del SDK se ejecute en el entorno de ejecución de SDK para lograr nuestros objetivos de privacidad. En este caso, el lenguaje de definición de la API y las herramientas tendrían que estar diseñados con tu entrada.

El modelo de interacción general sería el siguiente:

La app llama al SDK a través de la interfaz y pasa devoluciones de llamada.
El SDK satisface las solicitudes de forma asíncrona y responde mediante las devoluciones de llamada.
Esto se puede generalizar a cualquier modelo de publicador y suscriptor, lo que significa que una app puede suscribirse a eventos en el SDK con devoluciones de llamada, de modo que, cuando se produzcan los eventos, se activen las devoluciones de llamada.

Una consecuencia de la nueva estructura de procesos cruzados de esta propuesta es que hay dos ciclos de vida de procesos que se deben administrar: uno para la app en sí y otro para el entorno de ejecución del SDK. Nuestra propuesta busca automatizar el proceso tanto como sea posible para minimizar el impacto en los desarrolladores de apps y SDK. En el siguiente diagrama, se muestra un enfoque que consideramos:

Diagrama de secuencias que muestra las interacciones de app a SDK durante el inicio de la app y el SDK.

La plataforma expone APIs nuevas para que las apps carguen SDKs de forma dinámica en el proceso del entorno de ejecución de SDK, reciban notificaciones sobre los cambios en el estado del proceso y también interactúen con los SDKs cargados en el entorno de ejecución de SDK.

En el gráfico de la figura anterior, se muestra la comunicación de app a SDK en un nivel inferior, sin la capa de ordenamiento.

La app se comunica con el SDK que se ejecuta en el proceso del entorno de ejecución de SDK mediante los siguientes pasos:

Antes de que una app pueda interactuar con un SDK, primero solicita que la plataforma lo cargue. Para garantizar la integridad del sistema, las apps deberían especificar los SDKs que quieren cargar en su archivo de manifiesto, y esos SDKs serían los únicos permitidos.

El siguiente fragmento de código proporciona un ejemplo ilustrativo de la API:
```
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
    OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
```
El SDK recibe una notificación sobre la carga y muestra su interfaz. Esta interfaz se diseñó para que la use el proceso de la app. Para compartir la interfaz fuera del límite del proceso, se debe mostrar como un objeto IBinder.

En la guía de servicios vinculados, se detallan diferentes formas de proporcionar IBinder. Independientemente de la opción que elijas, esta debe ser coherente entre el SDK y la app que realiza la llamada. Los diagramas usan AIDL como ejemplo.
SdkSandboxManager recibe la interfaz IBinder y la muestra en la app.

La app obtiene el IBinder, lo convierte en la interfaz del SDK y llama a sus funciones:

IBinder binder = sandboxSdk.getInterface();
ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
mySdkInterface.something();

La app también puede procesar contenido multimedia desde el SDK con estos pasos:

Como se explica en la sección de renderización de contenido multimedia de este documento, para que una app obtenga un SDK para renderizar contenido multimedia en una vista, puede realizar una llamada a requestSurfacePackage() y recuperar el SurfaceControlViewHost.SurfacePackage adecuado.

El siguiente fragmento de código proporciona un ejemplo ilustrativo de la API:
```
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
        Executor executor,
        OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
```
Luego, la app podría incorporar el SurfacePackage que se muestra en SurfaceView a través de la API de setChildSurfacePackage en SurfaceView.

El siguiente fragmento de código proporciona un ejemplo ilustrativo de la API:
```
SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
```

Nuestra propuesta es que las APIs de IBinder y requestSurfacePackage() sean genéricas, y no que las apps puedan llamar directamente a ellas. En su lugar, se llamará a estas APIs con la referencia a la API generada que se analizó antes, en una capa de "corrección de compatibilidad" para alivianar el proceso de los desarrolladores de apps.

SDK a SDK

A menudo, es necesario que se comuniquen dos SDK en la misma app. Esto puede suceder cuando la arquitectura de un SDK determinado está compuesta por SDKs constituyentes y cuando dos SDKs de diferentes partes necesitan colaborar para satisfacer una solicitud de la app que realiza la llamada.

Hay dos casos clave que deben considerarse:

Cuando ambos SDKs están habilitados para el entorno de ejecución: En este caso, ambos SDKs se ejecutan en el entorno de ejecución con todas sus protecciones. Los SDKs no pueden comunicarse como lo hacen actualmente en una app. En consecuencia, se agregó una API en SdkSandboxController para permitir la recuperación de objetos SandboxedSdk para todos los SDKs cargados y habilitados para el entorno de ejecución. Esto permite que un SDK habilitado para el entorno de ejecución se comunique con otros SDKs cargados en el entorno de ejecución de SDK.
Cuando solo un SDK está habilitado para el entorno de ejecución:
- Si el SDK que realiza la llamada se ejecuta en la app, no funciona diferente de la app que llama al segundo SDK dentro del entorno de ejecución de SDK.
- Si el SDK que realiza la llamada se ejecuta dentro del entorno de ejecución de SDK, te sugerimos que expongas un método con el IBinder que se describe en la sección de app a SDK que el código escucha, procesa y responde con las devoluciones de llamada proporcionadas.
- Es posible que los SDKs de anuncios que no están habilitados para el entorno de ejecución no puedan registrarse ellos mismos. Te recomendamos que crees un SDK de mediador que incluya SDKs de socios o apps como dependencias directas de la app y que controle el registro. Este SDK de mediador establece la comunicación entre los SDKs que no están habilitados para el entorno de ejecución y otras dependencias de la app, y el mediador habilitado para el entorno de ejecución que funciona como adaptador.

El conjunto de atributos para la comunicación de SDK a SDK se dividió en las siguientes categorías:

Comunicación de SDK a SDK dentro del entorno de ejecución de SDK (disponible en la Versión preliminar para desarrolladores más reciente)
Comunicación de SDK a SDK entre la app y el entorno de ejecución de SDK (disponible en la Versión preliminar para desarrolladores más reciente)
Cómo deberían funcionar las vistas y la renderización remota para la mediación (propuesta en el desarrollo)

Se están estudiando los siguientes casos de uso a medida que se diseñan las primitivas:

Mediación y ofertas. Muchos SDKs de publicidad ofrecen una capacidad de mediación o de oferta en la que el SDK llama a otros SDKs distintos para una impresión de anuncios (mediación) o recopilación de indicadores para ejecutar una subasta (licitación). Por lo general, el SDK de coordinación llama a otros SDKs a través de un adaptador que proporcionó el mismo SDK. Debido a las primitivas anteriores, el SDK de coordinación (habilitado para el entorno de ejecución o no) debe poder acceder a todos los SDKs habilitados y de otros tipos para garantizar un funcionamiento normal. La renderización en este contexto es un área de investigación activa.
Descubrimiento de funciones. Algunos productos de SDK consisten en SDKs más pequeños que, a través de un proceso de descubrimiento entre SDKs, determinan el conjunto de atributos final que se expone al desarrollador de la app. Se espera que las primitivas de registro y descubrimiento permitan este caso de uso.
Modelos de suscripción de publicador. Algunos SDKs están diseñados para tener un publicador central de eventos al que se pueden suscribir otros SDKs o apps para recibir notificaciones mediante devoluciones de llamada. Las primitivas anteriores deben admitir este caso de uso.

App a app

En la comunicación de app a app, al menos uno de los dos procesos participantes es un SDK habilitado para el entorno de ejecución y es un vector potencial para compartir datos no divulgados. En consecuencia, el entorno de ejecución de SDK no puede establecer un canal de comunicación directo con ninguna app que no sea la aplicación cliente o con SDKs de otro entorno de ejecución de SDK creado para otra app. Esto se logra de la siguiente manera:

El SDK no puede definir componentes como <service>, <contentprovider> o <activity> en su manifiesto.
El SDK no puede publicar un ContentProvider ni realizar una transmisión.
El SDK puede iniciar una actividad que pertenezca a otra app, pero con límites sobre lo que se puede enviar en el intent. Por ejemplo, no se pueden agregar acciones adicionales ni personalizadas a este intent.
El SDK solo puede iniciarse o vincularse a una lista de entidades permitidas de servicios.
El SDK solo puede acceder a un subconjunto del sistema ContentProvider (como com.android.providers.settings.SettingsProvider), donde los datos obtenidos no tienen identificadores y no se pueden usar para crear una huella digital del usuario. Estas verificaciones también se aplican al acceso a ContentProvider con ContentResolver.
El SDK solo puede acceder a un subconjunto de receptores de emisión protegidos (como android.intent.action.AIRPLANE_MODE).

Etiquetas del manifiesto

Cuando se instala el SDK, PackageManager analiza el manifiesto del SDK y no lo instala si contiene etiquetas de manifiesto prohibidas. Por ejemplo, es posible que el SDK no defina componentes como <service>, <activity>, <provider> o <receiver>, y que no declare un <permission> en el manifiesto. Las etiquetas que fallan en la instalación no son compatibles con el entorno de ejecución de SDK. Las etiquetas que no fallan en la instalación, pero se ignoran en silencio, podrían admitirse en versiones futuras de Android.

Estas verificaciones también se pueden aplicar a través de cualquier herramienta de tiempo de compilación que use el SDK para crear el paquete de SDK y en el momento de subirlo a la tienda de aplicaciones.

Compatibilidad con actividades

Los SDK del entorno de ejecución de SDK no pueden agregar una etiqueta de actividad al archivo de manifiesto ni pueden iniciar sus propias actividades con Context.startActivity. En cambio, la plataforma crea las actividades para los SDKs cuando se solicita y las comparte con los SDKs.

La actividad de la plataforma es del tipo android.app.Activity. Esta comienza desde una de las actividades de la app y forma parte de la tarea de la app. FLAG_ACTIVITY_NEW_TASK no es compatible.

Para que un SDK inicie una actividad, debe registrar una instancia del tipo SdkSandboxActivityHandler, que se usa para notificar la creación de la actividad cuando la app llama a SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) para iniciarla.

El flujo de solicitud de una actividad se muestra en el siguiente gráfico.

Desarrollo

Un principio clave de esta propuesta es minimizar el impacto en el ecosistema de desarrolladores en la medida de lo posible. Esta propuesta ofrece a los desarrolladores un conjunto completo de herramientas de desarrollo para escribir, compilar y depurar apps y SDKs habilitados para el entorno de ejecución. Para garantizar la integridad de esta propuesta, se implementaron algunos cambios en la forma en que se configuran, crean y compilan las apps y los SDKs habilitados para el entorno de ejecución.

Autorización

Se actualizarán Android Studio y las herramientas relacionadas para que sean compatibles con el entorno de ejecución de SDK, lo que ayudará a garantizar que los desarrolladores hayan configurado correctamente sus apps y SDKs habilitados para el entorno de ejecución, y garantiza que las llamadas heredadas o no compatibles se actualicen a sus alternativas más recientes cuando sea relevante. Durante la fase de creación, nuestra propuesta requiere que los desarrolladores sigan algunos pasos.

Desarrolladores de apps

Las apps deberán especificar las dependencias del certificado de SDK y el SDK habilitado para el entorno de ejecución en su manifiesto. En nuestra propuesta, trataremos esto como la fuente de información del desarrollador de la app durante toda la propuesta. Por ejemplo:

Nombre: Es el nombre del paquete del SDK o la biblioteca.
Versión principal: Corresponde al código de la versión principal del SDK.
Resumen de certificados: Es el resumen de certificados de la compilación de SDK. Para una compilación determinada, proponemos que el desarrollador del SDK obtenga y registre este valor en la tienda de apps relevante.

Esto se aplica únicamente a los SDK distribuidos en la tienda de apps, independientemente de que estén habilitados para el entorno de ejecución o no. Las apps que vinculan SDK de forma estática usan mecanismos de dependencia actuales.

Dado nuestro objetivo de impacto mínimo para los desarrolladores, es importante aclarar que, una vez que se especifique un nivel de API de destino que admita el entorno de ejecución de SDK, los desarrolladores de apps solo deberán tener una compilación única, independientemente de que esa compilación se ejecute en dispositivos que sean o no compatibles con el entorno de ejecución de SDK.

Desarrolladores de SDK

En nuestro diseño propuesto, los desarrolladores de SDKs habilitados para el entorno de ejecución deben declarar explícitamente un nuevo elemento que represente el SDK o la entidad de biblioteca en el manifiesto. Además, se debería proporcionar un conjunto de valores similar al de la dependencia más una versión secundaria:

Nombre: Es el nombre del paquete del SDK o la biblioteca.
Versión principal: Corresponde al código de la versión principal del SDK.
Versión secundaria: Es el código de la versión secundaria del SDK.

Si los desarrolladores de SDKs habilitados para el entorno de ejecución tienen otros SDKs habilitados como dependencias de tiempo de compilación, es probable que necesiten declararlos de manera idéntica a la que haría un desarrollador de apps. Los SDKs habilitados para el entorno de ejecución que dependan de otros que no estén habilitados los vincularán de forma estática. Esto puede generar problemas que se detectarían en el tiempo de compilación o durante los pases de prueba si los SDKs que no están habilitados para el entorno de ejecución requieren una funcionalidad que no admite el entorno de ejecución de SDK o si deben ejecutarse en el proceso de la app.

Es probable que los desarrolladores de SDKs habilitados para el entorno de ejecución deseen seguir brindando compatibilidad con dispositivos que no están habilitados, como los que ejecutan Android 12 o versiones anteriores y, como se menciona en la sección Estado del sistema del documento, los dispositivos Android 14 básicos con recursos del sistema muy limitados. Estamos trabajando para garantizar que los desarrolladores de SDKs puedan retener una sola base de código para admitir entornos habilitados y no habilitados para el entorno de ejecución.

Compilaciones

Desarrolladores de apps

Se espera que los desarrolladores de apps experimenten pocos cambios en el paso de compilación. Las dependencias de SDK, ya sean distribuidas de forma local o en tiendas de aplicaciones (habilitadas para el entorno de ejecución o no), tendrán que existir en la máquina para el análisis con lint y las compilaciones. Proponemos que Android Studio abstraiga estos detalles del desarrollador de la app durante el uso normal para que el proceso sea lo más transparente posible.

Si bien se espera que una compilación de depuración incluya todo el código y los símbolos presentes en este tipo de compilación para su depuración, las compilaciones de lanzamiento pueden, de manera opcional, quitar todos los SDKs distribuidos en tiendas de aplicaciones (habilitados para el entorno de ejecución o no) del artefacto final.

Apenas empezamos con el diseño de esta fase; compartiremos más información a medida que tome forma.

Desarrolladores de SDK

Estamos trabajando en una ruta que garantice que las versiones de un SDK que estén habilitadas o no para el entorno de ejecución se puedan compilar en un solo artefacto para su distribución. Esto evitaría que los desarrolladores de apps necesiten admitir compilaciones separadas para las versiones habilitadas y no habilitadas para el entorno de ejecución de un SDK.

Al igual que para las apps, cualquier SDK de dependencia distribuido en tiendas de aplicaciones tendría que existir en la máquina para análisis con lint y compilaciones, y esperamos que Android Studio facilite esta posibilidad.

Pruebas

Desarrolladores de apps

Como se describe en nuestra propuesta, los desarrolladores de apps podrán probar sus apps en dispositivos con Android 14 como lo harían normalmente. Después de compilar la app, esta podría instalarse en un emulador o dispositivo habilitado para el entorno de ejecución. Este proceso de instalación garantizará que los SDK correctos se instalen en el entorno de ejecución de SDK del dispositivo o el emulador, ya sea con SDK extraídos de un repositorio de SDK remoto o almacenados en la caché del sistema de compilación.

Desarrolladores de SDK

Por lo general, los desarrolladores de SDK usan apps de prueba internas en dispositivos y emuladores para probar sus productos. Nuestra propuesta no cambia este enfoque, y la validación integrada en la app seguirá los mismos pasos que se detallan para los desarrolladores de apps anteriores, con un único artefacto de compilación para apps habilitadas y no habilitadas para el entorno de ejecución. Los desarrolladores de SDK podrán revisar su código independientemente de su presencia en el entorno de ejecución de SDK, aunque podría haber algunas limitaciones en las herramientas avanzadas de depuración y generación de perfiles. Esta es un área de investigación activa.

Distribución

Nuestra propuesta de diseño para la separación de una app de sus SDK creó la posibilidad de distribuir SDK en tiendas de apps. Esta es una posibilidad general, no exclusiva de una tienda. Los beneficios son claros:

Se garantiza la calidad y coherencia de los SDK.
Se optimiza el proceso de publicación para los desarrolladores de SDK.
Se agiliza el lanzamiento de actualizaciones de versiones secundarias de SDK para apps instaladas.

Para admitir la distribución de SDK, es probable que una tienda de apps necesite proporcionar la mayoría de las siguientes capacidades:

Un mecanismo para que los desarrolladores de SDKs suban sus SDKs distribuibles a la tienda, los actualicen, los reviertan y los quiten
Un mecanismo para garantizar la integridad de un SDK y su procedencia, así como una app y su procedencia, y resolver sus dependencias
Un mecanismo para implementarlos en dispositivos de manera confiable y coherente

Evolución de las restricciones a lo largo del tiempo

Esperamos que las restricciones que enfrenta el código en el entorno de ejecución de SDK evolucionen con las versiones posteriores de Android. Para garantizar la compatibilidad con aplicaciones, no cambiaremos estas restricciones con actualizaciones del módulo de línea principal para un nivel de SDK determinado. El comportamiento asociado con una targetSdkVersion determinada se conserva hasta que la compatibilidad con esa targetSdkVersion deje de estar disponible a través de la política de la tienda de aplicaciones, y la baja de la targetSdkVersion puede ocurrir más rápido que en el caso de las apps. Es posible que las restricciones cambien con frecuencia entre las versiones del SDK de Android, especialmente en las primeras versiones.

Además, compilamos un mecanismo de versiones canary para permitir que los verificadores internos y externos se unan a un grupo que obtenga el conjunto de restricciones propuesto para la próxima versión de Android. Esto nos ayudará a obtener comentarios y confianza sobre los cambios propuestos para el conjunto de restricciones.

Preguntas frecuentes

¿Qué es un SDK relacionado con publicidad?

Un SDK relacionado con anuncios es aquel que facilita cualquier parte de la segmentación de los usuarios con mensajes para fines comerciales, en apps que no son propiedad del anunciante. Se incluyen, entre otros, los SDKs de Analytics en los que se pueden crear grupos de usuarios para segmentación posterior, los SDKs de publicación de anuncios, los SDKs antiabuso y antifraude para anuncios, los SDKs de participación y los SDKs de atribución.
¿Se puede ejecutar cualquier SDK en el entorno de ejecución de SDK?

Si bien el enfoque inicial es el uso de SDKs relacionados con anuncios, los desarrolladores de SDKs de otra índole que busquen una posición favorable a la privacidad y crean que pueden operar según las condiciones descritas anteriormente pueden compartir comentarios sobre los SDKs que ejecuten en el entorno de ejecución de SDK. Sin embargo, este no está diseñado para ser compatible con todos los diseños de SDK. Más allá de las limitaciones documentadas, el entorno de ejecución del SDK probablemente no sea adecuado para los SDK que necesitan comunicaciones de alta capacidad de procesamiento o en tiempo real con la app host.
¿Por qué elegir el aislamiento de procesos en lugar del aislamiento en un entorno de ejecución de un proceso basado en Java?

Actualmente, el entorno de ejecución basado en Java no facilita los límites de seguridad necesarios para las garantías de privacidad que desean los usuarios de Android. Intentar implementar algo como esto probablemente requeriría un esfuerzo de varios años, sin garantía de éxito. Por lo tanto, Privacy Sandbox usa límites de procesos, una tecnología probada en el tiempo y muy comprensible.
¿Transferir el SDK al proceso del Entorno de ejecución de SDK proporciona un ahorro de espacio o de tamaño de descarga?

Si se integran varias apps con SDKs habilitados para el entorno de ejecución de la misma versión, se puede reducir el tamaño de descarga y el espacio en disco.
¿A qué tipo de eventos de ciclo de vida de la app (como cuando la app pasa a segundo plano) tendrán acceso los SDKs en el entorno de ejecución de SDK?

Estamos trabajando activamente en la compatibilidad de diseño para notificar al entorno de ejecución de SDK sobre eventos de ciclo de vida a nivel de la app de su aplicación cliente (p. ej., cuando la app pasa a segundo plano o a primer plano). El diseño y el código de muestra se compartirán en una próxima Versión preliminar para desarrolladores.

Recomendaciones para ti

Nota: El texto del vínculo se muestra cuando JavaScript está desactivado
Guía para desarrolladores del entorno de ejecución del SDK