Xiaomi brickado: salvei o aparelho com ADB sideload quando o recovery falhou

Era uma noite de terça-feira cinzenta quando decidi atualizar o Redmi Note 14 Pro para uma build noturna de uma ROM customizada. O erro não veio acompanhado de mensagens amigáveis. Houve apenas o fim do logo da Xiaomi e o mergulho no vazio digital. O aparelho vibrava a cada 10 segundos, tentando reiniciar, mas a tela permanecia preta. O pior: a combinação clássica de botões para entrar no Recovery (Volume Up + Power) estava simplesmente ignorada pelo sistema. O hardware estava vivo, mas o software estava em coma profundo.

Esse cenário, conhecido como "soft brick" com display driver corrompido ou partição de recovery inacessível visualmente, geralmente leva as pessoas direto para a assistência técnica ou para tutoriais complicados envolvendo a ferramenta Deep Flash e cabos de teste. Eu não tinha o cabo, e o orçamento para conserto não existia. A solução veio de uma técnica antiga, muitas vezes esquecida nos tutoriais modernos que focam apenas em interfaces gráficas: o ADB sideload cego.

O estado do "meia-luz" e o erro do Mi Flash

O primeiro passo foi diagnosticar o porquê de o Mi Flash, a ferramenta oficial da Xiaomi, não reconhecer o dispositivo. Ao conectar o aparelho na porta USB 3.0 da minha mesa, o Windows emitia o som de conexão, mas o Mi Flash insistia que não havia dispositivos na porta EDL (Emergency Download). O problema era que o celular não estava entrando em EDL, nem em Fastboot. Ele estava preso em um limbo onde o kernel carregava o mínimo para ser detectado pelo ADB, mas falhava em renderizar a interface gráfica do recovery.

Foi aí que lembrei de uma peculiaridade do Android: a interface do Recovery e o daemon do ADB às vezes rodam em camadas separadas. Se o driver de vídeo do recovery estiver corrompido, você não vê nada, mas o ADB pode estar lá, ouvindo. Abri o Prompt de Comando na pasta platform-tools e digitei adb devices. A resposta veio instantânea: recovery. O sistema estava lá, esperando por comandos, mas eu estava voando às cegas sem o radar visual.

Se você já passou por algo parecido ao tentar instalar algo mais elaborado e se deparou com tela preta, sabe que o desespero é real. Muitos usuários acabam por tentar ferramentas de "unbricking" genéricas que podem apagar a partições de modem ou IMEI. O segredo aqui foi confiar no protocolo ADB mesmo sem feedback visual.

Por que o ADB sideload foi a única saída

O modo sideload é uma função do protocolo ADB que permite enviar um arquivo .zip diretamente para o dispositivo, que o aplica imediatamente na partição ativa. Diferente de copiar um arquivo para o armazenamento interno (o que exigiria acesso ao sistema de arquivos, algo que eu não tinha), o sideload joga o pacote na memória volátil e executa a instalação.

A grande vantagem neste caso de tela preta: eu não precisava navegar pelos menus do recovery com as teclas de volume. O comando adb sideload arquivo.zip força a entrada nesse modo de transferência via software, contornando a falha do driver de vídeo que impedia a exibição do menu na tela do celular.

Arrisquei uma abordagem arriscada, porém necessária. O objetivo não era necessariamente instalar a última ROM customizada de novo, que pode ter causado o conflito, mas sim um pacote menor e mais seguro de uma ROM stock ou uma build do LineageOS mais estável para retomar o controle do sistema. Eu precisava de algo que limpasse o sistema sem depender da interface.

Executando o procedimento às cegas

Coloquei o arquivo da ROM stock (a versão global mais recente, baixada do site da Xiaomi) na mesma pasta do platform-tools para facilitar a digitação. A primeira tentativa de sideload falhou no meio do caminho com erro de protocolo. Isso acontece quando o cache do adb no PC fica "encalhado" na sessão anterior.

