A quarta versão Beta do Android 17

O Android 17 chegou à versão Beta 4, a última programada para este ciclo de lançamento, um marco importante para a compatibilidade de apps e a estabilidade da plataforma. Seja para ajustar a experiência do usuário do app, garantir uma renderização de ponta a ponta sem problemas ou aproveitar as APIs mais recentes, a versão Beta 4 oferece o ambiente quase final que você precisa para testar. 

Prepare seus apps, bibliotecas, ferramentas e mecanismos de jogos.

Se você desenvolve um SDK do Android, uma biblioteca, uma ferramenta ou um mecanismo de jogo, é fundamental preparar as atualizações necessárias agora para evitar que os desenvolvedores de apps e jogos downstream sejam bloqueados por problemas de compatibilidade e permitir que eles usem os recursos mais recentes do SDK. Informe aos desenvolvedores downstream se forem necessárias atualizações para oferecer suporte total ao Android 17.

O teste envolve a instalação do app de produção ou de um app de teste que use sua biblioteca ou mecanismo usando o Google Play ou outros meios em um dispositivo ou emulador com o Android 17 Beta 4. Percorra todos os fluxos do app e procure problemas funcionais ou de interface. Cada versão do Android contém mudanças na plataforma que melhoram a privacidade, a segurança e a experiência geral do usuário. Analise as mudanças de comportamento que afetam os apps em execução e com destino ao Android 17 para focar seus testes, incluindo:

• Redimensionamento em telas grandes:ao direcionar ao Android 17, não será mais possível desativar as restrições de orientação, redimensionamento e proporção em telas grandes.
• Carregamento dinâmico de código:se o app for direcionado ao Android 17 ou versões mais recentes, a proteção de carregamento dinâmico de código (DCL, na sigla em inglês) mais seguro introduzida no Android 14 para arquivos DEX e JAR agora se estende às bibliotecas nativas. Todos os arquivos nativos carregados usando System.load() precisam ser marcados como somente leitura. Caso contrário, o sistema vai gerar um UnsatisfiedLinkError.
• Ativar CT por padrão: a transparência de certificados (CT, na sigla em inglês) é ativada por padrão. No Android 16, a CT está disponível, mas os apps precisavam ativar.
• Proteções de rede local:os apps destinados ao Android 17 ou versões mais recentes têm o acesso à rede local bloqueado por padrão. Se possível, use seletores que preservam a privacidade e a nova permissão ACCESS_LOCAL_NETWORK para acesso amplo e persistente.
• Proteção de áudio em segundo plano:a partir do Android 17, o framework de áudio aplica restrições às interações de áudio em segundo plano, incluindo a reprodução de áudio, solicitações de seleção de áudio e APIs de mudança de volume. Com base no seu feedback, fizemos algumas mudanças desde a versão Beta 2, incluindo a restrição de FGS em uso do targetSDK e a isenção de áudio de alarme. Confira todos os detalhes nas orientações atualizadas.

Limites de memória para apps

O Android está lançando limites de memória para apps com base na RAM total do dispositivo para criar um ambiente mais estável e determinista para seus aplicativos e usuários do Android. No Android 17, os limites são definidos de forma conservadora para estabelecer as bases do sistema, visando vazamentos de memória extremos e outros valores atípicos antes que eles causem instabilidade em todo o sistema, o que resulta em travamentos na interface, maior consumo de bateria e encerramento de apps. Embora o impacto seja mínimo na grande maioria das sessões de apps, recomendamos as seguintes práticas recomendadas de memória, incluindo o estabelecimento de um valor de referência para a memória.

Na implementação atual, getDescription em ApplicationExitInfo vai conter a string "MemoryLimiter" se o app tiver sido afetado. Também é possível usar a criação de perfil baseada em gatilhos com TRIGGER_TYPE_ANOMALY para receber heap dumps coletados quando o limite de memória é atingido.

Para ajudar você a encontrar vazamentos de memória, o Android Studio Panda adiciona a integração do LeakCanary diretamente ao Android Studio Profiler como uma tarefa dedicada, contextualizada no ambiente de desenvolvimento integrado e totalmente integrada ao seu código-fonte.

