Conheça a prévia para desenvolvedores do Sandbox de privacidade do Android. Veja como começar e envie feedback.

SDK Runtime

Enviar feedback

A plataforma Android usa o conceito de sandbox de app para manter uma execução robusta e limites de segurança, bem como limites de processo, para o código do app. É uma prática comum que os apps incluam código de terceiros, geralmente na forma de SDKs, como SDKs de anúncios ou de análise. Essa reutilização permite que os desenvolvedores de apps se concentrem em recursos que diferenciem os apps e tirem proveito do trabalho de especialistas no assunto para levar a execução do app a níveis mais elevados do que conseguiriam atingir facilmente por conta própria.

Como na maioria dos sistemas operacionais, no Android, os SDKs são executados no sandbox do app host e herdam os mesmos privilégios e permissões do app em que estão hospedados, bem como o acesso à memória e ao armazenamento do app host. Embora essa arquitetura permita a integração flexível de SDKs e apps, ela também cria a possibilidade de compartilhamento e coleta de dados não divulgados de usuários. Além disso, é possível que os desenvolvedores de apps não estejam totalmente cientes da extensão das funções de um SDK de terceiros e dos dados que ele acessa, o que dificulta a avaliação das práticas de coleta e compartilhamento de dados do app.

No Android 13, planejamos adicionar um novo recurso de plataforma que permite que SDKs de terceiros sejam executados em um ambiente de execução dedicado, chamado de SDK Runtime. O SDK Runtime oferece melhores proteções e garantias em relação à coleta e ao compartilhamento de dados do usuário, conforme apresentado a seguir:

  • Ambiente de execução modificado
  • Permissões bem definidas e direitos de acesso a dados para SDKs

Metas

Esta proposta busca atingir as metas abaixo:

  • Reduzir o acesso e o compartilhamento não revelado dos dados de apps de um usuário por SDKs de terceiros, implementando o isolamento de processos e um controle de acesso a APIs e dados bem definido. Saiba mais sobre o isolamento de processo em outra seção deste documento.
  • Reduzir o rastreamento não divulgado do uso de apps de usuários por SDKs de terceiros, limitando a possibilidade de acesso a identificadores exclusivos e persistentes pelos SDKs.
  • Acelerar a distribuição de atualizações do SDK para apps de forma segura, reduzindo o trabalho dos desenvolvedores de apps e dos usuários finais. Saiba mais sobre a proposta de modelo de distribuição de SDKs confiáveis em outra seção deste documento.
  • Ajudar os desenvolvedores a ter melhor controle sobre as práticas de acesso e compartilhamento de dados dos próprios apps.
  • Ajudar os desenvolvedores de SDKs a evitar adulterações por parte de outros SDKs, limitando o uso de algumas construções de linguagem que não são seguras, como reflexão e código JNI.
  • Ajudar os SDKs de anúncios a detectar e impedir tráfegos inválidos e fraude de anúncios mediante controle total sobre as visualizações remotas que mostram mídias.
  • Reduzir, o máximo possível, o impacto indevido aos desenvolvedores de apps e SDK.

SDKs executados em um processo isolado

O SDK Runtime proposto permite que os SDKs compatíveis, chamados neste documento de SDKs ativados pelo ambiente de execução (RE, na sigla em inglês), operem em um processo separado do app. A plataforma facilita a comunicação bidirecional entre o processo do app e o SDK Runtime. Consulte a seção sobre comunicações deste documento para ver mais informações. Os SDKs não RE permanecem no processo do app, como já ocorre atualmente. A Figura 1 ilustra essas mudanças:

Antes:


Depois:

Figura 1. Localização relativa dos SDKs ativados pelo ambiente de execução antes e depois de serem adicionados ao SDK Runtime. O diagrama "antes" (o primeiro) mostra que o código que chama o SDK e os SDKs que recebem as chamadas desse código residem no processo do app. O diagrama "depois" (o segundo) mostra que, no processo em primeiro plano do app, o código que chama o SDK se comunica com as interfaces do SDK. Em seguida, essas interfaces atravessam um limite de processo para chegar ao processo do SDK Runtime, a fim de chamar os próprios SDKs.

Novo modelo de distribuição confiável para SDKs

