Analisando o Tema Escuro Expandido

Há muita excitação em torno da personalização, acessibilidade e dar aos usuários mais controle sobre como as interfaces se adaptam às suas necessidades. Estou interessado no que acontece por baixo dos panos, e o modo escuro esconde uma quantidade surpreendente de engenharia.

Um tema escuro é mais do que a inversão binária de cores. As cores podem mudar, mas os sinais visuais e as relações que dão significado à interface ainda precisam ser mantidos. O modo escuro pode parecer uma preferência para algumas pessoas, mas pode importar muito mais para aqueles com baixa visão ou fotossensibilidade.

Há anos, se um aplicativo do seu telefone tinha modo escuro dependia de seus desenvolvedores terem construído um. O Android 10 (2019) introduziu Force Dark, permitindo que os desenvolvedores transferissem esse trabalho para o Android, que poderia gerar uma versão escura a partir do tema claro existente do aplicativo. Em seguida, em meados de 2025, um atualização do Android 16 introduziu Tema Escuro Expandido, colocando essa escolha nas mãos dos usuários. Os usuários podem agora pedir ao Android para escurecer aplicativos que ainda apareciam claros, mesmo quando esses aplicativos nunca forneceram seu próprio tema escuro. Essa mudança em direção a agência do usuário chamou minha atenção.

Usei Claude Science para investigar o Tema Escuro Expandido: criei um aplicativo Android que só tinha tema claro, medindo as mudanças em padrões de interface comuns e rastreando os resultados através do código de renderização do Android.

Configuração

Testei quatorze padrões de interface em uma tela, em três versões. O tema claro original, a versão escura que o Android gerou a partir dele (chamarei isso de auto-dark), e um tema escuro que construí manualmente seguindo Material 13, o próprio sistema de design da Google (construído à mão).

O que o Android preservou

A transformação poderia tornar texto legível ilegível? Não. Em meu experimento, tudo que passou no limiar de contraste WCAG no modo claro ainda passou após escurecer, e tudo que eu construí deliberadamente para falhar permaneceu quebrado. A razão por trás dessas decisões é:

Razão de Contraste = (L_claro + 0,05) / (L_escuro + 0,05)

onde L é a luminância relativa de cada cor. O texto branco na bandeira laranja falhou em 2,8 no modo claro e 2,7 no modo escuro automático. O Android herdou minhas contraste de acessibilidade ao invés de auditar ou alterá-las.

As famílias de cores também permaneceram, em grande parte. Os azuis ficaram azuis, os vermelhos ficaram vermelhos. A única exceção foi a bandeira laranja, que saiu vermelha. O motivo estava enterrado no código de renderização, o qual vem mais tarde.

A próxima pergunta que eu tinha era até que ponto um tema escuro automático se aproxima de um tema realmente projetado.

Automático vs manual

Em texto simples e superfícies, o tema escuro automático veio surpreendentemente perto do manual, com apenas pequenas diferenças de cor. Nesses padrões mais simples, o sistema operacional se aproximou surpreendentemente da minha saída manual sem ver um único token de design. A diferença apareceu em elementos coloridos e médios (pense em links, erros, pesquisa e bandeiras); todos leram 1,8 a 2,5 vezes melhor quando construídos manualmente.

A bandeira da marca mostra a diferença. Meu tema Material manual nunca tocou no laranja original. Estendeu a cor de marca em uma paleta de tons, então escolheu tons pela função da bandeira, dando ao esquema escuro um preenchimento marrom profundo com texto pêssego claro, os extremos claros e escuros do próprio laranja, passando no contraste por design em 6,6 para 1.

Essas etiquetas de função, atribuídas pelo desenvolvedor, nunca alcançam o renderizador do Android. No caso do tema escuro automático, a bandeira é apenas uma cor, então tudo que o Android pode fazer é passá-la pela matemática de escuridão e ela saiu em 2,7 para 1 e mais vermelha.

The failures clustered around saturated colors and middle grays. To understand why those colors behaved differently, I traced how Android transforms them in the renderer.

Inside the renderer

For ordinary Android UI rendering, the app records drawing instructions that eventually pass through HWUI, Android’s hardware-accelerated UI renderer. Expanded Dark Theme can transform colors in those drawing instructions before they become pixels.

Roughly, Android first decides whether a rendered chunk behaves like foreground or background. Text-containing nodes tend to become foreground and get pushed lighter; backgrounds get pushed darker, and the background guess is a heuristic the source itself labels a crude overlap check. Then one small piece of math picks the new color:

new lightness = min(110 − old lightness, 100)

applied only when it moves in the right direction. That guard is why my mid-grays never moved; a gray at lightness 50 maps to 60, wrong direction, left alone. Left alone is the trap. The gray stays put while everything behind it goes black, which is why the hand-built theme beat auto-dark on my placeholder; a designer re-lightens that gray, and the math never does. Here it is in the source:

SkColor makeDark(SkColor color) {
    Lab lab = sRGBToLab(color);
    float invertedL = std::min(110 - lab.L, 100.0f);
    if (invertedL < lab.L) {
        lab.L = invertedL;
        return LabToSRGB(lab, SkColorGetA(color));
    } else {
        return color;
    }
}

The math runs in CIELAB, a color system from 1976 that describes a color with three numbers:

L = luminosidade, de 0 (preto) a 100 (branco)
a = posição entre verde (-) e vermelho (+)
b = posição entre azul (-) e amarelo (+)

O sistema promete que a luminosidade vive em L, então você pode alterá-la sem tocar na cor. O Android reescreve L e deixa a e b inalterados.

Essa promessa cria dois problemas na prática. Primeiro, ela não é cumprida perfeitamente. A matemática se curva para alguns tons, como o laranja, que é parte do motivo pelo qual sistemas mais recentes como OKLab existem. Segundo, as telas trabalham em um intervalo de cores fixo chamado sRGB, e quando a matemática pede uma cor fora desse intervalo, a tela substitui pela mais próxima.

Meu banner laranja atingiu ambos os problemas. A curvatura o moveu cerca de quatro graus para o vermelho. Em seguida, o laranja escuro ficou fora do sRGB; não existe um laranja escuro e vívido, então a substituição fez os dez graus restantes. O padrão se curvou um pouco, e a tela não conseguiu entregar o resto.

O ponto

A Expansão do Tema Escuro é uma alternativa útil, especialmente para pessoas que precisam ou preferem fortemente interfaces mais escuras. Mas para desenvolvedores, o conselho antigo da Google ainda vale: envie seu próprio tema escuro. O Android pode transformar pixels. Ele não sabe que laranja é a cor de sua marca, que cinza é texto placeholder ou que vermelho comunica um erro. Conte com o modo escuro automático, e essas decisões caem sobre heurísticas do renderizador, matemática de cores e os limites do sRGB.

Para uma alternativa automática, os resultados são surpreendentemente bons. Eles ainda não substituem um tema projetado com significado em mente.