Depuración de bootloop: ¿Obtener un registro de información sin ADB? ¿Puede un emulador ayudar? [duplicar]

Posible duplicado:
¿mensajes de inicio de Android para depuración?

Relacionado con esta publicación que creé: ¿El emulador de Android genera algún tipo de archivo de registro al que puedo acceder si falla?

He estado buscando y tratando de averiguar si hay alguna forma de obtener algún tipo de información de depuración o algún tipo de mensaje del kernel de un teléfono Android si se atasca en un estado de bootloop. Eso significa que el teléfono se atasca en la pantalla de inicio de "Google", luego se bloquea, luego va a eso y luego se bloquea.

Sé que el teléfono tiene varias etapas de carga de arranque, pero para poder averiguar por qué la imagen de mi sistema/kernel modificado está haciendo que el teléfono se bloquee, necesito al menos saber dónde se bloquea el teléfono.

¿Hay algún tipo de registro que el emulador de Android escupe que muestre que pasa por las etapas de arranque: es decir, el cargador de arranque de la etapa 1, el cargador de arranque de la etapa principal, el kernel que se está cargando, el proceso de inicialización, Zygote, Zygote inicializando Dalvik VM, ejecución del servidor del sistema, luego arranque completado (cuando ACTION_BOOT_COMPLETEse levanta la bandera/evento).

Intenté modificar init.rclos comandos de eco en un registro de inicio (pero no funcionó, aunque no sé si el teléfono llega a esa etapa, todo lo que tengo es una pantalla de bienvenida inútil), probé cualquier de las cosas de ADB pero, por supuesto, ADB no funciona si el teléfono no alcanza un estado estable, el dmesgcomando de Linux solo funciona para mostrar que el teléfono se conectó a través de USB, y los desarrolladores de Android han optado por no explicar al menos a me dice que solo ellos tienen ese tipo de herramientas de desarrollo. ¿Alguien puede darme alguna orientación sobre lo que puedo hacer para depurar el proceso de arranque? Tiene que haber algún tipo de registro al que pueda acceder con el emulador al menos.

En otras palabras, ¿cómo alguien obtiene algún tipo de registro de su teléfono/emulador si se queda atascado en un bootloop?

Más información, la versión de mi kernel que creo que he descargado para la compilación de mi teléfono es la versión 3.x del kernel de Linux (kernel estándar extraído de la tunacarpeta y usando el proyecto "omap"), para Android Galaxy Nexus (maguro), con la plataforma siendo Android 4.0.3 ICS.

Respuestas (1)

Sabrás si el kernel se ha colgado, la luz led se queda encendida y no vas a más.

En cuanto a su pregunta, debe ser más claro y específico, ya que no lo sabemos y ya que publicó una pregunta similar antes. No ha dicho qué dispositivo es, qué versión de Android es, qué kernel es, todo eso queda fuera y, por lo tanto, juega un juego de adivinanzas aquí.

  • ¿Es el ramdisk no creado correctamente?
  • ¿Es la dirección utilizada para arrancar incorrecta?
  • ¿La ROM está construida para VMSPLIT 3G y el kernel está construido con VMSPLIT 2G o viceversa?
  • ¿Qué conjunto de chips es? Kernel ARMv7 con ROM compilado para ARMv6...
  • ¿Está realmente arrancando el kernel? en caso afirmativo, ¿cómo lo sabe?

Demasiadas cosas aquí para especular.

Editar:

Este bit está relacionado con la depuración a nivel de kernel.

La única manera de saber si el núcleo realmente está arrancando en primer lugar es usar un cable USB a serie TTY con clavijas JTAG en una pequeña placa de circuito recortada/soldada a la parte posterior del dispositivo en cuestión, y tener el controlador serie compilado en el kernel y tratando la consola como un dispositivo tty, y leyendo de él a través de minicom o hiperterminal para ver la secuencia de arranque.

En cuanto a los bucles de arranque,

La causa de los bucles de arranque se debe a la propia ROM, la secuencia de inicialización se bloquea en alguna parte. Ahora tenga cuidado :), el kernel en sí mismo, puede iniciar un bucle también debido a un mal funcionamiento del controlador, pánico y reinicio.

Entonces la pregunta es, ¿cuál es? , ¿Es el núcleo el que sigue reiniciando o ha pasado esa etapa y comenzó a cargar la ROM? Si está en la etapa de carga de la ROM, entonces algo en la inicialización está fallando, cuando la ROM falla, envía una señal para apagar SurfaceFlinger, AudioFlinger, adb daemon, MedaServices, etc.

Lo que puedes hacer es esto - en el init.rc, donde tienes esto:

service console /system/bin/sh
    console
    disabled
    user shell

Cambie disableda enabled, la próxima vez, Android lo dejará en la consola, es decir, no tendrá una interfaz gráfica familiar.

Además, busque las líneas que contienen servicemanager, si el demonio adbd aparece allí, sáquelo ya que lo que sucede es la cláusula de directiva criticaly onrestarthará que no tenga ninguna función adb.

He editado mi publicación para reflejar detalles más específicos del sistema.