Esta página foi traduzida pela API Cloud Translation.

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

Key concepts

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 os SDKs para o SDK Runtime.

Glossário

SDK ativado pelo ambiente de execução (SDK RE): um SDK criado para ser executado no SDK Runtime. e se comunica com o aplicativo pela comunicação entre processos (IPC, na sigla em inglês).
SDK com reconhecimento de ambiente de execução (SDK RA): um SDK não ativado pelo ambiente de execução, vinculado ao app. estaticamente, que pode conter o código do SDK existente, bem como um novo código para chamar no SDK ativado pelo ambiente de execução.
- Às vezes, esse recurso também é chamado de SDK estático ou vinculado estaticamente.
Shim: uma biblioteca do Jetpack que ajuda na comunicação abstrata entre diferentes. de comunicação entre processos (IPC) e manter a mesma interface do SDK do app.

Arquitetura do SDK Runtime

O SDK Runtime adota uma tipo client-server de modelo.

A principal diferença é que o "cliente" (app) e o "server" (runtime-enabled SDKs) são executados no mesmo dispositivo, e essa comunicação acontece entre processos.

Para ajudar com esses desafios, criamos o seguinte Bibliotecas e ferramentas do Jetpack para simplificar Integração do app-SDK no SDK Runtime:

Biblioteca Shim:a biblioteca wrapper (ou shim) ajuda a abstrair comunicação entre processos ou comunicação entre processos (IPC). Ela também ajuda a manter a mesma interface do SDK do app.
Biblioteca Backcompatibilidade:essa biblioteca lida com a compatibilidade com versões anteriores, tornando a compatibilidade do SDK, independentemente de o SDK Runtime ser disponíveis ou não.
Biblioteca de IU:também fornecemos bibliotecas para lidar com apresentações remotas, como a busca da interface do SDK ativado pelo ambiente de execução ou o redimensionamento e novo layout de visualizações.

Visão geral da arquitetura do SDK Runtime — Diagrama mostrando um app interagindo com o SDK ativado pelo ambiente de execução usando 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ê crie 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 seu SDK ativado pelo ambiente de execução: esse APK separado contém os arquivos Código do SDK, mas nenhum código do app.

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

Depois que o APK do SDK for fornecido pelo instalador, a instalação começará com o Instalação do APK do SDK. Após o sucesso, ele instala o APK do app.

O fluxo será diferente se o app for instalado no Android 13 e versões anteriores e que não têm suporte ao SDK Runtime. Neste cenário, a loja instala Um único APK com 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 depende desse SDK na produção, a app store cria o APK do SDK correto desse ASB e o instala.

Compatibilidade com versões anteriores

Como o SDK Runtime foi lançado no Android 14, precisávamos oferecer suporte versões anteriores sem introduzir overhead para os desenvolvedores de SDK ou de apps.

Para lidar com a compatibilidade com versões anteriores no Android 13 e versões anteriores, lançamos uma biblioteca do Jetpack que pode executar o SDK ativado pelo ambiente de execução sem problemas, seja qual for o 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 é preciso seguir outras etapas.

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

Migrar SDKs atuais

Se você quer migrar um SDK para o ambiente de execução, não é necessário refatorar toda a base de código de uma só vez. Em vez disso, você pode optar por migrar a lógica do SDK existente de forma incremental para o novo SDK ativado pelo ambiente de execução.

Recomendamos as três fases a seguir para migrar um SDK existente para o SDK Ambiente de execução:

Criar um SDK ativado pelo ambiente de execução para o período de transição com um SDK compatível com ambiente de execução completo. Isso permite que você migre de forma incremental a lógica de negócios do SDK existente e oferece uma plataforma de testes para testes A/B.
Mudança de toda a lógica de negócios do SDK para um estado estável (link em inglês) com um SDK fino baseado no ambiente de execução para facilitar a migração do app.
Suporte a apps interessados com migração completa para consumir seu SDK ativado pelo ambiente de execução diretamente sem um SDK fino baseado no ambiente de execução

Fase 1 - Período de transição: SDK avançado com reconhecimento de ambiente de execução

Para começar, você pode optar por manter parte da sua lógica de negócios no SDK com reconhecimento de ambiente de execução. Chamamos isso de SDK espesso com reconhecimento de ambiente de execução ou wrapper no app.

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

Assim, é possível migrar de forma incremental seus casos de uso para a versão e para testar o SDK ativado pelo ambiente de execução em relação ao SDK atual.

Nessa fase, o desenvolvedor do aplicativo não precisa alterar nada na forma como consome seu SDK, porque é sua biblioteca de aplicativos estática (SDK com reconhecimento de tempo de execução) que faz o trabalho necessário para consumir seu SDK com reconhecimento de ambiente de execução.

O app chama um SDK estático que reconhece o ambiente de execução e pode conter uma camada de conversão para chamar o SDK ativado pelo ambiente de execução, além de outra lógica de negócios.

Fase 2: estado estável: SDK fino com reconhecimento de ambiente de execução

Em contraste com o SDK espesso com reconhecimento de ambiente de execução, um wrapper fino ou um SDK fino com reconhecimento de ambiente de execução (RA_SDK fino), contém apenas a tradução de API e chamadas de SDK ativadas pelo ambiente de execução. no SDK da biblioteca vinculada estaticamente.

Neste estágio, você já deve ter migrado todo o código do SDK de sua e no SDK ativado pelo ambiente de execução.

Os desenvolvedores de aplicativos não precisam fazer alterações a partir da fase 1 porque seu modelo o SDK fino com reconhecimento de ambiente de execução processa a chamada para seu SDK ativado pelo ambiente de execução dentro do SDK Ambiente de execução.

O app chama um SDK estático dentro dele mesmo que contém apenas uma camada de conversão. — O app chama um SDK estático dentro dele mesmo 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 a SDK ativado pelo ambiente de execução e removeu todas as bibliotecas estáticas do app.

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

As chamadas do SDK são roteadas pelo sistema para o SDK Runtime, em que seu SDK ativado pelo ambiente de execução será carregado automaticamente.

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

Introdução

Etapa 2: configurar o ambiente de desenvolvimento