Hoje, estamos lançando a primeira versão Beta do Android 17, continuando nosso trabalho para criar uma plataforma que prioriza privacidade, segurança e desempenho refinado. Esse build continua nosso trabalho para apps Android mais adaptáveis, introduz melhorias significativas nos recursos de câmera e mídia, novas ferramentas para otimizar a conectividade e perfis expandidos para dispositivos complementares. Essa versão também destaca uma mudança fundamental na forma como estamos lançando novas versões para a comunidade de desenvolvedores, do modelo tradicional de prévia para desenvolvedores ao programa Android Canary

Além da prévia para desenvolvedores

O Android substituiu a tradicional "prévia para desenvolvedores" por um canal Canary contínuo. Esse novo modelo "sempre ativo" oferece três benefícios principais:

• Acesso mais rápido:os recursos e as APIs chegam ao Canary assim que passam nos testes internos, em vez de esperar por uma versão trimestral.
• Melhor estabilidade:o "teste de batalha" antecipado no Canary resulta em uma experiência Beta mais refinada com novas APIs e mudanças de comportamento que estão mais próximas da versão final.
• Testes mais fáceis:o Canary oferece suporte a atualizações OTA (sem mais atualizações manuais) e, como um canal de atualização separado, se integra mais facilmente aos fluxos de trabalho de CI e oferece a janela mais antiga para dar feedback imediato sobre possíveis mudanças futuras.

Programação do Android 17

Vamos passar rapidamente dessa versão Beta para nosso marco de estabilidade da plataforma, previsto para março. Nesse marco, vamos oferecer APIs finais do SDK/NDK e comportamentos relacionados ao app em grande parte finais. A partir desse momento, você terá vários meses antes da versão final para concluir os testes.

Um ano de lançamentos

Planejamos que o Android 17 continue recebendo atualizações em uma série de lançamentos trimestrais. A próxima versão no segundo trimestre é a única em que apresentamos mudanças de comportamento planejadas para o app. Planejamos ter uma versão secundária do SDK no quarto trimestre com APIs e recursos adicionais.

Restrições de orientação e redimensionamento

Com o lançamento da versão Beta do Android 17, estamos passando para a próxima fase do nosso roteiro adaptável: o Android 17 (nível 37 da API) remove a opção de desativação do desenvolvedor para restrições de orientação e redimensionamento em dispositivos de tela grande (sw > 600 dp).

Quando o app é direcionado ao SDK 37, ele precisa estar pronto para se adaptar. Os usuários esperam que os apps funcionem em todos os lugares, seja em multitarefa em um tablet, desdobrando um dispositivo ou usando um modo janela para computador, e esperam que a interface preencha o espaço e respeite a postura do dispositivo.

Principais mudanças para o SDK 37

Os apps direcionados ao Android 17 precisam garantir a compatibilidade com a descontinuação dos atributos do manifesto e das APIs de execução introduzidas no Android 16. Ao serem executados em uma tela grande (dimensão menor ≥ 600 dp), os seguintes atributos e APIs serão ignorados:

Isenções e controle do usuário

Essas mudanças são específicas para telas grandes. Elas não se aplicam a telas menores que sw600dp (incluindo smartphones tradicionais). Além disso, os apps categorizados como jogos (com base na flag android:appCategory) estão isentos dessas restrições.

Também é importante observar que os usuários permanecem no controle. Eles podem ativar/desativar explicitamente o comportamento padrão de um app nas configurações de proporção do sistema.

Atualizações nas mudanças de configuração

Para melhorar a compatibilidade do app e ajudar a minimizar a reprodução de vídeo interrompida, a entrada descartada e outros tipos de perda de estado disruptiva, estamos atualizando o comportamento padrão para a recriação de atividades. A partir do Android 17, o sistema não vai mais reiniciar as atividades por padrão para mudanças de configuração específicas que normalmente não exigem uma recriação da interface, incluindo CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_UI_MODE (quando apenas UI_MODE_TYPE_DESK é alterado), CONFIG_TOUCHSCREEN, e CONFIG_COLOR_MODE. Em vez disso, as atividades em execução vão simplesmente receber essas atualizações por onConfigurationChanged.Se o aplicativo depende de uma reinicialização completa para recarregar recursos para essas mudanças, agora é necessário ativar explicitamente o novo atributo de manifesto android:recreateOnConfigChanges, que permite especificar quais mudanças de configuração devem acionar um ciclo de vida da atividade completo (de parar, destroy e criar novamente), juntamente com as constantes relacionadas mcc, mnc, e as novas keyboard, keyboardHidden, navigation, touchscreen e colorMode.

Preparar o app

