Android 16 em 2026: Novas APIs, Desktop Mode e Perguntas de Entrevista

O Android 16 (API level 36, codinome "Baklava") representa uma das atualizações de plataforma mais impactantes desde a reformulação Material You do Android 12. Lançada como versão estável em 10 de junho de 2025, a versão roda em mais de 21% dos dispositivos ativos em março de 2026, tornando-se a versão mais amplamente implantada do Android. Para desenvolvedores Android que se preparam para entrevistas em 2026, o domínio dessas mudanças de API é indispensável.

Modelo de Release SDK do Android 16: Estratégia Major-Minor

O Android 16 introduz uma estrutura de release dual que transforma o planejamento de adoção de funcionalidades. O SDK major foi entregue com a Beta 3 em março de 2025, definindo as mudanças de comportamento e APIs principais. Um segundo SDK minor seguiu em 2 de dezembro de 2025, adicionando novas APIs sem alterar o comportamento da plataforma.

Essa separação é fundamental em entrevistas: o release major é onde residem as mudanças que quebram compatibilidade (edge-to-edge, enforcement de orientação), enquanto o release minor fornece novas capacidades (bibliotecas Jetpack adicionais, APIs relacionadas a IA) sem impacto no comportamento existente das aplicações. O Google projetou esse modelo para acelerar a entrega de APIs enquanto oferece às equipes enterprise um alvo anual estável e previsível para conformidade.

Uma pergunta comum em entrevistas aborda a distinção entre targetSdkVersion e compileSdkVersion no contexto desse modelo dual. A resposta: targetSdkVersion = 36 ativa todas as mudanças de comportamento do release major. O SDK minor é puramente aditivo — não requer nenhum opt-in nem atualização de target.

Enforcement Edge-to-Edge no API 36

Aplicações que targetam Android 16 não podem mais desativar layouts edge-to-edge. O sistema ignora chamadas a setDecorFitsSystemWindows(true) e flags de visibilidade SystemUI legados. Toda aplicação precisa tratar corretamente os window insets ou corre o risco de ter elementos de UI ocultos atrás da status bar e da navigation bar.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // enableEdgeToEdge() is now the default on API 36+
        // No opt-out available
        enableEdgeToEdge()
        setContent {
            Scaffold(
                modifier = Modifier.fillMaxSize()
            ) { innerPadding ->
                // innerPadding accounts for system bars
                MainContent(
                    modifier = Modifier.padding(innerPadding)
                )
            }
        }
    }
}

O componente Scaffold do Jetpack Compose gerencia insets automaticamente através do innerPadding. Para apps baseados em Views, ViewCompat.setOnApplyWindowInsetsListener continua sendo a abordagem recomendada. O detalhe crítico: WindowInsetsCompat.Type.systemBars() precisa ser consumido explicitamente, caso contrário o sistema aplica um padding padrão que pode não corresponder ao design da aplicação.

Recrutadores frequentemente perguntam o que acontece com apps que dependiam de android:fitsSystemWindows="true" em layouts XML. No API 36, esse atributo ainda funciona mas aplica padding apenas para barras do sistema — ele não impede mais que a aplicação desenhe em edge-to-edge.

Apps Adaptativas e Mudanças de Orientação em Telas Grandes

O Android 16 ignora android:screenOrientation e android:resizeableActivity="false" para aplicações que não são jogos em telas com smallestWidth >= 600dp. Tablets, foldables e monitores externos conectados via Desktop Mode são todos afetados. Isso encerra anos de layouts de celular com letterbox em telas grandes.

// Responsive layout using WindowSizeClass
@Composable
fun AdaptiveLayout() {
    val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
    when {
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.EXPANDED -> {
            // Two-pane layout for tablets/desktop
            TwoPaneLayout()
        }
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.MEDIUM -> {
            // Adapted layout for foldables
            MediumLayout()
        }
        else -> {
            // Phone layout
            CompactLayout()
        }
    }
}

A biblioteca Jetpack WindowManager fornece WindowSizeClass para design responsivo. Uma propriedade de opt-out estava disponível para apps que targetam especificamente API 36, mas o Android 17 (previsto para Q2 2026) remove essa opção de desativação por completo.

Recrutadores frequentemente formulam essa questão assim: "Como seria a migração de uma aplicação travada em orientação portrait para suportar telas grandes?" A resposta envolve substituir a orientação fixa por layouts responsivos, testar mudanças de configuração (especialmente onConfigurationChanged), e verificar que o estado salvo sobrevive às transições de tamanho de tela.

Desktop Mode e Telas Conectadas

O Desktop Mode foi lançado como funcionalidade GA no Android 16 QPR3 (Pixel Drop de março 2026), com suporte para Pixel 8+ e dispositivos Samsung Galaxy S26/Fold7/Flip7. Conectar um celular a um monitor externo via USB-C inicia uma sessão desktop independente com barra de tarefas, janelas redimensionáveis, múltiplos desktops virtuais e suporte completo a teclado/mouse.

