Criar e consumir um SDK ativado pelo ambiente de execução

1
 Key concepts
2
 Set up your development environment
3
 Build an RE SDK
4
 Consume the RE SDK
5
 Testing, and building for distribution

Principais conceitos

Esta seção explica a arquitetura do SDK Runtime, como os SDKs ativados pelo ambiente de execução são instalados, a compatibilidade com versões anteriores e como migrar SDKs atuais para o SDK Runtime.

Glossário

  • SDK ativado no momento da execução (RE SDK): um SDK criado para ser executado no ambiente do SDK Runtime e se comunicar com o app por comunicação entre processos (IPC).
  • SDK compatível com o tempo de execução (RA SDK): um SDK não ativado no tempo de execução, vinculado ao app de forma estática, que pode conter seu código de SDK atual e um novo código para chamar seu SDK ativado no tempo de execução.
    • Às vezes, isso também é chamado de vinculado estaticamente ou SDK estático.
  • Shim: uma biblioteca do Jetpack que ajuda a abstrair a comunicação entre processos ou comunicação entre processos (IPC) e manter a mesma interface app-SDK.

Arquitetura do SDK Runtime

O SDK Runtime adota um modelo do tipo cliente-servidor.

A principal diferença é que o "cliente" (app) e o "servidor" (SDKs ativados no tempo de execução) são executados no mesmo dispositivo, e essa comunicação acontece entre processos.

Para ajudar com esses desafios, criamos as seguintes bibliotecas e ferramentas do Jetpack para simplificar a integração de SDKs de apps no SDK Runtime:

  • Biblioteca shim:a biblioteca wrapper (ou shim) ajuda a abstrair a comunicação entre processos ou a comunicação entre processos (IPC). Ele também ajuda a manter a mesma interface de SDK do app.
  • Biblioteca de compatibilidade com versões anteriores:essa biblioteca processa a compatibilidade com versões anteriores, garantindo que o SDK seja compatível, esteja ou não disponível o SDK Runtime.
  • Biblioteca de interface:também fornecemos bibliotecas para lidar com a apresentação remota, como buscar a interface do SDK ativado para execução ou redimensionar e reestruturar visualizações.
Visão geral da arquitetura do SDK Runtime
Diagrama mostrando um app interagindo com o SDK ativado pelo ambiente de execução por diferentes bibliotecas.

Mudanças no fluxo de instalação

Ao criar seu SDK ativado pelo ambiente de execução no Android Studio ou em outras ferramentas, você cria um Android SDK Bundle (ASB), um formato de publicação para SDKs ativados pelo ambiente de execução.

A bundletool processa o ASB para produzir um APK para o SDK ativado pelo ambiente de execução. Esse APK separado contém o código do SDK, mas não o código do app.

O arquivo de manifesto do app declara uma dependência do nome e da versão do SDK ativado pelo ambiente de execução, e essa dependência é resolvida pelo app instalador.

Depois que o APK do SDK é fornecido pelo instalador, a instalação começa com a instalação do APK do SDK. Em caso de sucesso, ele instala o APK do app.

O fluxo é diferente se o app estiver instalado no Android 13 e em versões anteriores, e em dispositivos que não são compatíveis com o SDK Runtime. Nesse cenário, a loja instala um único APK que contém o SDK ativado no tempo de execução e o código do app. Leia a seção de distribuição para saber mais.

Sempre que um app depender desse SDK em produção, a app store vai criar o APK correto do SDK no ASB e instalá-lo.

Compatibilidade com versões anteriores

Como o SDK Runtime foi introduzido no Android 14, precisávamos oferecer suporte a versões anteriores sem gerar sobrecarga para desenvolvedores de SDKs ou apps.

Para lidar com a compatibilidade com versões anteriores no Android 13 e versões anteriores, apresentamos uma biblioteca do Jetpack que pode executar sem problemas o SDK ativado para tempo de execução, independente do suporte do dispositivo ao SDK Runtime.

Seguir este guia torna seu SDK ativado pelo ambiente de execução compatível com versões anteriores por padrão, e não há mais etapas a serem seguidas.

