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 um smartphone, dobrável, tablet, computador, tela de carro ou XR. Os usuários esperam que os apps funcionem em qualquer lugar. Seja fazendo várias tarefas em um tablet, desdobrando um dispositivo para ler com conforto 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, além de oferecer uma opção temporária de desativação para ajudar na transição. Já vimos muitos desenvolvedores se adaptarem 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 adaptativo: 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, o 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 vai mudar no Android 17

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

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

Observação : conforme mencionado anteriormente com o 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.

Prepare seu app

Os apps precisam oferecer suporte a layouts paisagem e retrato para tamanhos de tela em toda a gama de proporções em que os usuários podem escolher usar apps, incluindo janelas redimensionáveis. Não será mais possível restringir a proporção e a orientação para retrato ou paisagem.

Testar seu app

A primeira etapa é testar o app com essas mudanças para garantir que ele funcione bem em vários tamanhos de tela.

Use o Android 17 Beta 1 com os emuladores das séries Pixel Tablet e Pixel Fold no Android Studio e defina o targetSdkPreview = “CinnamonBun”. Como alternativa, use o framework de compatibilidade de apps ativando a flag UNIVERSAL_RESIZABLE_BY_DEFAULT se o app ainda não tiver como destino o nível desejado da API 36.

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 o Compose UI Check e simular características específicas de exibição nos seus testes usando o DeviceConfigurationOverride.

Em apps que restringem a orientação e a proporção, é comum encontrar problemas com visualizações da 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 dispositivos dobráveis no modo 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 costuma acontecer em dispositivos de tela grande e dobráveis porque os apps presumem relações fixas entre recursos da câmera (como proporção e orientação do sensor) e recursos do dispositivo (como orientação do dispositivo e orientação natural).

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

Solução 1: Jetpack CameraX (preferencial) 

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

• PreviewView ajusta corretamente a orientação do sensor, a rotação do dispositivo e o dimensionamento
• A 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 adicionar barras pretas à visualização, se necessário.

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

Solução 2: CameraViewfinder 

Se você estiver usando uma base de código Camera2, a biblioteca CameraViewfinder (compatível com versões anteriores até o nível 21 da API) será outra solução moderna. Ele simplifica a exibição da transmissão da câmera usando um 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 não for possível 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.
• Acessar a rotação atual da tela do dispositivo (por exemplo, 0, 90, 180, 270 graus)
• Use a orientação do sensor da câmera e os valores de rotação da tela para determinar as transformações necessárias para seu SurfaceView ou TextureView.
• Verifique se a proporção da saída Surface corresponde à proporção da visualização da câmera para evitar distorções.

Importante: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 isso, o tamanho da tela não deve ser usado para determinar as dimensões do visor da câmera. Em vez disso, use métricas de janela. Caso contrário, a visualização da câmera pode ficar esticada.

Para mais informações, consulte o guia para desenvolvedores Prévia da câmera e o vídeo Seu app 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, basta usar um Intent em vez de integrar com uma biblioteca de câmera para facilitar a manutenção e a adaptabilidade. 

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

Evite interfaces esticadas ou botões inacessíveis

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

Verifique se 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 dispositivo dobrável no modo paisagem, os elementos da interface se estendem por toda a tela grande. No Jetpack Compose, use 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 dispositivo dobrável ou tablet, os botões de ação, como Salvar ou Fazer login, na parte de baixo da tela podem ser renderizados fora da tela. Se o contêiner não puder ser rolado, o usuário poderá ser impedido de continuar. No Jetpack Compose, você pode adicionar um modificador verticalScroll ao seu 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, independente da largura ou do comprimento da janela do app.

Consulte nosso guia sobre como criar layouts adaptáveis.

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

Remover as 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, dobrar/desdobrar ou redimensionar o app dinamicamente nos modos de tela dividida ou 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 o topo, os formulários preenchidos pela metade serão apagados e o histórico de navegação será perdido. Para garantir uma experiência adaptativa perfeita, é fundamental que o app preserve o estado durante essas mudanças de configuração. Com o Jetpack Compose, é possível desativar a recriação e permitir que as mudanças no 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 recusado essas mudanças ao ser destinado ao nível 36 da API, ele só será afetado pela remoção da recusa do Android 17 depois que for destinado ao nível 37 da API. Para ajudar você a se planejar e fazer os ajustes necessários no seu app, confira o cronograma de quando essas mudanças vão entrar 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 direcionados ao nível 37 da API. Os desenvolvedores não terão a opção de desativar.

Os prazos para segmentar um nível da API específico variam de acordo com a loja de apps. Para o Google Play, os novos apps e atualizações vão precisar ter como nível desejado da API o 37, 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 do Android 17 Beta 1 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á. Enquanto você se prepara para o Android 17, recomendamos que consulte nossos guias para criar layouts adaptáveis e nossas diretrizes de qualidade para telas grandes. Esses recursos foram criados 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!