Teste sobre os fundamentos do SDK Runtime

O SDK Runtime tem como objetivo oferecer vários benefícios importantes para o ecossistema do Android. Quais das seguintes opções são as principais vantagens enfatizadas para desenvolvedores de apps e SDKs, além de usuários?

Escolha quantas respostas você achar adequado.

Melhoria na privacidade do usuário e na segurança do aplicativo com o isolamento de recursos e códigos de SDKs de terceiros em um processo de execução separado e restrito.

Melhoria na estabilidade do app e responsabilidade por falhas mais precisas ao conter operações do SDK no próprio processo dedicado, separado do aplicativo host.

O acesso direto e aumentado de SDKs de terceiros ao conjunto completo de permissões do app host para maximizar a funcionalidade.

Um modelo de distribuição de SDK mais flexível, que permite que os SDKs sejam atualizados de forma independente dos lançamentos de apps por canais de distribuição de apps, o que pode levar a correções críticas mais rápidas.

Exigência de que todos os SDKs de terceiros utilizem um único ambiente de execução compartilhado em todos os apps de um dispositivo para otimizar o uso de recursos do sistema.

Qual declaração descreve com precisão um SDK habilitado para execução (RE SDK)?

Ele é executado no processo do app e se comunica diretamente com outros SDKs no app.

É principalmente uma camada de tradução que ajuda os apps a migrar para o uso de SDKs no SDK Runtime.

Ele é executado dentro do processo isolado do SDK Runtime.

Ele é usado apenas para depurar as funcionalidades do SDK no Android Studio.

Considerando o novo paradigma de distribuição para SDKs ativados pelo ambiente de execução (SDKs RE), qual das afirmações abaixo melhor descreve como os SDKs RE são disponibilizados para apps e instalados nos dispositivos dos usuários?

Os SDKs RE são sempre compilados diretamente no APK do app host, de forma semelhante aos SDKs tradicionais, mas só são ativados quando o SDK Runtime está presente.

Os SDKs de ambiente de execução podem ser publicados em app stores como entidades distintas. A app store gerencia a instalação no dispositivo, e cada app carrega os SDKs RE necessários no próprio processo privado do SDK Runtime.

Todos os SDKs RE necessários são pré-instalados como parte do sistema operacional Android, e os apps simplesmente declaram quais pretendem usar.

Os apps fazem o download dos SDKs de RE diretamente dos servidores do provedor de SDK sempre que necessário, garantindo que a versão mais recente seja sempre usada sem a participação da app store.

O SDK Runtime muda fundamentalmente a integração do SDK executando SDKs de terceiros em um processo separado. Como esse isolamento de processo resolve principalmente um desafio importante do modelo de SDK tradicional e acoplado?

Ele garante que os SDKs de RE consumam muito menos bateria, transferindo todas as tarefas para uma linha de execução do sistema de baixa prioridade.

Ele permite que os SDKs RE operem com privilégios elevados do sistema, ignorando o modelo de permissão do app para realizar operações avançadas.

Ele cria limites claros, limitando o acesso direto de um SDK aos dados e recursos internos do app host, reduzindo os riscos associados à coleta de dados não divulgados e melhorando a segurança geral.

Ele padroniza os componentes da interface que todos os SDKs de RE precisam usar, garantindo uma aparência consistente em todos os apps que os usam.

Qual é o objetivo principal das ferramentas de geração de "shim" no contexto do SDK Runtime?

Para empacotar SDKs ativados pelo ambiente de execução em Android SDK Bundles (ASBs).

Para aplicar restrições de permissão em SDKs ativados pelo ambiente de execução durante a compilação.

Para abstrair a complexidade da comunicação entre processos (IPC) de baixo nível entre o app/SDK Aware de ambiente de execução (RA SDK) e o SDK RE.

Fornecer componentes de interface pré-criados para SDKs RE para exibir anúncios.

Ao criar um SDK de RE, o que o desenvolvedor do SDK precisa implementar para definir o ponto de entrada do SDK, que normalmente estende uma classe gerada por shim?

Uma atividade que inicia as principais funcionalidades do SDK.

Uma classe que estende o `SandboxedSdkProviderCompat` (ou um derivado gerado por shim com base em `@PrivacySandboxService`) e substitui o método "create*".

Um BroadcastReceiver que detecta solicitações de carregamento do SDK do app.

Um ContentProvider para compartilhar dados de configuração iniciais com o app.

Ao depurar um SDK RE em um dispositivo ou emulador em que o SDK Runtime está ativo, em qual processo o depurador precisa ser anexado para inspecionar o código do SDK RE?

O processo principal do aplicativo cliente.

O processo "system_server".

O processo _sdk_sandbox.

O processo de depuração interno do Android Studio.

De acordo com as fases de migração recomendadas de um SDK para o SDK Runtime, qual é normalmente a primeira etapa?

Exija imediatamente que todos os apps consumam o SDK ativado pelo ambiente de execução diretamente, sem nenhuma camada de tradução.

Crie um SDK com ativação de execução fina com toda a lógica de negócios restante em um SDK no app legado.

Crie um SDK ativado pelo ambiente de execução para o período de transição com um SDK Aware de ambiente de execução para migração incremental e testes A/B.

Descontinuar o SDK atual e oferecer apenas o novo SDK ativado pelo ambiente de execução desde o início.