A separação entre o SDK e o app que está sendo proposta leva a outro conceito de separação: a separação entre o SDK e a distribuição do app. Nossa proposta exige um mecanismo confiável de distribuição e instalação para garantir que os SDKs corretos sejam instalados no SDK Runtime de um app. Isso ajuda a proteger os usuários e os desenvolvedores de apps contra o carregamento de SDKs inválidos e também permite que as app stores reduzam significativamente a carga de distribuição do SDK para os desenvolvedores de apps.

Os SDKs não vão precisar mais ser vinculados e agrupados estaticamente com os apps antes de serem enviados a uma app store para distribuição. Ao invés disso, ocorrerá o seguinte:

  1. Os desenvolvedores de SDKs vão poder fazer upload das versões de SDKs para as app stores, separados dos respectivos apps.
  2. Os desenvolvedores de apps vão poder especificar as dependências do SDK por versão, além de criar e fazer upload de uma versão do app que não inclua as dependências reais do SDK.
  3. Quando um usuário fizer o download desse app, o processo de instalação vai poder usar as dependências do SDK especificadas do app e fazer o download delas na app store.

Esse novo mecanismo de distribuição vai permitir que os desenvolvedores de SDKs façam alterações não interruptivas nos SDKs, ou seja, nenhuma mudança em APIs ou na semântica, e distribuam o app aos dispositivos sem necessidade de envolvimento dos desenvolvedores de apps. Essas alterações não interruptivas do SDK podem ser implantadas ou revertidas, sem que seja necessário esperar que os desenvolvedores de apps criem uma nova versão do app que inclua os novos SDKs ou que os usuários finais atualizem o app. As alterações interruptivas ainda vão precisar ser atualizadas pelos desenvolvedores de apps, mas os desenvolvedores de SDKs poderão lançar as alterações e correções não interruptivas de maneira mais rápida e uniforme, para um número maior de pessoas e, preferencialmente, minimizando o suporte entre versões.

A Figura 2 ilustra as mudanças propostas na distribuição do SDK:

Antes:

Diagrama do processo antes da mudança.

Depois:

Diagrama do processo após a mudança.
Figura 2. Modelo de distribuição do SDK, antes e depois da introdução do SDK Runtime. Os desenvolvedores de SDKs não vão precisar mais enviar os SDKs diretamente aos apps. Em vez disso, eles vão usar uma IU de upload do SDK para publicar os SDKs nas apps stores. Assim, a app store vai processar a distribuição dos apps, junto de qualquer dependência dos SDKs, para os dispositivos dos usuários.

Mudanças na forma como os SDKs e os apps são criados, executados e distribuídos

Esta é uma proposta inicial de uma tecnologia flexível de distribuição e do SDK Runtime. Nas próximas seções, vamos propor uma série de mudanças nestas categorias amplas:

  • Acesso: permissões, memória, armazenamento.
  • Execução: idiomas, mudanças no ambiente de execução, ciclo de vida, renderização de mídia.
  • Comunicações: de app para SDK e SDK para SDK.
  • Desenvolvimento: como criar, depurar e testar nesse modelo.
  • Distribuição: como distribuir, atualizar e reverter diferentes versões do Android, apps e SDKs.

Este documento também inclui uma lista de perguntas frequentes para ajudar a responder às dúvidas mais comuns.

Esta é uma proposta de modelo inicial. Compreendemos que ela pode caracterizar uma mudança expressiva para alguns membros do ecossistema. Por isso pedimos que você envie seu feedback pelo Issue Tracker.

Acesso

Gerenciar a privacidade de um sistema implica gerenciar a maneira como partes diferentes podem acessar recursos diferentes. Para cumprir nossa proposta de valor de privacidade, sugerimos atualizar o modelo de acesso a apps, SDKs e dados do usuário, a fim de seguir o princípio de privilégio mínimo e impedir o acesso não revelado a dados possivelmente sensíveis.

Permissões do SDK

Como um processo separado, o SDK Runtime vai ter um conjunto próprio e bem definido de permissões, ao invés de herdar aquelas concedidas ao app pelo usuário. Com base em uma pesquisa preliminar sobre as permissões usadas pelos SDKs relacionados a anúncios, propomos que as permissões abaixo possam ser acessadas pelos SDKs do SDK Runtime, por padrão:

  • INTERNET: acesso à Internet para se comunicar com serviços da Web.
  • ACCESS_NETWORK_STATE: acesso a informações sobre redes.
  • Permissões para acessar as APIs de preservação de privacidade, que oferecem os principais recursos de publicidade sem precisar acessar identificadores entre apps. Os nomes das permissões ainda não foram finalizados, mas essas APIs vão ser controladas pelo acesso do app às permissões.
  • AD_ID: capacidade de solicitar o ID de publicidade. Esso atributo também vai ser controlado pelo acesso do app a essa permissão.
  • BIND_GET_INSTALL_REFERRER_SERVICE: capacidade de usar a API Google Play Install Referrer para atribuir a fonte de instalação de um app.