Lançamos ferramentas e documentação para facilitar o processo. Nosso post do blog focado tem mais orientações, com estratégias para resolver problemas comuns. Os apps precisam oferecer suporte a layouts de paisagem e retrato para tamanhos de janela em toda a gama de proporções, já que restringir a orientação ou a proporção não será mais uma opção. Recomendamos testar o app usando a versão Beta 1 do Android 17 com emuladores do Pixel Tablet ou Pixel Fold (configurados para targetSdkPreview = "CinnamonBun") ou usando o framework de compatibilidade de apps para ativar UNIVERSAL_RESIZABLE_BY_DEFAULT em dispositivos Android 16.

Desempenho

MessageQueue sem bloqueio

No Android 17, os apps direcionados ao SDK 37 ou mais recente vão receber uma nova implementação do android.os.MessageQueue em que a implementação é sem bloqueio. A nova implementação melhora o desempenho e reduz os frames perdidos, mas pode interromper clientes que refletem em MessageQueue campos e métodos particulares.

Coleta de lixo geracional

O Android 17 introduz a coleta de lixo geracional no coletor Concurrent Mark-Compact do ART. Essa otimização introduz coleções de geração jovem mais frequentes e menos intensivas em recursos, além de coleções de heap completo, com o objetivo de reduzir o custo geral de CPU e a duração da coleta de lixo. As melhorias do ART também estão disponíveis para mais de um bilhão de dispositivos com o Android 12 (nível 31 da API) e versões mais recentes pelas atualizações do sistema do Google Play.

Campos finais estáticos agora são realmente finais

A partir do Android 17, os apps direcionados ao Android 17 ou mais recente não poderão modificar campos "finais estáticos", permitindo que o ambiente de execução aplique otimizações de desempenho de forma mais agressiva. Uma tentativa de fazer isso por reflexão (e reflexão profunda) sempre levará ao lançamento de IllegalAccessException. A modificação deles pela família de métodos SetStatic<Type>Field do JNI vai causar falha imediata no aplicativo.

Restrições de visualização de notificações personalizadas

Para reduzir o uso de memória, estamos restringindo o tamanho das visualizações de notificações personalizadas. Essa atualização fecha uma brecha que permite que os apps ignorem os limites atuais usando URIs. Esse comportamento é controlado pela versão do SDK de destino e entra em vigor para apps direcionados à API 37 e mais recentes.

Novos acionadores do ProfilingManager para depuração de desempenho

Introduzimos vários novos acionadores do sistema no ProfilingManager para ajudar você a coletar dados detalhados para depurar problemas de desempenho. Esses acionadores são TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM e TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE.

Para entender como configurar os novos acionadores do sistema, consulte a documentação sobre criação de perfil baseada em acionadores e recuperação e análise de dados de criação de perfil.

Mídia e câmera

O Android 17 oferece ferramentas de nível profissional para apps de mídia e câmera, com recursos como transições perfeitas e volume padronizado.

Atualizações dinâmicas da sessão da câmera

Introduzimos updateOutputConfigurations() no CameraCaptureSession. Isso permite anexar e desanexar dinamicamente superfícies de saída sem a necessidade de reconfigurar toda a sessão de captura da câmera. Essa mudança permite transições perfeitas entre casos de uso e modos de câmera (como tirar fotos em comparação com gravar vídeos) sem o custo de memória e a complexidade do código de configurar e manter todas as superfícies de saída da câmera que o app pode precisar durante a inicialização da câmera. Isso ajuda a eliminar falhas ou congelamentos visíveis ao usuário durante a operação.

  fun updateCameraSession(session: CameraCaptureSession, newOutputConfigs:  List<OutputConfiguration>)) {
    // Dynamically update the session without closing and reopening
    try {
        
        // Update the output configurations
        session.updateOutputConfigurations(newOutputConfigs)
    } catch (e: CameraAccessException) {
        // Handle error
    }
}

Metadados de dispositivos lógicos de várias câmeras

Ao trabalhar com câmeras lógicas que combinam vários sensores de câmera física, agora é possível solicitar metadados adicionais de todas as câmeras físicas ativas envolvidas em uma captura, não apenas a principal. Anteriormente, era necessário implementar soluções alternativas, às vezes alocando streams físicos desnecessários, para receber metadados de câmeras ativas secundárias (por exemplo, durante uma troca de lente para zoom em que uma câmera seguidora está ativa). Esse recurso introduz uma nova chave, LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS, em CaptureRequest e CaptureResult. Ao definir essa chave como ON no CaptureRequest, o TotalCaptureResult vai incluir metadados dessas câmeras físicas ativas adicionais. É possível acessar esses metadados abrangentes usando TotalCaptureResult.getPhysicalCameraTotalResults() para receber informações mais detalhadas que podem permitir otimizar o uso de recursos nos aplicativos de câmera.

Suporte à codificação de vídeo versátil (VVC, na sigla em inglês)

