Mudanças no Android: Edge-to-Edge e Nova Política de Orientação

Redação
há 2 dias
4 min de leitura

Por que o modelo mudou

Desde o Android 5 (Lollipop), o sistema operacional evoluiu de uma arquitetura em que o app declarava explicitamente cores e modos de barra do sistema para um modelo em que o SO gerencia automaticamente a aparência dessas regiões. A razão técnica central é o crescimento do ecossistema de form factors: dobráveis, tablets com proporções variadas, modos de janela dividida (split-screen) e floating window exigem que o conteúdo seja fluido o suficiente para ocupar qualquer área útil sem artefatos visuais.

O modelo edge-to-edge formaliza essa expectativa: o sistema declara que o conteúdo do app pode e deve se estender por toda a tela física, incluindo as regiões atrás da status bar e da navigation bar. O app passa a ser responsável por respeitar os insets (WindowInsets) que o sistema fornece, em vez de depender de APIs que fixavam cores ou dimensões de barra.

Mudanças introduzidas no Android 15

Edge-to-edge obrigatório para apps com targetSdkVersion ≥ 35

A partir do Android 15, apps com targetSdkVersion 35 passam a operar em modo edge-to-edge por padrão, sem necessidade de chamada explícita a WindowCompat.setDecorFitsSystemWindows(). O sistema injeta automaticamente o layout sob as barras do sistema.

Consequências diretas para apps que não trataram os insets corretamente:

Botões de ação ou campos de formulário posicionados na parte inferior da tela podem ficar sobrepostos pela navigation bar.
Conteúdo no topo pode colidir com a status bar em dispositivos sem notch.
ScrollViews e RecyclerViews podem ter clip incorreto, cortando o primeiro ou o último item.

Descontinuação de APIs de controle de barra

Diversas APIs históricas de controle de cor e transparência de barra foram marcadas como deprecated no Android 15. Entre elas:

Window.setStatusBarColor() e Window.setNavigationBarColor() — substituídas pelo controle via WindowInsetsController.
WindowManager.LayoutParams.FLAG_TRANSLUCENT_STATUS e FLAG_TRANSLUCENT_NAVIGATION — comportamento absorvido pelo modelo edge-to-edge.
Configurações de cutout mode via manifest attribute android:windowLayoutInDisplayCutoutMode com valores específicos agora ignorados em cenários de tela cheia.

No contexto de apps React Native / Expo, essas APIs aparecem tanto no código do próprio app quanto em dependências como react-native-screens, expo-navigation-bar e bibliotecas de navigation ou bottom sheet. Avisos no Play Console relativos a APIs descontinuadas podem, portanto, ter origem em pacotes de terceiros ainda não atualizados pelos seus mantenedores.

Nova política de orientação no Android 16 (Large Screen)

Esta é a mudança com maior impacto imediato para apps que não realizaram migração de layout.

O que o sistema passará a ignorar

O Google anunciou que, a partir do Android 16, em dispositivos classificados como large screen (tablets e dobráveis), o sistema poderá desconsiderar as seguintes declarações no AndroidManifest.xml:

android:screenOrientation="portrait" (e variantes como sensorPortrait, reversePortrait)
android:resizeableActivity="false"
Combinações de minAspectRatio e maxAspectRatio que restringem a proporção da janela.

O sistema pode, a seu critério, permitir rotação e redimensionamento de janela independentemente do que o manifesto declarar. O bloqueio de orientação via código em runtime (setRequestedOrientation()) continua funcionando em telefones convencionais, mas não há garantia de que esse comportamento seja respeitado em large screens.

Impacto esperado para layouts não responsivos

Apps com layout desenvolvido exclusivamente para retrato em tela de telefone podem apresentar:

Espaços vazios laterais (letterboxing) quando a janela for expandida horizontalmente.
Elementos de UI com posição absoluta que saem da área visível ou ficam desalinhados.
Áreas de toque que não correspondem ao elemento visível após o redimensionamento.
Scrolls e listas com largura máxima fixa que geram layouts de coluna estreita em telas largas.
Mapas, WebViews e players de vídeo com proporções quebradas.

Nota: Aplicações que já sofriam com layout rígido em celulares de tela maior (6,5”+) terão os problemas amplificados em tablets e dobráveis. A base de usuários desses dispositivos cresceu significativamente desde 2023 e continuará crescendo com os lançamentos de 2025–26.

Quando a política entra em vigor

A mudança é progressiva: dispositivos com Android 16 já podem aplicar o comportamento assim que o update for distribuído para o hardware de destino. Não há período de graça atrelado ao targetSdkVersion neste caso o sistema operacional da página aplicará a política independentemente da versão alvo declarada no app.

Recomendações técnicas

Ações imediatas

Auditar o uso de WindowInsets no app e substituir padding fixo em botões e barras inferiores por insets dinâmicos (WindowInsetsCompat).
Remover ou condicionalmente desabilitar chamadas a setStatusBarColor(), setNavigationBarColor() e flags deprecated, substituindo por WindowInsetsController.
Atualizar dependências de navegação, bottom sheet e componentes de sistema para versões compatíveis com edge-to-edge (verificar changelogs de react-native-screens, expo-navigation-bar e similares).

Layout responsivo

Testar os fluxos críticos (login, checkout, formulários, mapas, WebViews) no emulador Android com perfis de tablet (ex: Pixel Tablet, Generic Large Screen) e no modo de janela redimensionável.
Substituir dimensões fixas em px ou dp por constraints flexíveis (ConstraintLayout, peso, proporções relativas à largura disponível).
Considerar layouts adaptativos com WindowSizeClass para distinguir compact, medium e expanded width e ajustar a composição de tela conforme o espaço disponível.
Para React Native / Expo: utilizar SafeAreaProvider com useSafeAreaInsets() em vez de padding codificado, e testar com o emulador em modo landscape e split-screen.