No momento, estamos analisando se vamos incluir outras permissões, e como poderíamos fazer isso, de um modo que limite o impacto para os usuários finais do ponto de vista da privacidade e da usabilidade. Solicitamos que você envie feedback em relação a qualquer caso de uso que não seja atendido por esse conjunto de permissões.

Memória

Conforme explicado na seção de permissões do SDK deste documento, o SDK Runtime vai ter um espaço de memória próprio e isolado, visto que ele terá um processo próprio. Por padrão, essa estrutura faria com que o acesso do SDK ao espaço de memória do app fosse negado. Da mesma forma, o aplicativo não poderia acessar o espaço de memória do SDK. Sugerimos manter esse comportamento padrão na proposta para que o princípio do privilégio mínimo seja seguido.

Armazenamento

Esta proposta tem como objetivo usar um armazenamento permanente para equilibrar a necessidade de que os SDKs acessem o armazenamento a fim de executar operações comuns e minimizar o rastreamento entre apps e em todo o processo. Propomos esta atualização no atual modo de acesso ao armazenamento:

  • Um app não vai poder acessar diretamente o armazenamento dos SDKs e vice-versa.
  • O armazenamento externo do dispositivo não vai poder ser acessado por SDKs.
  • Em cada SDK Runtime, vai haver um armazenamento disponível para todos os SDKs e um armazenamento exclusivo para um SDK específico.

Assim como o modelo de armazenamento atual, o armazenamento não tem limites arbitrários de tamanho nem duração. Em outras palavras, o armazenamento não é temporário, mas é removido no momento em que o app é desinstalado.

Execução

Para garantir um sistema particular entre apps, SDKs e usuários, o próprio contexto de execução (formatos de código, construções de linguagem, APIs que podem ser acessadas e dados do sistema) precisa reforçar esses limites de privacidade ou, pelo menos, não oferecer oportunidades para os contornar. Ao mesmo tempo, queremos preservar o acesso a uma plataforma completa e à maioria dos recursos de ambiente de execução atualmente disponíveis para os SDKs. Neste documento, apresentamos a proposta de um conjunto de atualizações para o ambiente de execução, com o objetivo de alcançar esse equilíbrio.

Código

O código do Android, de apps e SDKs, é interpretado principalmente pelo Android Runtime (ART), seja ele escrito na linguagem de programação Kotlin ou Java. Os recursos do ART e as construções de linguagem que ele oferece, combinados à possibilidade de verificação oferecida quando comparado às alternativas (como o código nativo), parecem trazer um equilíbrio adequado entre funcionalidade e privacidade. Nossa proposta é que o código do SDK seja composto exclusivamente pelo bytecode Dex, ao invés de oferecer suporte para acesso da JNI.

Estamos cientes de que existem casos de uso (como do SQLite personalizado) que, devido ao uso de código nativo, vão precisar ser substituídos por uma alternativa, como a versão integrada do SDK do Android para SQLite.

SELinux

No Android, todos os processos, incluindo aqueles executados como raiz, são executados com um contexto específico do SELinux, o que permite que o kernel gerencie o controle de acesso a serviços, arquivos, dispositivos e outros processos do sistema. Para preservar a maioria dos casos de uso do SDK e minimizar o descumprimento das proteções de privacidade que estamos tentando propor, sugerimos as atualizações abaixo para o SDK Runtime no contexto do SELinux de um app que não é do sistema:

  • Um conjunto limitado de serviços do sistema vai poder ser acessado (em fase de desenvolvimento).
  • Os SDKs só vão poder carregar e executar o código no APK.
  • Um conjunto limitado de propriedades do sistema vai poder ser acessado (em fase de desenvolvimento).

APIs