O Android 17 adiciona suporte ao padrão Versatile Video Coding (VVC). Isso inclui definir o tipo MIME video/vvc em MediaFormat, adicionar novos perfis VVC em MediaCodecInfo e integrar o suporte ao MediaExtractor. Esse recurso será disponibilizado em dispositivos com suporte à decodificação de hardware e drivers capazes.

Qualidade constante para gravação de vídeo

Adicionamos setVideoEncodingQuality() ao MediaRecorder. Isso permite configurar um modo de qualidade constante (CQ) para codificadores de vídeo, oferecendo um controle mais refinado sobre a qualidade do vídeo além das configurações simples de taxa de bits.

Reforço da proteção de áudio em segundo plano

A partir do Android 17, o framework de áudio vai aplicar restrições às interações de áudio em segundo plano, incluindo reprodução de áudio, solicitações de foco de áudio e APIs de mudança de volume para garantir que essas mudanças sejam iniciadas intencionalmente pelo usuário. 

Se o app tentar chamar APIs de áudio enquanto o aplicativo não estiver em um ciclo de vida válido, as APIs de reprodução de áudio e mudança de volume vão falhar silenciosamente sem uma exceção gerada ou uma mensagem de falha fornecida. A API de seleção de áudio vai falhar com o código de resultado AUDIOFOCUS_REQUEST_FAILED.

Privacidade e segurança

Descontinuação do atributo de tráfego de texto não criptografado

O atributo android:usesCleartextTraffic foi descontinuado. Se o app for direcionado ao Android 17 ou mais recente e depender de usesCleartextTraffic="true" sem uma configuração de segurança de rede correspondente, ele será definido como padrão para não permitir tráfego de texto não criptografado. Recomendamos migrar para arquivos de configuração de segurança de rede para controle granular.

Criptografia híbrida HPKE

Estamos introduzindo uma interface de provedor de serviços (SPI) pública para uma implementação de criptografia híbrida HPKE, permitindo a comunicação segura usando uma combinação de chave pública e criptografia simétrica (AEAD).

Conectividade e telecomunicações

Histórico de chamadas VoIP aprimorado

Estamos introduzindo o gerenciamento de preferências do usuário para a integração do histórico de ligações VoIP do app. Isso inclui suporte a URIs de avatar de chamador e participante no discador do sistema, permitindo o controle granular do usuário sobre a privacidade do registro de chamadas e enriquecendo a exibição visual dos registros de chamadas VoIP integrados.

Alcance e proximidade de Wi-Fi

O alcance de Wi-Fi foi aprimorado com novos recursos de detecção de proximidade, oferecendo suporte a alcance contínuo e descoberta segura ponto a ponto. As atualizações no alcance do Wi-Fi Aware incluem novas APIs para identificadores de pares e armazenamento em cache de PMKID para alcance seguro de 11az.

Produtividade e ferramentas do desenvolvedor

Atualizações para apps de dispositivos complementares

Introduzimos dois novos perfis no CompanionDeviceManager para melhorar a distinção de dispositivos e o gerenciamento de permissões:

• Dispositivos médicos:esse perfil permite que aplicativos móveis de dispositivos médicos solicitem todas as permissões necessárias com um único toque, simplificando o processo de configuração.
• Trackers de condicionamento físico:o perfil DEVICE_PROFILE_FITNESS_TRACKER permite que apps complementares indiquem explicitamente que estão gerenciando um tracker de condicionamento físico. Isso garante experiências precisas do usuário com ícones distintos ao reutilizar as permissões de função de relógio atuais.

Além disso, o CompanionDeviceManager agora oferece uma caixa de diálogo unificada para associação de dispositivos e solicitações de permissão de acesso a dispositivos por perto. É possível aproveitar o novo método setExtraPermissions no AssociationRequest.Builder para agrupar solicitações de permissão de acesso a dispositivos por perto no fluxo de associação atual, reduzindo o número de caixas de diálogo apresentadas ao usuário.

Começar a usar o Android 17

Você pode registrar 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 1.

Se você tiver a versão Beta 26Q1 do Android e quiser usar a versão estável final do 26Q1 e sair da versão Beta, ignore a atualização over the air para a versão Beta 1 do 26Q2 e aguarde o lançamento do 26Q1.

Estamos buscando seu feedback. Portanto, informe problemas e envie 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 usar a versão de pré-lançamento 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 problemas no nosso 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 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 da versão Beta, você vai receber automaticamente atualizações 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

À medida que avançamos para a estabilidade da plataforma e a versão estável final do Android 17 ainda este ano, seu feedback continua sendo nosso recurso mais valioso. Seja você um usuário pioneiro no canal Canary ou um desenvolvedor de apps que testa na versão Beta 1, considere participar das nossas comunidades e enviar feedback. Estamos ouvindo.