Privacy Sandbox on Android Developer Preview is here! Learn how to get started, and continue to provide feedback.

Entorno de ejecución de SDK

Enviar comentarios

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 SDK 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 SDK 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 13, planeamos agregar una nueva capacidad de plataforma que permita que los SDK de terceros se ejecuten en un entorno de ejecución dedicado llamado entorno de ejecución de SDK. El entorno de ejecución del 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 SDK

Objetivos

La propuesta tiene los siguientes objetivos:

  • Reducir el acceso no divulgado y el uso compartido de los datos de app de un usuario a través de SDK 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.
  • Reduce el seguimiento no divulgado del uso de la app por parte de un usuario que hacen SDK de terceros mediante la limitación de acceso de los SDK únicos y persistentes.
  • Acelera la distribución de forma segura de las actualizaciones de SDK 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.
  • Ayuda a los desarrolladores de apps a comprender mejor las prácticas de acceso y uso compartido de datos de sus apps.
  • Ayuda a los desarrolladores de SDK a evitar alteraciones por parte de otros SDK mediante el límite de ciertas construcciones de lenguaje no seguras, como la reflexión y el código JNI.
  • Ayuda a los SDK de anuncios a detectar y evitar el tráfico no válido y el fraude publicitario mediante un control total sobre las vistas remotas en las que se muestra contenido multimedia.
  • Minimiza el impacto indebido de los desarrolladores de apps y SDK tanto como sea posible.

Los SDK se ejecutan en un proceso aislado

El entorno de ejecución de SDK propuesto permite que los SDK compatibles, a los que se hace referencia en todo el resto de este documento como SDK habilitados para el entorno de ejecución (RE), 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 del SDK. Consulta la sección de comunicaciones de este documento para obtener más detalles. Los SDK que no son de RE permanecerán en el proceso de la app como lo hacen actualmente. En la Figura 1, se ilustran estos cambios:

Antes:


Después:

Figura 1: Ubicaciones relativas de los SDK habilitados para el entorno de ejecución antes y después de agregarse al entorno de ejecución del SDK En el diagrama "antes" (primero), se muestra que el código de llamada del SDK, junto con los SDK que reciben las llamadas desde este código, se encuentra en el proceso de la app. En el diagrama de "después" (segundo), se muestra que, en el proceso en primer plano de la app, el código de llamada del SDK se comunica con las interfaces del SDK. Estas interfaces luego cruzan un límite de proceso en el proceso del entorno de ejecución del SDK para llamar a los SDK.

Nuevo modelo de distribución confiable para SDK

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 SDK correctos en el entorno de ejecución del SDK de una app. Esto ayuda a proteger a los usuarios y desarrolladores de apps de los SDK no válidos que se cargan y, al mismo tiempo, permite que las tiendas de apps reduzcan de manera significativa la carga de distribución de SDK de los desarrolladores.

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

  1. Los desarrolladores de SDK pueden subir sus SDK con versiones a las tiendas de apps, separados de las apps en sí.
  2. 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.
  3. 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 apps.

Este mecanismo de distribución nuevo permite que los desarrolladores de SDK realicen cambios no rotundos (es decir, no haya cambios en las API ni su semántica) en sus SDK 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 SDK nuevos ni que los usuarios finales actualicen sus apps. Los desarrolladores de apps deberán actualizar los cambios rotundos, pero los desarrolladores de SDK podrían recibir 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 la Figura 2, se ilustran los cambios propuestos para la distribución de SDK:

Antes:

Diagram de antes

Después:

Diagrama de después
Figura 2: Diseño de distribución del SDK, antes y después de la introducción del entorno de ejecución del SDK Los desarrolladores del SDK ya no deberán enviar sus SDK directamente a las apps. En su lugar, usarán una IU de carga de SDK para publicar sus SDK en una tienda de apps. La tienda de apps 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 SDK y apps

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

  • Acceso: Permisos, memoria, 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 SDK

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. Es por eso que solicitamos activamente tus comentarios y te pedimos que lo envíes mediante esta herramienta de seguimiento de errores.

Acceso