Um consumo de memória menor se traduz diretamente em um desempenho mais suave, maior duração da bateria e uma experiência premium em todos os formatos. Vamos construir juntos um futuro mais rápido e confiável para o ecossistema Android!

Acionadores de criação de perfil para anomalias de apps

O Android apresenta um serviço de detecção de anomalias no dispositivo que monitora comportamentos que consomem muitos recursos e possíveis regressões de compatibilidade. Integrado ao ProfilingManager, esse serviço permite que o app receba artefatos de criação de perfil acionados por eventos específicos detectados pelo sistema.

Use o gatilho TRIGGER_TYPE_ANOMALY para detectar problemas de desempenho do sistema, como chamadas excessivas de binder e uso excessivo de memória. Quando um app viola os limites de memória definidos pelo SO, o acionador de anomalias permite que os desenvolvedores recebam heap dumps específicos do app para ajudar a identificar e corrigir problemas de memória. Além disso, para spam excessivo de binder, o acionador de anomalias fornece um perfil de amostragem de pilha em transações de binder.

Esse callback de API ocorre antes de qualquer restrição imposta pelo sistema. Por exemplo, ela pode ajudar os desenvolvedores a coletar dados de depuração antes que o app seja encerrado pelo sistema devido ao limite de memória excedido. Para entender como usar o gatilho, confira nossa documentação sobre criação de perfil com base em gatilhos.

    val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList<ProfilingTrigger>()  
    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 
    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)
}

Criptografia pós-quântica (PQC) no Android Keystore

O Android Keystore adicionou suporte ao ML-DSA (Module-Lattice-Based Digital Signature Algorithm), padronizado pelo NIST. Em dispositivos compatíveis, é possível gerar chaves ML-DSA e usá-las para produzir assinaturas resistentes a ataques quânticos, inteiramente no hardware seguro do dispositivo. O Android Keystore expõe as variantes de algoritmo ML-DSA-65 e ML-DSA-87 pelas APIs padrão da arquitetura criptográfica do Java: KeyPairGenerator, KeyFactory e Signature. Para mais detalhes, consulte nossa documentação para desenvolvedores.

KeyPairGenerator generator = KeyPairGenerator.getInstance(
        “ML-DSA-65”, "AndroidKeyStore");
generator.initialize(
        new KeyGenParameterSpec.Builder(
                “my-key-alias”,
                KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)
        .build());
KeyPair keyPair = generator.generateKeyPair();

Começar a usar o Android 17

Você pode registrar qualquer dispositivo Pixel compatível para receber essa e as próximas atualizações over the air do Android Beta. Se você não tiver um dispositivo Pixel, poderá usar as imagens do sistema de 64 bits com o Android Emulator no Android Studio.

Se você já participa do Programa Android Beta, vai receber uma atualização over the air para o Beta 4.

Continue relatando problemas e enviando solicitações de recursos na página de feedback. Quanto mais cedo recebermos seu feedback, mais melhorias poderão ser incluídas na versão final.

Para ter a melhor experiência de desenvolvimento com o Android 17, recomendamos usar a prévia mais recente do Android Studio (Panda). Depois de configurar, faça o seguinte:

• Compile com o novo SDK, teste em ambientes de CI e informe qualquer problema no nosso rastreador na página de feedback.
• Teste a compatibilidade do seu app atual, saiba se ele é afetado pelas mudanças no Android 17 e instale-o em um dispositivo ou emulador com o Android 17 para fazer testes extensivos.

Vamos atualizar as imagens do sistema de pré-lançamento/Beta e o SDK regularmente durante o ciclo de lançamento do Android 17. Depois de instalar um build Beta, você vai receber automaticamente atualizações over the air para todas as prévias e versões Beta futuras.

Para mais informações, acesse o site para desenvolvedores do Android 17.

Participe da conversa

Seu feedback continua sendo nosso recurso mais valioso. Seja você um usuário inicial no canal Canary ou um desenvolvedor de apps testando o Beta 4, participe das nossas comunidades e envie feedback. Estamos ouvindo.