Soft brick y hard brick en Android: cómo distinguirlos

La diferencia no está en lo muerto que parezca el teléfono, sino en si un ordenador todavía puede comunicarse con él. Dos comandos lo aclaran en menos de un minuto, y la respuesta decide si te enfrentas a un reflasheo de firmware, a un procedimiento de recuperación de bajo nivel o a una reparación de placa.

La palabra «brick» abarca al menos cuatro estados distintos

Se dice «bricked» para todo, desde un bucle de animación de arranque hasta un teléfono que ha pasado por la lavadora. No son el mismo problema ni acaban igual, así que la etiqueta por sí sola no le dice nada a un técnico.

Este es el espectro real, del más recuperable al menos recuperable:

1. El dispositivo arranca en algo. Recovery, fastboot, modo de descarga, una pantalla del bootloader o incluso una pantalla de error. Ejecuta código y se puede acceder a él.
2. El dispositivo no muestra nada, pero un ordenador lo detecta. No hay imagen en pantalla, pero al conectarlo aparece un dispositivo USB en el equipo. Es el estado al que con más frecuencia y con mayor desacierto se le llama «hard brick».
3. El dispositivo no muestra nada y nada lo detecta, pero responde físicamente. Vibra al encenderlo, se calienta o se enciende el LED de carga. Algo se está ejecutando.
4. Ausencia total de respuesta. Sin pantalla, sin enumeración USB, sin vibración, sin comportamiento de carga y sin calor.

Solo el cuarto es lo que «hard brick» quería describir en origen, y aun así importa la causa: una batería muerta y una placa base muerta dan el mismo síntoma vistas desde fuera.

La tabla de decisión

Haz primero la prueba de detección de la sección siguiente y luego lee la fila que coincida.

Dos filas de esa tabla son las que más se malinterpretan. La del modo de descarga y de emergencia se llama «hard brick» y con frecuencia es recuperable. La de «vibra pero no se detecta» se llama «soft brick» porque el teléfono da señales de vida, y a menudo es el problema más difícil.

Cómo hacer bien la prueba de detección

La tabla solo sirve si el resultado de la detección es fiable. Un teléfono que está perfectamente bien puede parecer no detectado por culpa de un cable solo de carga o de un driver que falta, y ese diagnóstico erróneo lleva a conclusiones caras.

Paso 1. Usa un cable que sepas que transmite datos. No uno que des por bueno, sino uno con el que ya hayas transferido archivos. Existen cables solo de carga y producen justo el síntoma que intentas interpretar.

Paso 2. Usa un puerto USB trasero, directamente en el equipo. Sin hub, sin puerto del monitor y sin dock.

Paso 3. Haz las dos comprobaciones en cada estado al que entre el dispositivo.

adb devices
fastboot devices

Paso 4. Mira la lista de dispositivos del sistema operativo, no solo lo que muestra la herramienta. Este paso distingue un resultado real de un falso negativo, porque un dispositivo puede enumerarse por USB aunque la herramienta de línea de comandos no muestre nada.

• Windows: abre el Device Manager y observa la lista mientras conectas el teléfono. Que algo aparezca y desaparezca, o que salga como dispositivo no reconocido, cuenta como detección positiva aunque fastboot devices no haya mostrado nada.
• macOS: abre System Information, ve a USB y busca una entrada nueva.
• Linux: ejecuta lsusb antes y después de conectarlo y compara, o vigila dmesg mientras lo enchufas.

Un dispositivo USB sin nombre o desconocido no equivale a «no se detecta nada». Significa «detectado, pero sin identificar», que es una fila completamente distinta de la tabla y suele ser un problema de drivers, no un teléfono muerto. Si el resultado es una detección ausente o ambigua, repasa la lista de comprobación de detección de fastboot antes de concluir que el dispositivo está muerto.

Paso 5. Prueba el dispositivo con un segundo ordenador, a ser posible con otro sistema operativo. Así descartas de golpe todo un tipo de problemas del lado del equipo.

Por qué «hard brick» suele ser el término equivocado

El término se popularizó cuando los dispositivos Android tenían vías de recuperación más sencillas y un flasheo fallido solía significar ir al taller. Han cambiado dos cosas.

Primero, los fabricantes de chipsets incluyen interfaces de recuperación de bajo nivel que quedan por debajo del bootloader. Las plataformas Qualcomm exponen un modo de descarga de emergencia. Las plataformas MediaTek exponen una interfaz a nivel de BootROM. Los dispositivos Samsung tienen su propio modo de descarga. Existen para que un dispositivo con el bootloader dañado se pueda volver a flashear, y uno que está en cualquiera de ellas desde luego no es un pisapapeles.

Segundo, las herramientas y el firmware para usar esas interfaces están mucho más disponibles que antes, aunque la disponibilidad varía muchísimo según el fabricante y el modelo. Algunos fabricantes protegen estas interfaces con una autenticación que solo se concede a proveedores de servicio autorizados. Otros no.

El resultado es que la pregunta práctica ya no es «¿soft o hard?», sino «¿qué interfaz sigue exponiendo este dispositivo concreto y se puede usar con el firmware y la autorización que realmente existen para este modelo?»