Administrar la privacidad de un sistema implica administrar cómo distintas partes pueden acceder a diferentes recursos. A fin de cumplir con nuestra propuesta de valor de privacidad, proponemos actualizar el modelo para acceder a apps, SDK y datos de usuarios a fin de 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 del 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 SDK relacionados con anuncios, proponemos que los siguientes permisos sean accesibles para los SDK en el entorno de ejecución del 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.
  • Permisos para acceder a las API de preservación de la privacidad, que proporcionan capacidades de publicidad principales sin necesidad de acceder a identificadores de apps múltiples. Los nombres de los permisos no están finalizados, pero las APIs están restringidas por el acceso de la app a estos permisos.
  • AD_ID: Permite solicitar el ID de publicidad. También se verá restringido el acceso de la app a este permiso.
  • BIND_GET_INSTALL_REFERRER_SERVICE: Es la capacidad de usar la API de referencia de instalación de Google Play para atribuir la fuente de instalación de una app.

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

Como se explica en la sección de permisos de SDK de este documento, 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 SDK y viceversa.
  • Los SDK no podrán acceder al almacenamiento externo del dispositivo.
  • Dentro de cada entorno de ejecución de SDK, todos los SDK deben poder acceder a ambos almacenamientos, y al que es privado de cada uno.

Al igual que el modelo de almacenamiento actual, el almacenamiento en sí no tendrá límites arbitrarios de tamaño ni duración (en otras palabras, no será efímero, sino que se quitará cuando se desinstale la app).

Ejecución

Para garantizar un sistema privado entre apps, SDK y usuarios, el contexto de ejecución en sí mismo (formatos de código, construcciones de lenguaje, API 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 SDK), ya sea escrito en Kotlin o en el lenguaje de programación 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 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

Si bien la mayoría de las APIs de lenguaje basado en Java admiten el modelo de privacidad que nos esforzamos por alcanzar en el entorno de ejecución de SDK, hay algunas APIs basadas en Java que dificultan la conservación de la privacidad del usuario y del SDK, como las de reflección e invocación. Por lo tanto, proponemos evitar el acceso a estos dos conjuntos de APIs desde el entorno de ejecución de SDK, además de otros que estamos investigando de forma activa, y esperamos recibir comentarios sobre el impacto en diversos casos de uso. Compartiremos una propuesta completa en una actualización futura.

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.

Por último, los SDK de RE no podrán usar las APIs de notificaciones para enviar notificaciones a los usuarios en ningún momento.

Ciclo de vida

Los SDK 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 SDK también lo hacen. Nuestra propuesta de separar los SDK 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 tiempo de ejecución de SDK finalizará de forma automática inmediatamente después.
  • El sistema operativo puede finalizar el tiempo de ejecución del SDK debido a, por ejemplo, la presión de la memoria o una excepción no controlada en un SDK.

    El tiempo de ejecución de SDK se produce con una prioridad un poco menor que su app asociada. Por lo tanto, es muy probable que una app se cierre poco después del tiempo de ejecución del SDK debido a la presión de la memoria. En caso de que no sea así, o por un motivo diferente, la propuesta ofrece métodos de devolución de llamada de ciclo de vida relacionados a los desarrolladores de apps para que manejen esta excepción y vuelvan a inicializar el tiempo de ejecución de SDK con una llamada init() que lo volvería a cargar.

    En caso de fallas persistentes, el desarrollador de la app deberá planificar una degradación elegante sin el SDK o notificar al usuario si este es fundamental 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 SDK que no sean de RE podrán seguir usando las primitivas estándar del SO disponibles para su app incorporada (incluidos servicios, actividades y transmisiones), mientras que los SDK de RE no podrán hacerlo.

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 procesado.

Los anuncios nativos, que no son renderizados por el SDK, sino por la app, serían compatibles con los SDK en el entorno de ejecución del SDK. El proceso de recopilación de indicadores y recuperación de creatividades se realizaría de manera coherente con los anuncios no nativos. Sin embargo, es probable que no sean posibles las protecciones de renderización del entorno de ejecución de SDK que otorgan los SDK típicos de WebView. 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 el del SDK o la vista, 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