Tive que reiniciar o serviço no PC com adb kill-server seguido de adb start-server. O celular, no entanto, continuava na mesma tela preta. Não tentei reiniciá-lo manualmente, pois tinha medo de ele não entrar mais nesse estado de "recovery fantasma".

Com o serviço resetado, o comando seguinte foi crucial:

adb sideload twrp-3.7.0-12-14.img.zip

Perceba que eu não mandei a ROM inteira de 3GB. Primeiro, tentei flashear uma versão do TWRP (Recovery customizado) compatível com o Android 15. A ideia era substituir aquele recovery corrompido que não mostrava imagem. O progresso corria no prompt do Windows. A porcentagem subiu lentamente: 10%, 25%, 47%. Pareceu travar no 47% por três minutos. O suor frio voltou. Interromper um sideload no meio é sentença de morte definitiva para o dispositivo naquele momento. Deixei rodar. Felizmente, ele pulou para 100% e disse "Total xfer: 1.00x".

A luz no fim do túnel e o Rollback obrigatório

Assim que o sideload terminou, o aparelho vibrou duas vezes. Eu mantive a fé e dei o comando adb reboot recovery. Dessa vez, embora o demorasse uns 20 segundos, a tela finalmente acendeu. Não era o recovery oficial da Xiaomi, mas sim o interface roxa do TWRP. Eu tinha conseguido injetar um recovery funcional sem ver nada. Com a interface restaurada, o caminho de volta estava aberto.

A partir daí, o processo seguiu o padrão, mas com uma ressalva importante de segurança. Eu não fiquei na ROM customizada que causou o problema. Fiz um "Wipe" (Factory Reset) completo e utilizei a opção "Install" do próprio TWRP para mandar a ROM stock original (Fastboot ROM convertida em zip para recovery ou zip de atualização oficial). Após a instalação da ROM stock, o sistema inicializou normalmente.

Política de Retorno (Rollback): Se você pretende seguir este caminho, tenha em mente que o objetivo é salvar o hardware, não necessariamente manter o mod. Para garantir que o dispositivo volte ao estado original de fábrica e elimine qualquer bug residual de kernel ou partição, o método mais seguro após recuperar o acesso é via Fastboot:

1. Baixe a ROM Fastboot adequada para o seu modelo exato (evite Cross-Flash);
2. Entre no modo Fastboot (Volume Menos + Power);
3. Use o script flash_all.bat dentro da ROM descompactada no computador.

Isso reescreve todas as partições, incluindo a que estava causando o conflito inicial.

Lições técnicas de um resgate silencioso

Essa experiência serviu como um lembrete brutal de que modding envolve riscos reais, e que nem todo "brick" é irreversível. O segredo foi entender que a tela preta não significava sistema morto. Muitas vezes, o Android é resiliente o suficiente para carregar o daemon ADB antes de tentar renderizar gráficos complexos. Se você se deparar com um aparelho que vibra, é reconhecido pelo PC mas não mostra nada, não desista imediatamente. Verifique se o adb devices tem algo a dizer.

Depois que o celular voltou à vida com a ROM stock, tive que começar do zero. A primeira coisa antes de qualquer nova aventura com LineageOS vs crDroid: escolha estabilidade ou personalização foi verificar se os blocos de armazenamento não tinham setores defeituosos. O procedimento de recuperação funciona, mas é estressante para o controlador de memória.

O custo emocional e o tempo perdido (cerca de 4 horas de pânico e tentativas) não compensam a falta de um backup completo antes de começar. Hoje, antes de qualquer flash, verifico se o MindTheGapps é obrigatório em toda ROM customizada, pois conflitos nessa área costumam ser gatilhos para problemas de inicialização que não dão erro claro, apenas tela preta.

Por fim, com o sistema estável, o passo seguinte foi garantir que meus apps bancários funcionassem sem reclamar do bootloader desbloqueado, seguindo o guia de como esconder o root do app do Nubank no Android 14. A ordem é simples: recupere, estabilize e só depois modifique novamente. A linha de comando salvou o meu aparelho, mas o bom senso é que evita o próximo susto.