fun launchOnExternalDisplay(context: Context) {
    val displayManager = context.getSystemService(
        Context.DISPLAY_SERVICE
    ) as DisplayManager
    // Find external displays
    val externalDisplays = displayManager.displays.filter {
        it.displayId != Display.DEFAULT_DISPLAY
    }
    if (externalDisplays.isNotEmpty()) {
        val options = ActivityOptions.makeBasic().apply {
            launchDisplayId = externalDisplays.first().displayId
        }
        context.startActivity(
            Intent(context, DesktopActivity::class.java),
            options.toBundle()
        )
    }
}

O celular e a tela externa operam independentemente — as aplicações são específicas do display em que executam. Google e Samsung colaboraram na experiência de janelas desktop para reduzir a fragmentação no ecossistema. O Samsung DeX integra as mesmas APIs de plataforma, criando um alvo de desenvolvimento unificado.

Considerações-chave para o Desktop Mode:

• As métricas de janela mudam dinamicamente. Nunca fazer cache de objetos Display. Consultar WindowMetricsCalculator ou LocalConfiguration do Compose a cada mudança de configuração.
• Suporte a teclado e mouse. Periféricos externos são a norma em sessões desktop. Tratar o dispatch de KeyEvent e os estados hover do ponteiro.
• Suporte multi-instância. Usuários desktop esperam múltiplas janelas do mesmo aplicativo. Declarar android:documentLaunchMode="intoExisting" ou tratar FLAG_ACTIVITY_NEW_DOCUMENT apropriadamente.

Notificações ProgressStyle e Atualizações em Tempo Real

O Android 16 introduz Notification.ProgressStyle, um novo template de notificação para jornadas de usuário centradas em progresso como rastreamento de viagens, atualizações de entregas e navegação. Isso substitui layouts de notificação personalizados ad hoc por um formato padronizado e promovido pelo sistema.

fun buildDeliveryNotification(
    context: Context,
    orderId: String,
    progress: Float,  // 0.0 to 1.0
    currentStep: String
): Notification {
    val style = Notification.ProgressStyle()
        .setStyledByProgress(true)
        .setProgress(progress)
        .setProgressTrackerIcon(
            Icon.createWithResource(context, R.drawable.ic_delivery_truck)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_preparing)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_in_transit)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.34f)
                .setColor(context, R.color.segment_delivered)
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.0f)
                .setLabel("Order placed")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.33f)
                .setLabel("Preparing")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.66f)
                .setLabel("In transit")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(1.0f)
                .setLabel("Delivered")
        )

    return Notification.Builder(context, DELIVERY_CHANNEL_ID)
        .setSmallIcon(R.drawable.ic_notification)
        .setContentTitle("Order #$orderId")
        .setContentText(currentStep)
        .setStyle(style)
        .setOngoing(true)
        .build()
}

ProgressStyle suporta segmentos (seções coloridas da barra de progresso), pontos (marcos rotulados) e um ícone de rastreamento que se move ao longo da barra. Configurar setStyledByProgress(true) permite ao sistema colorir os segmentos com base no avanço. Para a preparação de entrevistas sobre notificações Android, entender quando usar ProgressStyle versus uma notificação setProgress() padrão é essencial: ProgressStyle é para jornadas multi-etapa com marcos distintos, enquanto setProgress() continua apropriado para operações de tarefa única como downloads de arquivos.

Navegação Preditiva com OnBackInvokedCallback

O Android 16 conclui a migração plurianual de onBackPressed() para a API OnBackInvokedCallback. O sistema agora exibe uma animação de "peek" da tela de destino durante o gesto de voltar, permitindo que usuários confirmem ou cancelem. Aplicações que ainda sobrescrevem onBackPressed() sem registrar um callback quebram essa animação.

class DetailActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        if (Build.VERSION.SDK_INT >= 36) {
            onBackInvokedDispatcher.registerOnBackInvokedCallback(
                OnBackInvokedDispatcher
                    .PRIORITY_SYSTEM_NAVIGATION_OBSERVER
            ) {
                // Observe back navigation without intercepting
                // Log analytics or trigger save-draft logic
                analyticsTracker.logBackNavigation(
                    screen = "detail"
                )
            }
        }
    }
}

A nova prioridade PRIORITY_SYSTEM_NAVIGATION_OBSERVER permite que aplicações observem eventos de retorno sem bloquear a animação do sistema. O Android 16 também adiciona finishAndRemoveTaskCallback e moveTaskToBackCallback para comportamentos personalizados de back-stack que ainda se integram com a animação preditiva.

A navegação preditiva também funciona na navegação de 3 botões no Android 16: manter pressionado o botão de voltar inicia a mesma animação de preview que a navegação por gestos. Esse é um tema frequente em entrevistas — candidatos que mencionam apenas a navegação por gestos perdem metade da resposta.

