¿Mensajes de arranque de Android para la depuración?

Estoy tratando de averiguar si Android (es decir, Galaxy Nexus, Nexus S y/o Motorola Xoom) viene con algún tipo de capacidad para producir un registro de "arranque". (algo así como la pantalla de inicio de Linux) Sería inmensamente útil para determinar qué tan lejos llega el teléfono de uno en las etapas de inicio antes de que se bloquee (como el cargador de arranque de la primera etapa, el cargador de arranque principal, luego la carga del kernel, etc.). ¿Alguien sabe cómo habilitar el teléfono para escupir este archivo de registro o habilitar un modo de arranque "detallado" (e imprimir mensajes reales en la terminal de la computadora Linux a la que tiene conectado el teléfono)?

Mi teléfono se atasca en un "bucle de arranque" con mi compilación modificada actual y me gustaría depurarlo si es posible.

Alternativamente, ¿alguien sabe de recursos útiles o tutoriales que expliquen cómo "piratear" fácilmente el teléfono para hacer esto (sin alterar el hardware)? ¿O de algún foro donde se haya hecho mi pregunta pero de una forma más oscura?

Este ha sido un problema frustrante recientemente, por lo que cualquier ayuda sería muy apreciada.

Sé que comienza a escribir en el logcat desde el principio, pero eso se borra una vez que se reinicia. debería comenzar a escribir tan pronto como muestre la "animación de arranque" (o tal vez incluso un poco antes).
¿Cómo accederías a logcat sin "adb"? Adb solo funciona cuando el teléfono está en un estado estable, lo que contradice todo el punto, supongo, de por qué existe logcat (a quién le importa si el teléfono se inicia con éxito, no se necesita mucho la herramienta).
adb es uno de los primeros servicios que se inician. si ve la animación de arranque, adb ya se está ejecutando. adb incluso está disponible cuando está en modo de recuperación.
Bueno, no estoy seguro de estar viendo la animación de arranque de la que hablas. Después del símbolo de "carga" de la batería, el teléfono se cuelga en la pantalla de inicio con "Google" en blanco antes de que se bloquee. No hay pantalla de inicio de "Android" después de eso, ni ninguna animación de arranque. Así que no creo que ADB funcione todavía...

Respuestas (3)

Hay un par de maneras de hacer esto:

  • cat /proc/last_kmsg > /sdcard/last_kernel_message_log.txt
  • dmesg > /sdcard/kernel_boot_log.txt
  • conecte el cable usb con el teléfono inteligente apagado. Luego emita el comando adb logcatdesde su Windows cmd o terminal Linux, se colgará esperando que el dispositivo se conecte, ahora encienda el teléfono inteligente. El logcat debería comenzar a desplazarse entonces.

Dado que expresó interés en averiguar qué tan lejos llega el teléfono de uno en las etapas de arranque antes de que se bloquee , esos métodos deberían ayudar. La cuestión es que debe ser bastante rápido para obtener el registro del kernel (los dos primeros métodos que se muestran arriba).

Lo que haría es esto, en mi caja Arch Linux, dos ventanas de terminal, una para el adb logcat, la otra, para tomar el registro en el momento en que logcat comienza a desplazarse.

Editar:

TENGA en cuenta que existen diferencias con el uso de adby fastboot!

fastbootfunciona de manera diferente, solo se usa para flashear imágenes en particiones específicas y está más relacionado con el proceso del cargador de arranque, es decir, puede comprender el mecanismo del cargador de arranque. También requiere que:

  • bajo Windows, privilegio de 'Administrador' para ejecutarlo
  • bajo Linux, privilegio 'root'

La razón por la que lo requiere es porque omite ciertas entradas/salidas del hardware y, por lo tanto, no "habla" en el adbprotocolo, sino que "habla" directamente con el cargador de arranque. Algo que no se puede hacer como un usuario normal. Aquí está la ayuda para el uso de fastboot.

$ sudo fastboot
usage: fastboot [ <option> ] <command>

commands:
  update <filename>                        reflash device from update.zip
  flashall                                 flash boot + recovery + system
  flash <partition> [ <filename> ]         write a file to a flash partition
  erase <partition>                        erase a flash partition
  getvar <variable>                        display a bootloader variable
  boot <kernel> [ <ramdisk> ]              download and boot kernel
  flash:raw boot <kernel> [ <ramdisk> ]    create bootimage and flash it
  devices                                  list all connected devices
  continue                                 continue with autoboot
  reboot                                   reboot device normally
  reboot-bootloader                        reboot device into bootloader
  help                                     show this help message