Embora a maioria das APIs baseadas em linguagem Java ofereça suporte ao modelo de privacidade que queremos alcançar no SDK Runtime, existem algumas APIs baseadas em Java que dificultam a preservação da privacidade do usuário e do SDK, como as APIs de reflexão e de chamada. Por esse motivo, sugerimos impedir o acesso a esses dois conjuntos de APIs no SDK Runtime, possivelmente junto a outros conjuntos que estamos analisando no momento. Solicitamos que você envie feedback. em relação ao impacto gerado nos diversos casos de uso. Compartilharemos uma proposta completa em uma atualização futura.

Além disso, as versões recentes da Plataforma Android têm restringido cada vez mais o acesso a identificadores persistentes, com o objetivo de melhorar a privacidade. No SDK Runtime, a proposta inclui limitações ainda maiores ao acesso a identificadores que podem ser usados para o rastreamento entre apps.

Por fim, os SDKs RE não vão poder usar as APIs de notificação para enviar notificações ao usuário em nenhum momento.

Ciclo de vida

Atualmente, os SDKs dos apps seguem o ciclo de vida do app host. Isso significa que, quando o app entra ou sai do primeiro plano, é desligado ou é interrompido pelo sistema operacional devido à pressão da memória, o mesmo ocorre com os SDKs do app. Nossa proposta de mover os SDKs dos apps para um processo separado implica nas mudanças do ciclo de vida abaixo:

  • O processo do app pode ser encerrado pelo usuário ou pelo sistema operacional. Quando isso ocorrer, o SDK Runtime vai ser automaticamente encerrado em seguida.
  • O SDK Runtime pode ser encerrado pelo sistema operacional devido à pressão da memória ou, por exemplo, devido a uma exceção não processada em um SDK.

    O SDK Runtime é executado com uma prioridade um pouco menor que o app associado. Consequentemente, é muito provável que, se o SDK Runtime for encerrado devido à pressão da memória, o app também seja encerrado em seguida. Caso isso não ocorra ou caso o motivo do encerramento seja outro, a proposta oferece métodos de callback do ciclo de vida relacionados aos desenvolvedores de apps, para que eles possam processar essa exceção e reinicializar o SDK Runtime com uma chamada init() para o recarregar.

    No caso de falhas persistentes, o desenvolvedor do app vai precisar planejar uma degradação suave sem o SDK ou notificar o usuário se o SDK for essencial para o recurso principal do app. Veja mais detalhes sobre essa interação do app para o SDK na seção de comunicações deste documento.

Os SDKs não RE podem continuar a usar os primitivos padrão do SO disponíveis para o app incorporado, incluindo serviços, atividades e transmissões. Já os SDKs RE não podem fazer o mesmo.

Renderização de mídia

Existem SDKs que renderizam conteúdos como texto, imagens e vídeos em uma visualização especificada pelo app. Para isso, sugerimos uma abordagem de renderização remota, em que o SDK renderiza a mídia no SDK Runtime, mas usa a API SurfaceControlViewHost para que a mídia seja renderizada em uma visualização especificada pelo app. Isso oferece ao SDK a capacidade de renderizar a mídia de maneira particular ao usuário, além de ajudar a impedir e detectar interações inválidas ou fraudulentas do usuário com a mídia renderizada.

Os SDKs no SDK Runtime vão oferecer suporte a anúncios nativos, que não são renderizados pelo SDK, mas sim pelo app. O processo de coleta de indicadores e busca de criativos vai acontecer de maneira consistente em anúncios não nativos. No entanto, não vai ser possível oferecer as proteções de renderização do SDK Runtime, disponibilizadas para renderização típica do WebView. Essa área está em fase de análise.

Anúncios em vídeo in-stream são os aqueles mostrados em um player de vídeo dentro do app. Como o vídeo é reproduzido em um player no app, e não em um player ou uma visualização no SDK, o modelo de renderização é diferente de outros formatos de anúncio. Estamos analisando mecanismos para oferecer suporte à inserção de anúncios do lado do servidor e inserção de anúncios com base no SDK.

Integridade do sistema

Estamos buscando maneiras de minimizar o impacto causado pelo SDK Runtime à integridade do sistema nos dispositivos dos usuários. No entanto, é provável que alguns dispositivos básicos que usam o Android 13 e têm recursos de sistema muito limitados, como o Android Go, não ofereçam suporte ao SDK Runtime devido ao impacto gerado à integridade do sistema Em breve, compartilharemos os requisitos mínimos necessários para usar o SDK Runtime.

