O Android 17 chegou à versão Beta 4, a última versão Beta programada desse ciclo de lançamento, um marco fundamental para a compatibilidade de apps e a estabilidade da plataforma. Se você estiver ajustando a experiência do usuário do app, garantindo uma renderização suave de ponta a ponta ou aproveitando 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, biblioteca, ferramenta ou mecanismo de jogo, é fundamental preparar todas 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 aos desenvolvedores downstream se as atualizações forem necessárias 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 usando o Google Play ou outros meios em um dispositivo ou emulador com 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. Analise as mudanças de comportamento que afetam os apps em execução e direcionados ao Android 17 para concentrar seus testes, incluindo o seguinte:

• Redimensionamento em telas grandes: depois de direcionar o Android 17, não será mais possível desativar a manutenção da orientação, do redimensionamento e das restrições de 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 a bibliotecas nativas. Todos os arquivos nativos carregados usando System.load() precisam ser marcados como somente leitura. Caso contrário, o sistema vai gerar UnsatisfiedLinkError.
• Ativar a CT por padrãoa transparência de certificado (CT, na sigla em inglês) 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. Mude para o uso de seletores de preservação de privacidade, se possível, e use a nova permissão ACCESS_LOCAL_NETWORK para acesso amplo e persistente.
• Reforç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 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 limitação do targetSDK durante a aplicação do FGS em uso e a isenção do áudio de alarme. Detalhes completos disponíveis nas orientações atualizadas.

Limites de memória do app

O Android está introduzindo limites de memória do app 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 linhas de base do sistema, segmentando vazamentos de memória extremos e outros outliers antes que eles acionem instabilidade em todo o sistema, resultando em renderização lenta da interface, consumo elevado da bateria e encerramento de apps. Embora prevejamos um impacto mínimo na grande maioria das sessões de apps, recomendamos as práticas recomendadas de memória a seguir, incluindo o estabelecimento de uma linha de base para a memória.

Na implementação atual, getDescription em ApplicationExitInfo vai conter a string "MemoryLimiter" se o app tiver sido afetado. Você também pode usar criação de perfil baseada em acionadores com TRIGGER_TYPE_ANOMALY para receber despejos de heap 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 na IDE e totalmente integrada ao código-fonte.

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

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 com uso intenso de 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 acionador TRIGGER_TYPE_ANOMALY para detectar problemas de desempenho do sistema, como chamadas de binder excessivas e uso excessivo de memória. Quando um app viola os limites de memória definidos pelo SO, o acionador 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 de binder excessivo, o acionador de anomalia fornece um perfil de amostragem de pilha em transações de binder.

Esse callback de API ocorre antes de qualquer aplicação imposta pelo sistema. Por exemplo, ele pode ajudar os desenvolvedores a coletar dados de depuração antes que o app seja encerrado pelo sistema devido ao excesso de limites de memória. Para entender como usar o acionador, consulte nossa documentação sobre criação de perfil baseada em acionadores.

    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, totalmente no hardware seguro do dispositivo. O Android Keystore expõe as variantes de algoritmo ML-DSA-65 e ML-DSA-87 pelas APIs Java Cryptographic Architecture padrão: KeyPairGenerator, KeyFactory e Signature. Para mais detalhes, consulte nossa documentação do desenvolvedor.

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 inscrever qualquer dispositivo Pixel compatível para receber essa e futuras atualizações do Android Beta over the air. 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ê estiver no 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 no nosso trabalho na versão final.

Para ter a melhor experiência de desenvolvimento com o Android 17, recomendamos que você use a versão de pré-lançamento mais recente do Android Studio (Panda). Depois de configurar, confira algumas coisas que você precisa fazer:

• Compile com o novo SDK, teste em ambientes de CI e relate problemas no nosso rastreador na página de feedback.
• Teste seu app atual para verificar a compatibilidade, saiba se ele é afetado por mudanças no Android 17 e instale o app em um dispositivo ou emulador com o Android 17 e teste-o extensivamente.

Vamos atualizar as imagens do sistema de pré-lançamento/Beta e o SDK regularmente durante todo o ciclo de lançamento do Android 17. Depois de instalar um build Beta, você vai receber automaticamente atualizações futuras over the air para todas as versões de pré-lançamento e 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 pioneiro no canal Canary ou um desenvolvedor de apps que testa na versão Beta 4, considere participar das nossas comunidades e enviar feedback. Estamos ouvindo.