Es una pregunta más acotada y más útil, y por eso no damos una tasa de recuperación general. Un dispositivo en modo de emergencia con firmware publicado y sin requisito de autenticación es un trabajo. El mismo síntoma en un modelo cuyo fabricante restringe la interfaz es otro trabajo con otra respuesta, y a veces la respuesta honesta es que no hay recuperación por software.

Nuestro servicio de recuperación de firmware y bricks empieza justo por esta determinación, y te decimos en cuál de esas dos situaciones estás antes de dar ningún presupuesto.

Lo que de verdad no se puede recuperar por software

Algunos estados no tienen solución por software, y conviene hablar de ellos con franqueza:

• Almacenamiento averiado. Si la propia memoria flash ha fallado, no hay dónde escribir el firmware. Puede presentarse como un dispositivo que entra en modo de flasheo y falla durante cada intento.
• Gestión de energía o placa dañada. Un dispositivo que no alimenta sus líneas de tensión no ejecutará código, tengas el firmware que tengas.
• Daños en la placa por líquidos o golpes. La corrosión y las pistas rotas son problemas físicos.
• Fusible de seguridad quemado en algunos dispositivos. Ciertos fabricantes implementan fusibles de seguridad de un solo sentido. Una vez que saltan, ese estado no se puede revertir por software. Si esto afecta a la recuperación, y cómo, depende del fabricante. En los dispositivos Samsung, el fusible Knox afecta concretamente a la garantía y a ciertas funciones seguras, no a la capacidad de flashear firmware, y explicamos aparte qué hace y qué no hace.
• Modelos cuya interfaz de bajo nivel exige autenticación y cuya autorización no se puede conseguir. Es un límite real y ninguna habilidad técnica lo elimina.

Quien prometa recuperar a distancia cualquier dispositivo en cualquier estado describe un modelo de negocio, no una capacidad técnica.

Qué datos pierdes en cada categoría

La complejidad de la recuperación y el destino de los datos son dos ejes distintos, y no evolucionan a la par.

La clasificación sorprende: un dispositivo que arranca en bucle, lo cual asusta, está en mejor posición para tus datos. Uno que exige un reflasheo de bajo nivel, que parece un triunfo cuando funciona, suele costarte todo lo que contiene.

Conviene entenderlo antes de autorizar cualquier reparación. «Lo hemos vuelto a poner en marcha» y «hemos salvado tus archivos» son resultados distintos, y el segundo es mucho más difícil. Si lo que te importa son los datos, dilo desde el principio y lee cómo abordar un bootloop sin perder datos antes de que nadie empiece a flashear. Si los archivos son irreemplazables, nuestro servicio de recuperación de datos evalúa qué es realista según el estado del dispositivo, incluso cuando la respuesta es que no se puede recuperar nada.

Preguntas frecuentes

Mi teléfono vibra pero la pantalla sigue negra. ¿Soft o hard brick? No se puede saber hasta que hagas la prueba de detección. La vibración indica que algo se está ejecutando, lo cual es buena señal, pero lo decisivo es si un ordenador lo enumera. Mira la lista de dispositivos del sistema operativo, no solo lo que muestra la herramienta.

¿Un soft brick puede convertirse en hard brick? Sí, y es el principal motivo para parar a tiempo. Flashear la imagen equivocada, interrumpir un flasheo o usar herramientas del fabricante con el modelo incorrecto puede llevar un dispositivo de un estado recuperable a uno mucho peor. Cada intento fallido es una oportunidad de complicarlo más.

¿Un bootloop es un soft brick? Según la definición habitual, sí: el dispositivo ejecuta código y se puede acceder a él. Dicho esto, «bootloop» describe lo que ves y «soft brick» describe la categoría, y el síntoma de arranque concreto aporta más información de diagnóstico que cualquiera de las dos etiquetas.

¿Desbloquear el bootloader ayuda a recuperar un dispositivo con brick? No como paso de recuperación, y tiene su propio coste. En Android, desbloquear el bootloader borra los datos como medida de seguridad. Si el dispositivo ya está desbloqueado, es útil porque amplía las opciones disponibles. Desbloquearlo ahora solo para intentar una recuperación supone aceptar el borrado.

¿Un taller de reparación sabrá notar la diferencia? Uno competente hará la misma prueba de detección y llegará a la misma conclusión. Desconfía de cualquier presupuesto dado sin haber conectado antes el dispositivo a un ordenador, porque la categoría no se puede determinar mirando la pantalla.

¿Cuánto de todo esto se puede hacer a distancia? Los estados en los que el dispositivo es accesible y tienes un ordenador que funciona se prestan bien a la asistencia remota, porque las operaciones se ejecutan desde el equipo. Los que requieren herramientas de servicio del fabricante o trabajo en la placa, no. Esto es lo que implica realmente una sesión remota.

---

Lecturas relacionadas: Arreglar un bootloop sin perder datos · Qué significa cada síntoma de la pantalla de arranque · Dispositivo fastboot no detectado · Fallo al flashear Magisk · Android arranca siempre en recovery

Fuentes: documentación del Android Open Source Project sobre bootloader y particiones.

Última verificación: 22 de agosto de 2026. Las interfaces de recuperación de bajo nivel, su disponibilidad y los requisitos de autenticación varían según el chipset, el fabricante y el modelo. Confírmalo en la documentación oficial de tu dispositivo.