| Key concepts | Set up your development environment | Build an RE SDK | Consume the RE SDK | 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 para o SDK Runtime.
Glossário
- SDK ativado pelo ambiente de execução (SDK RE): um SDK criado para ser executado no ambiente do SDK Runtime e se comunicar com o app por comunicação interprocesso (IPC).
- SDK ciente do tempo de execução (SDK RA): um SDK que não é ativado no momento de execução, vinculado ao app
de forma estática, que pode conter o código do SDK atual e um novo código para chamar o SDK ativado no momento de execução.
- Às vezes, isso também é chamado de vinculado de forma estática ou SDK estático.
- Shims: uma biblioteca do Jetpack que ajuda a abstrair a comunicação entre processos ou a comunicação interprocessos (IPC) e a manter a mesma interface do 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 momento de execução) são executados no mesmo dispositivo, e essa comunicação acontece entre os processos.
Para ajudar com esses desafios, criamos as seguintes bibliotecas e ferramentas do Jetpack para simplificar a integração do app com o SDK no SDK Runtime:
- Biblioteca shim:a biblioteca wrapper (ou shim) ajuda a abstrair a comunicação entre processos ou a comunicação interprocessos (IPC). Ele também ajuda a manter a mesma interface do SDK do app.
- Biblioteca de compatibilidade com versões anteriores:essa biblioteca processa a compatibilidade com versões anteriores, garantindo que seu SDK seja compatível, independentemente de o SDK Runtime estar disponível ou não.
- Biblioteca de interface:também oferecemos bibliotecas para processar apresentações remotas, como buscar a interface do SDK ativado pelo ambiente de execução ou redimensionar e refazer o layout das visualizações.
Mudanças no fluxo de instalação
Ao criar o 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.
O 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 no nome e na versão do SDK ativado pelo ambiente de execução, e essa dependência é resolvida pelo app de instalação.
Depois que o APK do SDK é fornecido pelo instalador, a instalação começa com a instalação do APK do SDK. Se for bem-sucedido, o APK do app será instalado.
O fluxo é diferente se o app estiver instalado no Android 13 e versões anteriores e em dispositivos que não oferecem suporte ao SDK Runtime. Nesse cenário, a loja instala um único APK que contém o SDK ativado pelo ambiente 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 na produção, a app store vai criar e instalar o APK do SDK correto desse ASB.
Compatibilidade com versões anteriores
Como o SDK Runtime foi introduzido no Android 14, precisamos oferecer suporte a versões anteriores sem gerar sobrecarga para os desenvolvedores de SDK ou app.
Para lidar com a compatibilidade com versões anteriores no Android 13 e versões anteriores, apresentamos uma biblioteca do Jetpack que pode executar o SDK ativado pelo ambiente de execução sem problemas, independentemente do suporte do dispositivo ao SDK Runtime.
Ao seguir este guia, o SDK ativado pelo ambiente de execução fica compatível com versões anteriores por padrão, e não é necessário seguir outras etapas.
Destacamos as ações conectadas à compatibilidade com versões anteriores em etapas relevantes, mas, em termos gerais, você precisa garantir que declarou as dependências corretas e que está usando as classes *Compat sempre que aplicável.
Migrar SDKs
Se você tiver um SDK que gostaria de migrar para o ambiente de execução, não será necessário refazer 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 ativado pelo ambiente de execução.
Recomendamos as três fases a seguir para migrar um SDK para o ambiente de execução do SDK:
- Criação de um SDK ativado no momento da execução para períodos de transição com um SDK correspondente compatível com o ambiente de execução. Isso permite migrar a lógica de negócios de forma incremental do SDK atual e oferece uma plataforma de teste para testes A/B.
- Mover toda a lógica de negócios do SDK para um estado estável com um SDK compatível com o ambiente de execução para facilitar a migração do app
- Suporte a apps interessados com migração completa para consumir o SDK ativado pelo ambiente de execução diretamente, sem um SDK compatível com o ambiente de execução
Fase 1: período de transição: SDK compatível com o ambiente de execução
Para começar, escolha manter parte da lógica de negócios no SDK compatível com o ambiente de execução. Chamamos isso de SDK compatível com o tempo de execução ou wrapper no app.
Essa abordagem permite manter todos ou alguns dos recursos do SDK na biblioteca de apps estática, junto com um SDK ativado pelo ambiente de execução recém-criado.
Isso permite migrar seus casos de uso de forma incremental para o SDK ativado pelo ambiente de execução e testar o SDK ativado pelo ambiente de execução em relação ao SDK atual.
Nessa fase, o desenvolvedor do app não precisa mudar nada na forma como consome o SDK, porque é a biblioteca de apps estática (SDK compatível com o ambiente de execução) que faz o trabalho necessário para consumir o SDK compatível com o ambiente de execução.
Fase 2: estado estável: SDK compatível com o ambiente de execução
Em contraste com o SDK compatível com o ambiente de execução, um wrapper fino ou um SDK fino compatível com o ambiente de execução (thin RA_SDK) contém apenas a tradução da API e o código de chamada de SDK ativado no ambiente de execução no SDK da biblioteca vinculada estaticamente.
Nesse estágio, você já migrou todo o código do SDK do SDK da biblioteca estática do app para o SDK ativado no momento da execução.
Os desenvolvedores de apps não precisam fazer nenhuma mudança da fase 1, porque o SDK compatível com o ambiente de execução no app lida com a chamada no SDK ativado pelo ambiente de execução no SDK Runtime.
Fase 3: migração completa
Nesta fase final, você migrou todos os recursos do SDK para o SDK ativado no momento da execução e removeu todas as bibliotecas estáticas do app.
Nesse 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 roteadas pelo sistema para o SDK Runtime, onde o SDK ativado pelo ambiente de execução é carregado automaticamente.