Nuestro objetivo es minimizar el impacto en el estado del sistema que tiene el entorno de ejecución del SDK en los dispositivos del usuario final, y estamos diseñando maneras de lograrlo. Sin embargo, lo más probable es que algunos dispositivos básicos de Android 13 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 SDK 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 devoluciones de llamada a través de este límite entre la app y el SDK. Proponemos que los desarrolladores de SDK 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 SDK y, al mismo tiempo, proporcionar flexibilidad para los desarrolladores de SDK y asegurarnos de que el código de SDK se ejecute en el entorno de ejecución del SDK a fin de 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 a fin de minimizar el impacto en los desarrolladores de apps y SDK. En la Figura 3, se muestra un enfoque que consideramos:

Diagrama
Figura 3: Diagrama de secuencias que muestra las interacciones de app a SDK durante el inicio de la app y el SDK

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

  • Primero, una app registraría una devolución de llamada para recibir notificaciones sobre eventos, como cuando se (re)inicia el proceso de tiempo de ejecución de SDK o cuando un SDK envía datos de vuelta a la app. Por ejemplo, una app puede registrar la devolución de llamada durante su inicio.

    El siguiente fragmento de código proporciona un ejemplo ilustrativo de la API:

    SdkRuntimeManager.registerSdkRuntimeCallback(SdkRuntimeCallback callback,
        Executor executor)
    
  • 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 SDK que quieren cargar en su archivo de manifiesto, y estos SDK serían los únicos permitidos. Una app podría solicitar la carga de un SDK específico o todos los SDK definidos en su manifiesto. Esto permitiría que la app cargue los SDK durante su inicio o cuando se reinicie el tiempo de ejecución del SDK.

    El siguiente fragmento de código proporciona un ejemplo ilustrativo de la API:

    SdkRuntimeManager.loadSdk(String sdkName, LoadSdkCallback callback,
        Executor executor)
    
    SdkRuntimeManager.loadAllSdks(LoadAllSdksCallback callback,
        Executor executor)
    
  • Después de que se carga un SDK en el entorno de ejecución de SDK, nuestra propuesta permite que la app interactúe con el SDK a través de la capa de ordenamiento generada desde la interfaz del SDK. De forma interna, las llamadas se agrupan mediante una API de sendData(). Ejemplo ilustrativo:

    SdkRuntimeManager.sendData(String sdkName, Bundle data)
    
  • Como se explica en la sección de procesamiento de contenido multimedia de este documento, a fin de que una app obtenga un SDK para procesar 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:

    SdkRuntimeManager.requestSurfacePackage(String sdkName, IBinder appToken,
        int displayId, Bundle extraParams,
        RequestSurfacePackageCallback callback, Executor executor)
    
  • La app puede incorporar el SurfacePackage mostrado 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 sendData() y requestSurfacePackage() sean genéricas y no que las apps puedan llamar directamente a ellas. En su lugar, la referencia a la API generada que describimos anteriormente llama a estas APIs para reducir la carga de los desarrolladores de apps.

SDK a SDK

En este caso, es necesario que se comuniquen dos SDK en la misma app. Esto puede suceder cuando la arquitectura de un SDK determinado está compuesta por SDK constituyentes y puede suceder cuando dos SDK 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 SDK son RE: En este caso, ambos SDK se ejecutan en el entorno de ejecución del SDK con todas sus protecciones, incluida la falta de capacidades de reflexión para el descubrimiento. Los SDK no podrán comunicarse como lo hacen actualmente en una app. En consecuencia, estamos diseñando APIs en el entorno de ejecución de SDK para el registro y el descubrimiento de SDK a fin de facilitar la comunicación.
  • Cuando solo uno es RE:
    • 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, proponemos exponer una llamada sendData(...) genérica que el código de la app detecte, procese y responda con las devoluciones de llamada proporcionadas. Esto se encuentra en proceso de investigación activa.

