O Android 17 chegou ao Beta 4, o último beta programado deste ciclo de lançamento, um marco crítico para a compatibilidade de apps e a estabilidade da plataforma. Seja para ajustar a experiência do usuário do seu app, garantir uma renderização suave de ponta a ponta ou aproveitar as APIs mais recentes, a versão Beta 4 oferece o ambiente quase final necessário para testes. 

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

Se você desenvolve um SDK do Android, uma biblioteca, uma ferramenta ou um mecanismo de jogos, é 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 segmentem os recursos mais recentes do SDK. Informe seus 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 usa sua biblioteca ou mecanismo no Google Play ou por outros meios em um dispositivo ou emulador que executa o Android 17 Beta 4. Trabalhe em 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. Revise as mudanças de comportamento que afetam os apps executados e direcionados ao Android 17 para concentrar seus testes, incluindo o seguinte:

• Redimensionamento em telas grandes:depois de segmentar o Android 17, não será mais possível desativar a manutenção das 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) mais seguro introduzida no Android 14 para arquivos DEX e JAR agora se estende a 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 a CT por padrão: a transparência de certificado (CT) está ativada por padrão. (No Android 16, a CT está disponível, mas os apps precisam ativar.)
• Proteções de rede local:os apps direcionados 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.
• Reforço da proteção de áudio em segundo plano:a partir do Android 17, o framework de áudio impõe restrições às interações de áudio em segundo plano, incluindo 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 o controle de acesso do targetSDK durante a execução em primeiro plano e a isenção do áudio de alarmes. Confira todos os detalhes no guia atualizado.

Limites de memória de apps

O Android está introduzindo limites de memória para apps com base na RAM total do dispositivo para criar um ambiente mais estável e determinístico para seus aplicativos e usuários do Android. No Android 17, os limites são definidos de forma conservadora para estabelecer valores de referência do sistema, visando vazamentos de memória extremos e outros outliers antes que eles causem instabilidade em todo o sistema, resultando em renderização lenta da interface, consumo elevado da bateria e encerramento de apps. Embora prevemos um impacto mínimo na grande maioria das sessões de apps, recomendamos seguir as 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 foi afetado. Você também pode usar o criação de perfil com base em gatilho 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 no Android Studio Profiler como uma tarefa dedicada, contextualizada no IDE e totalmente integrada ao seu código-fonte.

Um consumo de memória mais leve 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 exigem muitos recursos e possíveis regressões de compatibilidade. Integrado ao ProfilingManager, esse serviço permite que seu 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 de vinculador e uso da memória excessivos. Quando um app viola os limites de memória definidos pelo SO, o gatilho de anomalia permite que os desenvolvedores recebam despejos de heap específicos do app para ajudar a identificar e corrigir problemas de memória. Além disso, para spam excessivo do binder, o gatilho de anomalia fornece um perfil de amostragem de pilha em transações do binder.

Esse callback da API ocorre antes de qualquer aplicação obrigatória imposta pelo sistema. Por exemplo, ele pode ajudar os desenvolvedores a coletar dados de depuração antes que o app seja encerrado pelo sistema por exceder os limites de memória. Para entender como usar o gatilho, consulte 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 (algoritmo de assinatura digital baseado em módulo-reticulado) padronizado pelo NIST. Em dispositivos compatíveis, é possível gerar chaves ML-DSA e usá-las para produzir assinaturas resistentes a ataques quânticos, tudo no hardware seguro do dispositivo. O Android Keystore expõe as variantes do algoritmo ML-DSA-65 e ML-DSA-87 pelas APIs padrão da Java Cryptographic Architecture: 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 outras atualizações do Android Beta over the air. Se você não tiver um dispositivo Pixel, use 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 a versã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 que você use a versão 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 rastreador na página de feedback.
• Teste a compatibilidade do app atual, saiba se ele é afetado por mudanças no Android 17 e instale o app em um dispositivo ou emulador com o Android 17 para testá-lo extensivamente.

Vamos atualizar regularmente as imagens do sistema de prévia/Beta e o SDK durante todo o ciclo de lançamento do Android 17. Depois de instalar um build Beta, você vai receber automaticamente atualizações OTA de todas as prévias e versões Beta mais recentes.

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

Participe da conversa

Seu feedback continua sendo nosso recurso mais valioso. Seja um usuário dos primeiros testes no canal Canary ou um desenvolvedor de apps testando na versão Beta 4, participe das nossas comunidades e envie feedback. Estamos ouvindo.