Comunicações

Como atualmente os apps e os SDKs são executados no mesmo processo, a comunicação entre eles não é inibida nem mediada. Além disso, o Android permite comunicações entre apps, mesmo que elas se iniciem e terminem com os SDKs. Esse modelo de comunicação de fluxo livre permite vários casos de uso, mas também introduz a possibilidade de compartilhamento de dados não revelado entre apps e entre SDKs dentro de um mesmo app e em apps diferentes. Esta proposta inclui as atualizações ao modelo de comunicações apresentadas abaixo. Procuramos encontrar um equilíbrio entre o valor dessas comunicações e o cumprimento dos nossos objetivos.

Do app para o SDK

A interface entre o app e o SDK é o caminho de comunicação mais comum para um SDK, e é na API do SDK que fica localizada a maior parte das diferenciações e inovações voltadas ao usuário. Buscamos preservar a capacidade dos SDKs de inovar e se diferenciarem nesse local. Por isso, nossa proposta permite que os SDKs exponham APIs aos apps e garante que eles tirem proveito de toda a inovação.

Devido à estrutura de limites do processo do SDK Runtime, sugerimos a criação de uma camada de marshaling, que pode ser acessada no app, para transportar as chamadas e respostas de API ou callbacks para além desse limite entre o app e o SDK. Propomos que a interface para essa camada de marshaling seja definida pelos desenvolvedores de SDKs e gerada por ferramentas de build de código aberto oficiais, que vão ser desenvolvidas por nossas equipes.

Com esta proposta, buscamos remover o trabalho de marshaling de código boilerplate dos desenvolvedores de apps e SDKs, oferecendo flexibilidade para os desenvolvedores de SDKs e garantindo que o código do SDK vai ser executado no SDK Runtime de modo a cumprir nossas metas de privacidade. Se fizermos a implementação dessa forma, a linguagem e as ferramentas de definição de API vão precisar ser projetadas considerando o feedback dos desenvolvedores.

O modelo de interação geral vai ser semelhante a este:

  • O app chama o SDK pela interface, transmitindo callbacks.
  • O SDK atende de forma assíncrona às solicitações e responde usando os callbacks.
  • Isso pode ser generalizado para qualquer modelo de editor/assinante, o que significa que um app pode se inscrever em eventos no SDK com callbacks e, quando esses eventos acontecerem, os callbacks serão acionados.

Uma das consequências da nova estrutura de processamento cruzado desta proposta é a necessidade de gerenciar dois ciclos de vida de processos: um para o próprio app e outro para o SDK Runtime. Nossa proposta procura automatizar esses processos o máximo possível, minimizando o impacto gerado para desenvolvedores de apps e SDKs. A Figura 3 mostra uma abordagem que estamos considerando:

Diagrama
Figura 3. Diagrama de sequência que mostra as interações do app para o SDK durante a inicialização do app e do SDK.

A plataforma vai expor novas APIs para que os apps carreguem SDKs dinamicamente no processo do SDK Runtime, recebam notificações sobre mudanças no estado do processo e interajam com os SDKs carregados no SDK Runtime.

  • Primeiramente, o app registra um callback para ser notificado sobre eventos como quando o SDK Runtime é iniciado (ou reiniciado) ou quando um SDK envia dados de volta ao app. Por exemplo, o app pode registrar o callback durante a inicialização.

    O snippet de código abaixo apresenta um exemplo ilustrativo da API:

    SdkRuntimeManager.registerSdkRuntimeCallback(SdkRuntimeCallback callback,
        Executor executor)
    
  • Antes que o app possa interagir com um SDK, ele vai solicitar que a plataforma carregue o SDK. Para garantir a integridade do sistema, o app vai especificar os SDKs que pretende carregar no arquivo de manifesto, e esses SDKs serão os únicos permitidos. O app pode solicitar o carregamento de um SDK específico ou de todos os SDKs definidos no manifesto. Isso permite que o app carregue os SDKs durante a inicialização ou quando o SDK Runtime for reiniciado.

    O snippet de código abaixo apresenta um exemplo ilustrativo da API:

    SdkRuntimeManager.loadSdk(String sdkName, LoadSdkCallback callback,
        Executor executor)
    
    SdkRuntimeManager.loadAllSdks(LoadAllSdksCallback callback,
        Executor executor)
    
  • Depois que um SDK for carregado no SDK Runtime, a proposta permite que o app interaja com o SDK pela camada de marshaling gerada na interface do SDK. Internamente, as chamadas são organizadas por uma API sendData(). Exemplo:

    SdkRuntimeManager.sendData(String sdkName, Bundle data)
    
  • Como explicado na seção sobre renderização de mídia deste documento, para que um app receba um SDK de renderização mídia em uma visualização, o app pode fazer uma chamada para requestSurfacePackage() e buscar o SurfaceControlViewHost.SurfacePackage correspondente.

    O snippet de código abaixo apresenta um exemplo ilustrativo da API:

    SdkRuntimeManager.requestSurfacePackage(String sdkName, IBinder appToken,
        int displayId, Bundle extraParams,
        RequestSurfacePackageCallback callback, Executor executor)
    
  • O app vai poder incorporar o SurfacePackage retornado à SurfaceView usando a API setChildSurfacePackage na SurfaceView.

    O snippet de código abaixo apresenta um exemplo ilustrativo da API:

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
    