Cooldown de Notificações e Agrupamento Obrigatório

Duas mudanças adicionais de notificação afetam todas as aplicações Android. O cooldown de notificação reduz o volume de alertas para notificações rápidas da mesma aplicação, diminuindo gradualmente o nível de som ao longo de aproximadamente 60 segundos antes de reiniciar. Essa funcionalidade é habilitada por padrão e não pode ser sobrescrita pelos desenvolvedores.

O agrupamento obrigatório de notificações significa que o sistema agora agrupa notificações automaticamente independentemente de a aplicação usar setGroup(). Aplicações que dependiam da proeminência individual das notificações para engajamento precisarão repensar sua estratégia de notificações.

Para a preparação de entrevistas, essas mudanças combinam bem com perguntas sobre coroutines Kotlin e Flow, já que o batching e throttling eficiente de notificações frequentemente envolve padrões de debouncing baseados em coroutines.

APIs Health Connect FHIR e RangingManager

O Android 16 expande o Health Connect com suporte de escrita FHIR (Fast Healthcare Interoperability Resources), permitindo que aplicações de saúde criem e armazenem registros médicos estruturados. A API RangingManager unifica a medição de distância/ângulo através de BLE channel sounding, BLE RSSI, Ultra-Wideband e Wi-Fi RTT — consolidando o que anteriormente requeria quatro superfícies de API separadas.

O seletor de fotos ganha APIs de personalização mais profundas, permitindo que desenvolvedores controlem a aparência do seletor enquanto mantêm o mesmo modelo de segurança sandboxed. A busca em provedores de mídia na nuvem foi adicionada na Developer Preview 2.

Essas APIs têm menos probabilidade de aparecer em entrevistas Android gerais, mas são críticas para posições especializadas em saúde, IoT ou aplicações de mídia.

Perguntas e Respostas de Entrevista Android 16

P: Quais são as mudanças de comportamento obrigatórias ao targetar API 36? Três mudanças são impostas: renderização edge-to-edge (sem opt-out), restrições de orientação/redimensionamento ignoradas em telas >= 600dp, e navegação preditiva habilitada em todo o sistema. Apps precisam tratar WindowInsets corretamente, suportar layouts responsivos e migrar de onBackPressed() para OnBackInvokedCallback.

P: Como o Desktop Mode afeta a arquitetura de uma aplicação? O Desktop Mode cria uma sessão de display independente. Aplicações devem evitar fazer cache de objetos Display, suportar métricas de janela dinâmicas, tratar input de teclado/mouse e considerar cenários multi-instância. A API ActivityOptions.launchDisplayId permite targetar displays específicos programaticamente.

P: Quando ProgressStyle deve substituir setProgress()? ProgressStyle é para jornadas de usuário multi-etapa com marcos distintos (viagens compartilhadas, entregas, navegação). O setProgress() padrão continua apropriado para progresso de operação única (download de arquivo, upload). ProgressStyle ganha visibilidade promovida na gaveta de notificações.

P: O que é o modelo de release SDK major/minor do Android 16? O release major (março 2025) contém mudanças de comportamento e requer atualização de targetSdkVersion. O release minor (dezembro 2025) adiciona novas APIs sem mudanças de comportamento — nenhuma atualização de targetSdkVersion necessária. Isso desacopla estabilidade de inovação.

P: Como a navegação preditiva funciona com a navegação de 3 botões? No API 36+, manter pressionado o botão de voltar na navegação de 3 botões dispara a mesma animação preditiva que a navegação por gestos. Apps devem registrar um OnBackInvokedCallback com a prioridade apropriada. A prioridade PRIORITY_SYSTEM_NAVIGATION_OBSERVER permite observar sem interceptar.

Conclusão

• Edge-to-edge não é mais opcional no API 36. Auditar todas as telas para tratamento correto de WindowInsets, especialmente toolbars customizadas e bottom sheets.
• Substituir manifests com orientação fixa por layouts responsivos Jetpack Compose usando WindowSizeClass antes que o Android 17 remova a opção de desativação.
• O Desktop Mode está pronto para produção em Pixel 8+ e flagships Samsung. Testar aplicações com telas externas, input de teclado e cenários multi-instância.
• Migrar de onBackPressed() para OnBackInvokedCallback. Usar PRIORITY_SYSTEM_NAVIGATION_OBSERVER para tracking de analytics sem bloquear animações do sistema.
• Adotar Notification.ProgressStyle para qualquer jornada de usuário multi-etapa. O cooldown de notificações e o agrupamento obrigatório afetam todas as apps independentemente do SDK alvo.
• O modelo SDK major/minor significa que mudanças de comportamento chegam uma vez por ano. O SDK minor traz novas APIs sem risco de compatibilidade — adotá-las livremente.