options:
  -w                                       erase userdata and cache
  -s <serial number>                       specify device serial number
  -p <product>                             specify product name
  -c <cmdline>                             override kernel commandline
  -i <vendor id>                           specify a custom USB vendor id
  -b <base_addr>                           specify a custom kernel base address
  -n <page size>                           specify the nand page size. default: 2048

Un uso bien conocido de fastbootes para flashear, por ejemplo, para flashear una imagen de recuperación: sudo fastboot flash recovery recovery.img, otro es para flashear directamente una imagen sin procesar, sudo fastboot flash system system.img. Para obtener más información sobre el caso del desarrollo del kernel, al usar this fastboot boot new_kernel, esto descarga temporalmente un nuevo kernel y arranca usándolo sin tocar el propio arranque del cargador de arranque.

También hay una limitación en el tamaño de una imagen en bruto que requiere ser flasheada, cuando digo imagen en bruto, me refiero a un archivo que tiene una .imgextensión, la imagen no debe exceder los 128Mb. ( ¡Descubrí esto cuando desarrollé ics4blade, después de que se completó la compilación, system.img tenía 162 Mb, e intenté actualizarlo pero fastboot se negó! Para eludir la limitación, tuve que crear un archivo zip CWM flashable para hacer eso y moverse eso! )

Practique la precaución y asegúrese de que la partición sea correcta y verifique dos veces y verifique nuevamente, si es necesario, aléjese de la computadora, tome un descanso, regrese nuevamente y vuelva a verificar nuevamente, aquí es donde puede salir terriblemente mal, flashea el archivo incorrecto en la partición incorrecta... bueno, se encoge de hombros

Esta es una gran idea, pero un problema... adb solo funciona si el demonio adb puede detectar el dispositivo. Si el teléfono no se ha iniciado correctamente, adb no funciona. Entonces, un "bucle de arranque", cuando más necesitaría logcat, no funcionaría, y no lo es en este momento mientras lo intento. Lo único a lo que tiene acceso en cuanto a comandos que no le importa si el teléfono se ha iniciado correctamente es "arranque rápido". ¿Cuál es una alternativa en este caso entonces?
@ 9exceptionThrower9 editó mi respuesta para incluir el concepto de fastboot y para responder en su comentario, fastboot no funcionará :)
La única alternativa que se me ocurre es que fastboot borre la partición cachey data- ¡No soy responsable de nada malo si continúas! E intente flashear la ROM nuevamente a través de CWM. Aún mejor , olvídate del fastboot y usa CWM para borrar tanto el caché como los datos , parece que el bootloop se debe a un caché o datos dañados...
Como cuestión de interés, ¿ qué hizo exactamente para que se inicie el bootloop? Esa es una pregunta crucial y le gustaría saber qué pasos tomó.
Modifiqué el kernel de Android (maguro) para Galaxy Nexus, particularmente el archivo "socket.h" para anular el registro de INET con el proyecto de investigación de mi equipo FINS (que extrae protocolos de Internet en el espacio de usuario para investigadores de redes). Después de modificar este archivo (solo unas pocas líneas), volví a compilar el kernel con éxito, inserté este kernel en el árbol de compilación maguro de Android, reconstruí la imagen del sistema Android y luego actualicé los nuevos archivos de recuperación, arranque, sistema y userdata.img en el teléfono...
...El teléfono se atasca después de mostrar el símbolo de la batería y se cuelga un momento en la pantalla de inicio con el texto "Google" en blanco, luego se cuelga. ¿Alguna sugerencia basada en esta situación única?
por lo que vale, por experiencia cuando se construye desde la fuente y se cuelga en el chapoteo, generalmente no puede montar algunas particiones. Compararía tanto el stock como el modded fstab para ver si algo cambió. probablemente pueda habilitar adb en init.rc y capturar el registro antes del bloqueo. pero pueden ser muchas otras cosas.
fastbootno siempre requiere acceso de root, al menos no en algunas distribuciones de Linux. Simplemente puede indicar a las personas que usen sudo o administrador si se les niega el permiso.

Puede utilizar LiveBoot. Está en Google Play Store. Hará justo lo que usted está pidiendo.

¿Qué pasa si tengo bootloop? ¿Hay alguna manera de hacerlo con un cable USB?
no sé si eso gana la etiqueta de registro, pero es un buen truco :) play.google.com/store/apps/details?id=eu.chainfire.liveboot

Puede acceder a la recuperación en esa pantalla, le permite acceder a algunos archivos de registro a los que no puede acceder una vez que se inicia el teléfono. Lo que está tratando de solucionar estará en estos registros previos al arranque.

¿Mensajes de arranque de Android para la depuración?
RespuestasAquíPolítica de privacidad1y, 0v