Nossa proposta é que as APIs sendData() e requestSurfacePackage() sejam genéricas e não sejam chamadas diretamente pelos apps. Em vez disso, essas APIs vão ser chamadas pela Referência da API gerada, que foi abordada acima, para reduzir o fardo sobre os desenvolvedores de apps.

Do SDK para o SDK

Esse é o caso em que dois SDKs no mesmo app precisam se comunicar. Isso pode acontecer quando um SDK específico é arquitetado para ser composto pelos SDKs constituintes e também quando dois SDKs de partes diferentes precisam colaborar para atender a uma solicitação do app de chamada.

Existem dois casos principais a serem considerados:

  • Quando os dois SDKs são ativados pelo ambiente de execução. Nesse caso, os dois SDKs estão em execução no SDK Runtime com todas as proteções, incluindo a falta de capacidade de reflexão para descoberta. Os SDKs não vão poder se comunicar no app da mesma forma que fazem atualmente. Consequentemente, estamos desenvolvendo APIs no SDK Runtime para registro e descoberta de SDKs, para facilitar a comunicação.
  • Quando apenas um SDK é ativado pelo ambiente de execução.
    • Se o SDK de chamada estiver em execução no app, o processo vai ser igual a quando o próprio app chama um segundo SDK no SDK Runtime.
    • Se o SDK de chamada estiver em execução no SDK Runtime, sugerimos expor uma chamada sendData(...) genérica que vai ser detectada, processada e respondida pelo código do app com os callbacks fornecidos. Esse processo está em análise.

Estamos considerando os casos de uso abaixo à medida que desenvolvemos esses primitivos:

  1. Mediação e lances. Muitos SDKs de publicidade oferecem um recurso de mediação ou de lances em que o SDK chama vários outros SDKs para receber impressões de anúncios (mediação) ou para coletar indicadores e realizar um leilão (lances). Geralmente, o SDK que realiza a coordenação chama outros SDKs usando o adaptador fornecido pelo próprio SDK. Considerando os primitivos acima, o SDK que realiza a coordenação, seja ele RE ou não, precisa conseguir acessar todos os SDKs, sejam eles RE ou não, para uma operação normal. A renderização nesse contexto está sendo continuamente analisada.
  2. Descoberta de recursos. Alguns produtos do SDK consistem em SDKs menores que, por um processo de descoberta interna no SDK, determinam o conjunto de atributos final que vai ser exposto ao desenvolvedor do app. Esperamos que os primitivos de registro e descoberta possibilitem esse caso de uso.
  3. Modelos de editor e assinatura. Alguns SDKs vão ter um editor central de eventos que outros SDKs ou o app poderão assinar para receber notificações usando callbacks. Os primitivos acima precisam oferecer suporte a esse caso de uso.

Do app para o app

Essa é uma comunicação entre apps, em que pelo menos um dos dois processos de comunicação é um SDK RE. Devido ao fato de essa ser uma comunicação entre apps, ela é um vetor comum para o compartilhamento de dados não divulgados.

Consequentemente, o SDK Runtime não vai poder se comunicar com nenhum outro processo de app por nenhum meio, incluindo o envio de transmissões e intents. Como resultado, nenhum SDK dentro do SDK Runtime vai poder se comunicar com nenhum outro app ou SDK RE hospedado por outro app.

Desenvolvimento

