Com o lançamento do Android 16 em 2025, compartilhamos nossa visão de um ecossistema de dispositivos em que os apps se adaptam perfeitamente a qualquer tela, seja de smartphone, dobrável, tablet, computador, tela de carro ou XR. Os usuários esperam que os apps funcionem em todos os lugares. Seja fazendo várias tarefas em um tablet, desdobrando um dispositivo para ler confortavelmente ou executando apps em um modo janela para computador, os usuários esperam que a interface preencha o espaço de exibição disponível e se adapte à postura do dispositivo.

Introduzimos mudanças significativas nas APIs de orientação e redimensionamento para facilitar o comportamento adaptável, oferecendo uma opção de desativação temporária para ajudar na transição. Já vimos muitos desenvolvedores se adaptarem com sucesso a essa transição ao segmentar o nível 36 da API.

Agora, 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). Ao segmentar o nível desejado da API 37, seu app precisa ser capaz de se adaptar a vários tamanhos de tela.

As mudanças de comportamento garantem que o ecossistema Android ofereça uma experiência consistente e de alta qualidade em todos os formatos de dispositivos.

O que está mudando no Android 17

Os apps destinados ao Android 17 precisam garantir a compatibilidade com a descontinuação dos atributos de manifesto e das APIs de execução introduzidas no Android 16. Entendemos que, para alguns apps, essa pode ser uma grande transição. Por isso, incluímos práticas recomendadas e ferramentas para ajudar a evitar problemas comuns mais adiante nesta postagem do blog.

Nenhuma mudança nova foi introduzida desde o Android 16, mas a opção de desativação do desenvolvedor não está mais disponível. Lembrete: quando o app é executado em uma tela grande, em que tela grande significa que a dimensão menor da tela é maior ou igual a 600 dp, os seguintes atributos de manifesto e APIs são ignorados:

Observação : como mencionado anteriormente no Android 16, essas mudanças não se aplicam a telas menores que sw 600 dp ou apps categorizados como jogos com base na flag android:appCategory. 

Além disso, os usuários mantêm o controle. Nas configurações de proporção, os usuários podem ativar explicitamente o comportamento solicitado do app.

Preparar seu app

Os apps precisam oferecer suporte a layouts de paisagem e retrato para tamanhos de tela em toda a variedade de proporções em que os usuários podem escolher usar apps, incluindo janelas redimensionáveis, já que não haverá mais como restringir a proporção e a orientação para retrato ou paisagem.

Testar seu app

A primeira etapa é testar seu app com essas mudanças para garantir que ele funcione bem em todos os tamanhos de tela.

Use a versão Beta 1 do Android 17 com os emuladores da série Pixel Tablet e Pixel Fold no Android Studio e defina targetSdkPreview = “CinnamonBun”. Como alternativa, você pode usar o framework de compatibilidade ativando a UNIVERSAL_RESIZABLE_BY_DEFAULT flag se o app ainda não for destinado ao nível desejado da API.

Temos outras ferramentas para garantir que seus layouts se adaptem corretamente. Você pode auditar automaticamente sua interface e receber sugestões para torná-la mais adaptável com Compose UI Check e simular características de exibição específicas nos testes usando DeviceConfigurationOverride.

Para apps que historicamente restringiram a orientação e a proporção, geralmente vemos problemas com visualizações de câmera distorcidas ou mal orientadas, layouts esticados, botões inacessíveis ou perda do estado do usuário ao processar mudanças de configuração. 

Vamos conferir algumas estratégias para resolver esses problemas comuns.

Garantir a compatibilidade da câmera

Um problema comum em dobráveis de paisagem ou para cálculos de proporção em cenários como várias janelas, modo janela para computador ou telas conectadas é quando a visualização da câmera aparece esticada, girada ou cortada.

Verifique se a visualização da câmera não está esticada ou girada.

Esse problema geralmente ocorre em dispositivos de tela grande e dobráveis porque os apps presumem relações fixas entre os recursos da câmera (como proporção e orientação do sensor) e os recursos do dispositivo (como orientação e orientação natural).

Para garantir que a visualização da câmera se adapte corretamente a qualquer tamanho ou orientação da janela, considere estas quatro soluções:

Solução 1: Jetpack CameraX (preferencial) 

A solução mais simples e robusta é usar a biblioteca Jetpack CameraX. O elemento da interface PreviewView foi projetado para processar todas as complexidades de visualização automaticamente:

• PreviewView se ajusta corretamente à orientação do sensor, à rotação do dispositivo e ao dimensionamento
• O PreviewView mantém a proporção da imagem da câmera, geralmente centralizando e cortando (FILL_CENTER)
• Você pode definir o tipo de escala como FIT_CENTER para aplicar o efeito letterbox na visualização, se necessário

Para mais informações, consulte Implementar uma visualização na documentação do CameraX.

Solução 2: CameraViewfinder 

Se você estiver usando uma base de código Camera2 atual, a biblioteca CameraViewfinder (compatível com versões anteriores até o nível 21 da API) será outra solução moderna. Ela simplifica a exibição da transmissão da câmera usando uma TextureView ou SurfaceView e aplicando todas as transformações necessárias (proporção, escala e rotação) para você.

Para mais informações, consulte a postagem do blog Apresentação do visor da câmera e o guia do desenvolvedor Visualização da câmera.

Solução 3: implementação manual do Camera2 

