29 votos

¿Mensajes de arranque de Android para depuración?

Estoy tratando de averiguar si Android (es decir, Galaxy Nexus, Nexus S, y / o Motorola Xoom) vienen con algún tipo de capacidad para producir un registro de "arranque". (algo así como la pantalla de arranque de Linux) Sería inmensamente útil para averiguar hasta qué punto el teléfono de uno llega en las etapas de arranque antes de que se bloquee (como la primera etapa del gestor de arranque, gestor de arranque principal, a continuación, 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 "verboso" (e imprimir mensajes reales en el terminal del ordenador Linux al que se tiene conectado el teléfono)?

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

Alternativamente, ¿alguien sabe de algún recurso útil o tutoriales que explican cómo fácilmente "hackear" el teléfono para hacer esto (sin meterse con el hardware)? ¿O de algún foro en el que se haya planteado mi pregunta pero de forma más oscura?

Éste ha sido un problema frustrante en los últimos tiempos, por lo que cualquier ayuda será muy apreciada.

0 votos

Sé que empieza a escribir en el logcat muy pronto, pero eso se borra una vez que se reinicia. debería empezar a escribir tan pronto como muestra la "animación de arranque" (o tal vez incluso un poco antes).

3 votos

¿cómo acceder a logcat sin "adb"? Adb sólo funciona cuando el teléfono está en un estado estable, lo que contradice el punto entero supongo que en cuanto a por qué existe logcat (a quién le importa si el teléfono se inicia correctamente, no hay mucha necesidad de la herramienta).

0 votos

Adb es uno de los primeros servicios que se inician. si ves la animación de arranque, adb ya se está ejecutando. adb está disponible incluso cuando estás en modo de recuperación.

18voto

Nick Pierpoint Puntos 7976

Hay un par de maneras de hacerlo:

  • 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. A continuación, ejecute el comando adb logcat desde tu terminal Windows cmd o Linux, se colgará esperando a que el dispositivo se conecte, ahora enciende el smartphone. El logcat debería empezar a desplazarse entonces.

Dado que ha expresado su interés por averiguar hasta dónde llega el teléfono en las etapas de arranque antes de que se bloquee esos métodos deberían ayudar. La cosa es que tienes que ser bastante rápido para agarrar el registro del kernel (los dos primeros métodos mostrados arriba).

Lo que yo haría es lo siguiente, en mi caja Arch Linux, dos Windows de terminal, uno para el adb logcat y la otra, para coger el registro en cuanto logcat empiece a desplazarse.

Edita:

Tenga en cuenta que hay diferencias con el uso de adb y fastboot ¡!

fastboot funciona de manera diferente, sólo se utiliza para flashear imágenes en particiones especificadas, y está más ligado al proceso del cargador de arranque, es decir, puede entender el mecanismo del cargador de arranque. También requiere que:

  • en Windows, privilegio de 'Administrador' para ejecutarlo
  • en Linux, privilegio 'Root

La razón por la que lo requiere es porque puentea ciertas entradas/salidas del hardware, y por tanto, no "habla" en adb sino "hablar" directamente con el cargador de arranque. Algo que no se puede hacer como 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 fastboot es para flashear, por ejemplo, para flashear una imagen de recuperación: sudo fastboot flash recovery recovery.img otra es flashear directamente una imagen sin procesar, sudo fastboot flash system system.img . Para más de para el caso del desarrollo del kernel, utilizando este fastboot boot new_kernel , esto descarga temporalmente un nuevo kernel y arranca usando eso 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 flasheado, cuando digo imagen en bruto, me refiero a un archivo que tiene un .img la imagen no debe superar los 128 Mb. ( ¡Descubrí esto cuando desarrollaba ics4blade, después de que la compilación se completara, el system.img era de 162Mb, e intenté flashearlo pero fastboot se negó! Para eludir la limitación, tuve que crear un archivo zip CWM flashable para hacerlo y evitarlo. )

Tenga cuidado y asegúrese de que la partición es correcta y vuelva a comprobarlo una y otra vez, si es necesario, aléjese del ordenador, tómese un descanso, vuelva de nuevo, y vuelva a comprobarlo otra vez, aquí es donde puede salir terriblemente mal, flashear el archivo equivocado en la partición equivocada... bueno se encoge de hombros

4 votos

Esta es una gran idea, pero un problema....adb sólo funciona si el demonio adb puede detectar el dispositivo. Si el teléfono no ha arrancado correctamente, adb no funciona. Así que un "boot-loop", cuando más se necesitaría logcat no funcionaría, y no lo está haciendo en este momento mientras lo pruebo. La única cosa que tienes acceso a comandos que no le importa si el teléfono ha arrancado con éxito es "fastboot". ¿Cuál es una alternativa en este caso entonces?

0 votos

@9exceptionThrower9 he editado mi respuesta para incluir el concepto de fastboot y para responder en su comentario, fastboot no funcionará :)

0 votos

La única alternativa que se me ocurre es, borrar por fastboot el cache y data partición: ¡no me hago responsable de ningún contratiempo si procede! Y tratar de flashear la ROM de nuevo a través de CWM. Aún mejor olvídate de fastboot y utilizar CWM para limpiar tanto caché y datos Parece que el bucle de arranque se debe a una caché o a unos datos...

1voto

Narcotixs Puntos 23

Puedes usar LiveBoot. Está en Google Play Store. Se va a hacer exactamente lo que usted está pidiendo.

0voto

snehal s Puntos 26

Usted puede ir a la recuperación en esa pantalla que le permite acceder a algunos archivos de registro que no se puede acceder una vez que el teléfono arranca. Lo que su tratando de solucionar problemas será en estos registros de pre arranque.

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X