Um princípio fundamental desta proposta é minimizar, na medida do possível, o impacto causado no ecossistema de desenvolvedores. Por esse motivo, a proposta vai oferecer aos desenvolvedores um conjunto abrangente de ferramentas de desenvolvimento para programar, criar e depurar apps e SDKs ativados pelo ambiente de execução. No entanto, para garantir a integridade da proposta, vai haver algumas mudanças na forma como os apps e SDKs ativados pelo ambiente de execução são configurados e criados.

Criação

O Android Studio e as ferramentas relacionadas vão ser atualizados para reconhecer o SDK Runtime, ajudando a garantir que os desenvolvedores tenham configurado corretamente os apps e SDKs ativados pelo ambiente de execução, além de garantir que as chamadas legadas ou sem suporte sejam atualizadas para alternativas mais recentes, quando necessário. De acordo com nossa proposta, algumas etapas precisarão ser cumpridas pelos desenvolvedores durante a fase de criação.

Desenvolvedores de apps

Os apps vão precisar especificar os certificados de dependências do SDK e do SDK RE no manifesto do app. Nesta proposta, tratamos essa etapa como a fonte de verdade do desenvolvedor do aplicativo. Exemplo:

  • Nome: nome do pacote do SDK ou da biblioteca.
  • Versão principal: código da versão principal do SDK.
  • Síntese do certificado: uma síntese do certificado do build do SDK. Para builds específicos, sugerimos que o desenvolvedor de SDKs receba e registre o valor pela app store correspondente.

Isso se aplica somente a SDKs distribuídos por app stores, sejam eles ativados pelo ambiente de execução ou não. Os apps que vinculam os SDKs de forma estática podem usar os mecanismos de dependência atuais.

Considerando que nosso objetivo é gerar o mínimo de impacto possível para os desenvolvedores, é importante que, em casos em que um nível desejado da API com suporte ao SDK Runtime for especificado, os desenvolvedores de apps só precisem ter um único build, independente de ele ser executado em um dispositivo com suporte ao SDK Runtime ou não.

Desenvolvedores de SDKs

No modelo proposto, os desenvolvedores de SDKs RE precisam declarar explicitamente um novo elemento que represente a entidade do SDK ou da biblioteca no manifesto. Além disso, é necessário informar um conjunto de valores semelhante ao da dependência e uma versão secundária:

  • Nome: nome do pacote do SDK ou da biblioteca.
  • Versão principal: código da versão principal do SDK.
  • Versão secundária: código da versão secundária do SDK.

Caso os desenvolvedores de SDKs RE tenham outros SDKs do mesmo tipo como dependências no momento da compilação, vai ser necessário as declarar da mesma maneira que desenvolvedores de apps declarariam essas mesmas dependências. Os SDKs RE que dependem de SDKs não RE precisaram ser vinculados a eles de forma estática. Isso pode introduzir problemas que vão ser detectados durante a compilação ou durante a fase de testes se os SDKs não RE exigirem funcionalidades a que o SDK Runtime não oferece suporte ou se precisarem ser executados no processo do app.

É provável que os desenvolvedores de SDKs RE queiram continuar a oferecer suporte a dispositivos não compatíveis com RE, como o Android 12 ou versões anteriores e dispositivos básicos que usam o Android 13 e têm recursos de sistema muito limitados, conforme mencionado na seção Integridade do sistema deste documento. Estamos trabalhando em abordagens para garantir que os desenvolvedores de SDKs possam manter uma única base de código que ofereça suporte a ambientes RE e não RE.

Builds

Desenvolvedores de apps

Os desenvolvedores de apps vão observar poucas mudanças na etapa de criação. As dependências do SDK, sejam elas distribuídas localmente ou pela app store (RE ou não), vão precisar existir na máquina para inspeção, compilação e criação. Nossa proposta é que o Android Studio extraia esses detalhes do desenvolvedor do app com o uso normal e torne esse processo o mais transparente possível.

Embora seja esperado que um build de depuração inclua todo o código e os símbolos para fazer parte do build de depuração e ter capacidade de depuração, nos builds de lançamento, todos os SDKs distribuídos pela app store (RE ou não) vão poder ser removidos do artefato final.

Estamos no início da fase de desenvolvimento e vamos compartilhar mais informações à medida que avançarmos.

Desenvolvedores de SDKs