Consideramos los siguientes casos de uso de diseño de estas primitivas:

  1. Mediación y ofertas. Muchos SDK de publicidad ofrecen una capacidad de mediación o de oferta en la cual el SDK llama a otros SDK distintos para una impresión de anuncios (mediación) o recopilación de indicadores a fin de ejecutar una subasta (ofertas). Por lo general, el SDK de coordinación llama a otros SDK a través de un adaptador proporcionado por él mismo. Debido a las primitivas anteriores, el SDK de coordinación (RE o no) debe poder acceder a todos los SDK de RE y de otros tipos para garantizar un funcionamiento normal. La renderización en este contexto es un área de investigación activa.
  2. Descubrimiento de funciones. Algunos productos de SDK consisten en SDK más pequeños que, a través de un proceso de descubrimiento entre SDK, determinan el conjunto de funciones final que se expone al desarrollador de la app. Esperamos que las primitivas de registro y descubrimiento habiliten este caso de uso.
  3. Modelos de suscripción de publicador. Algunos SDK tendrán un publicador central de eventos a los que otros SDK o la app podrán suscribirse para recibir notificaciones mediante devoluciones de llamada. Las primitivas anteriores deben admitir este caso de uso.

App a app

Esta es la comunicación entre apps, en la que al menos uno de los dos procesos participantes es un SDK de RE. Debido a que esta es una comunicación entre apps, este es un vector natural para compartir datos sin divulgar.

En consecuencia, el entorno de ejecución del SDK no podrá comunicarse con ningún otro proceso de app por ningún medio, incluidos intents y transmisiones. Como resultado, ningún SDK dentro del entorno de ejecución podrá comunicarse con ninguna otra app ni con ningún SDK de RE alojado por otra app.

Desarrollo

Un principio clave de esta propuesta es minimizar el impacto en el ecosistema de desarrolladores en la medida de lo posible. En consecuencia, esta propuesta ofrecerá a los desarrolladores un conjunto completo de herramientas de desarrollo para escribir, compilar y depurar apps y SDK de RE. Sin embargo, para garantizar la integridad de esta propuesta, se implementarán algunos cambios en la forma en que se configuran, crean y compilan las apps y los SDK de RE.

Autorización

Se actualizarán Android Studio y las herramientas relacionadas para que sean compatibles con el entorno de ejecución del SDK, lo que ayudará a garantizar que los desarrolladores hayan configurado correctamente sus apps y SDK de RE, 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 de RE 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 sean de RE 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 SDK de RE 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 SDK de RE tienen otros SDK de RE 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 SDK de RE que dependan de otros que no sean de RE 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 SDK que no son de RE 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 SDK de RE deseen seguir brindando compatibilidad con dispositivos que no están habilitados para RE, 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 13 básicos con recursos del sistema muy limitados. Estamos trabajando a fin de garantizar que los desarrolladores de SDK puedan retener una sola base de código para admitir entornos de RE y no RE.

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 apps (RE 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 a fin de que el proceso sea lo más transparente posible.

Si bien se espera que una compilación DEBUG incluya todo el código y los símbolos presentes en este tipo de compilación para su depuración, las compilaciones RELEASE pueden, de manera opcional, quitar todos los SDK distribuidos en tiendas de apps (RE 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 no sean de RE y de RE 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 de RE y que no son de RED de un SDK.

Al igual que para las apps, cualquier SDK de dependencia distribuido en tiendas de apps 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 13 como lo harían normalmente. Después de compilar la app, esta podría instalarse en un emulador o dispositivo de RE. 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 RE y no RE. 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 SDK suban sus SDK 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

Preguntas frecuentes

  1. ¿Qué es un SDK relacionado con publicidad?

    Un SDK que facilita cualquier parte de la segmentación de usuarios con mensajes para fines comerciales en apps que no son propiedad del anunciante. Se incluyen, entre otros, SDK de estadísticas en los que se pueden crear grupos de usuarios para segmentación posterior, SDK de publicación de anuncios, SDK antiabuso y antifraude para anuncios, SDK de participación y SDK de atribución.

  2. ¿Se puede ejecutar cualquier SDK en el entorno de ejecución del SDK?

    Si bien el enfoque inicial es el uso de SDK relacionados con anuncios, los desarrolladores de SDK 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 SDK que ejecuten en el entorno. 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.

  3. ¿Por qué elegimos aislamiento de procesos en lugar de aislamiento en el 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 buscamos ofrecer a 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, elegimos utilizar límites de proceso, una tecnología probada en el tiempo y muy comprensible.