Se você não puder usar o CameraX ou o CameraViewfinder, calcule manualmente a orientação e a proporção e garanta que os cálculos sejam atualizados em cada mudança de configuração:

• Receba a orientação do sensor da câmera (por exemplo, 0, 90, 180, 270 graus) de CameraCharacteristics
• Receba a rotação atual da tela do dispositivo (por exemplo, 0, 90, 180, 270 graus)
• Use os valores de orientação do sensor da câmera e de rotação da tela para determinar as transformações necessárias para sua SurfaceView ou TextureView
• Verifique se a proporção da saída Surface corresponde à proporção da visualização da câmera para evitar distorção

Importante:observe que o app de câmera pode estar sendo executado em uma parte da tela, no modo de várias janelas ou no modo janela para computador ou em uma tela conectada. Por esse motivo, o tamanho da tela não deve ser usado para determinar as dimensões do visor da câmera. Use métricas de janela. Caso contrário, você corre o risco de ter uma visualização da câmera esticada.

Para mais informações, consulte o guia do desenvolvedor Visualização da câmera e o vídeo Seu app de câmera em diferentes formatos.

Solução 4: realizar ações básicas da câmera usando uma intent 

Se você não precisar de muitos recursos da câmera, uma solução simples e direta é realizar ações básicas, como capturar uma foto ou um vídeo usando o app de câmera padrão do dispositivo. Nesse caso, você pode simplesmente usar uma Intent em vez de fazer a integração com uma biblioteca de câmera, para facilitar a manutenção e a adaptabilidade. 

Para mais informações, consulte Intents de câmera.

Evitar interface esticada ou botões inacessíveis

Se o app pressupõe uma orientação específica do dispositivo ou uma proporção de tela, ele poderá ter problemas quando for usado em várias orientações ou tamanhos de janela.

Verifique se os botões, campos de texto e outros elementos não estão esticados em telas grandes.

Você pode ter definido botões, campos de texto e cards como fillMaxWidth ou match_parent. Em um smartphone, isso fica ótimo. No entanto, em um tablet ou dobrável na orientação paisagem, os elementos da interface são esticados por toda a tela grande. No Jetpack Compose, você pode usar o modificador widthIn para definir uma largura máxima para os componentes e evitar conteúdo esticado:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

Se um usuário abrir seu app na orientação paisagem em um dobrável ou tablet, os botões de ação, como Salvar ou Fazer login , na parte de baixo da tela poderão ser renderizados fora da tela. Se o contêiner não for rolável, o usuário poderá ser impedido de continuar. No Jetpack Compose, você pode adicionar um modificador verticalScroll ao componente:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

Ao combinar restrições de largura máxima com rolagem vertical, você garante que o app permaneça funcional e utilizável, independentemente da largura ou do tamanho da janela do app.

Consulte nosso guia sobre como criar layouts adaptáveis.

Preservar o estado com mudanças de configuração

A remoção das restrições de orientação e proporção significa que o tamanho da janela do app vai mudar com muito mais frequência. Os usuários podem girar o dispositivo, dobrá-lo/desdobrá-lo ou redimensionar o app dinamicamente nos modos de tela dividida ou de modo janela para computador.

Por padrão, essas mudanças de configuração destroem e recriam sua atividade. Se o app não gerenciar corretamente esse evento de ciclo de vida, os usuários terão uma experiência frustrante: as posições de rolagem serão redefinidas para a parte de cima, os formulários preenchidos parcialmente serão limpos e o histórico de navegação será perdido. Para garantir uma experiência adaptável perfeita, é fundamental que o app preserve o estado durante essas mudanças de configuração. Com o Jetpack Compose, você pode desativar a recriação e, em vez disso, permitir que as mudanças de tamanho da janela recomponham a interface para refletir a nova quantidade de espaço disponível.

Consulte nosso guia sobre como salvar o estado da interface.

Segmentação do nível 37 da API até agosto de 2027

Se o app tiver desativado essas mudanças ao segmentar o nível 36 da API, ele só será afetado pela remoção da desativação do Android 17 depois que ele segmentar o nível 37 da API. Para ajudar você a planejar com antecedência e fazer os ajustes necessários no app, confira a linha do tempo em que essas mudanças entrarão em vigor:

• Android 17: as mudanças descritas acima serão a experiência básica para dispositivos de tela grande (menor largura de tela > 600 dp) para apps destinados ao nível desejado da API 37. Os desenvolvedores não terão uma opção de desativação.

Os prazos para segmentar um nível específico da API são específicos da loja de apps. No Google Play, novos apps e atualizações precisarão segmentar o nível 37 da API, tornando esse comportamento obrigatório para distribuição em agosto de 2027.

Preparação para o Android 17

Consulte a página de mudanças do Android 17 para conferir todas as mudanças que afetam os apps no Android 17. Para testar seu app, faça o download da versão Beta 1 do Android 17 e atualize para targetSdkPreview = “CinnamonBun” ou use o framework de compatibilidade de apps para ativar mudanças específicas.

O futuro do Android é adaptável, e estamos aqui para ajudar você a chegar lá. Ao se preparar para o Android 17, recomendamos que você consulte nossos guias para criar layouts adaptáveis e nossas diretrizes de qualidade para telas grandes. Esses recursos foram projetados para ajudar você a lidar com vários formatos e tamanhos de janela com confiança.

Não espere. Comece a se preparar para o Android 17 hoje mesmo.