Destacamos as ações relacionadas à compatibilidade com versões anteriores em etapas relevantes, mas, em termos gerais, você precisa declarar as dependências corretas e usar as classes *Compat sempre que aplicável.

Migrar SDKs atuais

Se você tiver um SDK que queira migrar para o Runtime, não é necessário refatorar toda a base de código de uma só vez. Em vez disso, você pode migrar a lógica do SDK atual de forma incremental para o novo SDK habilitado para o runtime.

Recomendamos as três fases a seguir para migrar um SDK atual para o SDK Runtime:

  1. Criar um SDK período de transição ativado no ambiente de execução junto com um SDK grosso equivalente que reconhece o ambiente de execução. Isso permite migrar incrementalmente a lógica de negócios do SDK atual e oferece uma plataforma de testes A/B.
  2. Mover toda a lógica de negócios do SDK para um estado estável, além de um SDK complementar simples compatível com o ambiente de execução para facilitar a migração do app.
  3. Oferecer suporte a apps interessados com migração completa para consumir seu SDK ativado pelo ambiente de execução diretamente, sem um SDK simples compatível com o ambiente de execução

Fase 1: período de transição: SDK espesso com reconhecimento de tempo de execução

Comece mantendo parte da lógica de negócios no SDK compatível com o tempo de execução. Chamamos isso de SDK espesso com reconhecimento de tempo de execução ou wrapper no app.

Essa abordagem permite manter todos ou alguns dos recursos do SDK na biblioteca estática do app, junto com um SDK ativado pelo ambiente de execução recém-criado.

Isso permite migrar incrementalmente seus casos de uso para o SDK ativado pelo ambiente de execução e testar o SDK ativado pelo ambiente de execução com o SDK atual.

Nessa fase, o desenvolvedor do app não precisa mudar nada na forma como consome seu SDK, porque é a biblioteca de app estática (SDK compatível com o tempo de execução) que faz o trabalho necessário para consumir o SDK compatível com o tempo de execução.

O app chama um SDK estático e compatível com o ambiente de execução dentro de si mesmo, que pode conter uma camada de tradução para chamar o SDK ativado pelo ambiente de execução e outras lógicas de negócios.
O app chama um SDK estático e compatível com o tempo de execução dentro dele, que pode conter uma camada de tradução para chamar o SDK ativado no tempo de execução, bem como outras lógicas de negócios.

Fase 2: estado estável: SDK leve com reconhecimento de tempo de execução

Em contraste com o SDK espesso compatível com o tempo de execução, um wrapper fino ou um SDK fino compatível com o tempo de execução (thin RA_SDK) contém apenas tradução de API e código de chamada de SDK ativado para tempo de execução na biblioteca SDK vinculada estaticamente.

Nesta etapa, você já deve ter migrado todo o código do SDK da biblioteca estática do app para o SDK ativado no tempo de execução.

Os desenvolvedores de apps não precisam fazer mudanças na fase 1 porque o SDK fino no app compatível com o ambiente de execução lida com a chamada para o SDK ativado pelo ambiente de execução no SDK Runtime.

O app chama um SDK estático dentro de si mesmo que contém apenas uma camada de tradução.
O app chama um SDK estático dentro dele que contém apenas uma camada de tradução.

Fase 3: migração completa

Nesta fase final, você migrou todos os recursos do SDK para o SDK ativado para tempo de execução e removeu todas as bibliotecas estáticas do app.

Neste ponto, os clientes do app não precisam mais incluir as bibliotecas nos builds, mas apenas listar as dependências do SDK no manifesto e incluir as chamadas do SDK no código do app.

As chamadas do SDK são encaminhadas pelo sistema para o SDK Runtime, onde o SDK ativado pelo ambiente de execução é carregado automaticamente.

Arquitetura da fase de migração completa, em que o código de anúncio do app invoca o SDK ativado para tempo de execução diretamente.
Arquitetura da fase completa de migração, em que o código de anúncio do app invoca o SDK ativado no tempo de execução diretamente.


Introdução

Etapa 2: configurar seu ambiente de desenvolvimento