Estamos trabalhando em um caminho para garantir que as versões não RE e RE de um SDK possam ser incorporadas a um único artefato para distribuição. Isso evitaria que os desenvolvedores de apps precisassem oferecer suporte a builds diferentes para versões RE e não RE de um SDK.

Assim como para os apps, todos os SDKs de dependência distribuídos por app stores precisam existir na máquina para inspeção, compilação e criação. Acreditamos que o Android Studio vai facilitar esse processo.

Testes

Desenvolvedores de apps

Conforme descrito em nossa proposta, os desenvolvedores de apps vão poder testar os apps em dispositivos com o Android 13, como fariam normalmente. Após a criação, o app vai poder ser instalado em um dispositivo ou emulador RE. Esse processo de instalação garante que os SDKs corretos sejam instalados no SDK Runtime do dispositivo ou emulador, independente de os SDKs terem sido extraídos de um repositório remoto ou do cache do sistema de compilação.

Desenvolvedores de SDKs

Os desenvolvedores de SDKs geralmente usam apps de teste internos em dispositivos e emuladores para testar o desenvolvimento. Nossa proposta não muda esse processo. A validação no app vai seguir as mesmas etapas para desenvolvedores de apps definidas acima, com um único artefato de build para apps RE e não RE. Os desenvolvedores de SDKs vão poder percorrer o código, seja no SDK Runtime ou não. No entanto, pode haver algumas limitações no uso de ferramentas avançadas de depuração e criação de perfis. Essa área está em fase de análise.

Distribuição

Nossa proposta de modelo para a separação de um app dos SDKs gerou a possibilidade de distribuição de SDKs por app stores. Essa é uma possibilidade geral que não exclui nenhuma app store específica. Os benefícios são claros:

  • Garantir a qualidade e a consistência dos SDKs.
  • Simplificar a publicação para desenvolvedores SDK.
  • Facilitar o lançamento de atualizações de versões secundárias do SDK para apps instalados.

Para oferecer suporte à distribuição do SDK, uma app store provavelmente vai precisar fornecer a maioria dos recursos abaixo:

  • Um mecanismo para os desenvolvedores de SDK fazerem upload dos SDKs distribuíveis de app stores na loja, os atualizar, reverter e, possivelmente, remover.
  • Um mecanismo para garantir a integridade de um SDK, um app e das procedências deles, além de resolver as dependências.
  • Um mecanismo para os implantar em dispositivos de maneira consistente e confiável e com alto desempenho.

Perguntas frequentes

  1. O que é um SDK relacionado à publicidade?

    Um SDK relacionado a anúncios é aquele que facilita qualquer parte da segmentação de usuários com mensagens para fins comerciais em apps que não pertencem ao anunciante. Isso inclui, entre outros, SDKs de análise em que os grupos de usuários podem ser criados para mais segmentação, SDKs para veiculação de anúncios, SDKs contra abusos e fraudes para anúncios, SDKs de engajamento e SDKs de atribuição.

  2. Qualquer SDK pode ser executado no SDK Runtime?

    Embora o foco inicial seja para SDKs relacionados a anúncios, os desenvolvedores que não são relacionados a anúncios que buscam uma postura que valoriza a privacidade e acreditam que podem operar sob as condições descritas acima podem compartilhar feedback sobre os SDKs executados no SDK Runtime. Entretanto, o SDK Runtime não foi projetado para ser compatível com todos os tipos de SDKs. Além das limitações documentadas, o SDK Runtime provavelmente não é adequado para SDKs que precisam de comunicação com o app de hospedagem em tempo real ou com alta capacidade de processamento.

  3. Por que escolher o isolamento de processos em vez do isolamento em um ambiente de execução baseado em Java?

    Atualmente, o ambiente de execução baseado em Java não facilita prontamente os limites de segurança necessários para as garantias de privacidade desejadas para os usuários do Android. Tentar implementar algo nesses moldes provavelmente vai exigir um esforço de vários anos, sem garantia de sucesso. Portanto, o Sandbox de privacidade utiliza limites de processo de uso, uma tecnologia testada com sucesso e bem compreendida.

  4. Mover SDKs para o processo do SDK Runtime pode diminuir o tamanho de download ou economizar espaço de armazenamento?

    Se vários apps estiverem integrados a SDKs ativados pelo ambiente de execução da mesma versão, isso poderá reduzir o tamanho do download e economizar o espaço em disco.