Android-Startmeldungen zum Debuggen?

Ich versuche herauszufinden, ob Android (dh Galaxy Nexus, Nexus S und/oder Motorola Xoom) mit einer Art Fähigkeit ausgestattet ist, ein "Boot-Up"-Protokoll zu erstellen. (ähnlich wie Linux-Startbildschirm) Es wäre immens hilfreich, herauszufinden, wie weit das Telefon in den Startphasen kommt, bevor es abstürzt (z. B. Bootloader der ersten Stufe, Haupt-Bootloader, dann Laden des Kernels usw.). Weiß jemand, wie man dem Telefon ermöglicht, diese Protokolldatei auszuspucken oder einen "verbose" Startmodus zu aktivieren (und tatsächliche Nachrichten an das Terminal des Linux-Computers zu drucken, an den das Telefon angeschlossen ist)?

Mein Telefon bleibt mit meinem aktuellen modifizierten Build in einer "Boot-Schleife" hängen und ich möchte es nach Möglichkeit debuggen.

Alternativ kennt jemand nützliche Ressourcen oder Tutorials, die erklären, wie man das Telefon einfach "hackt", um dies zu tun (kein Durcheinander mit der Hardware)? Oder von irgendwelchen Foren, wo meine Frage vielleicht gestellt wurde, aber in einer obskureren Form?

Dies war in letzter Zeit ein frustrierendes Problem, daher wäre jede Hilfe sehr willkommen!

Ich weiß, dass es sehr früh anfängt, in den Logcat zu schreiben, aber das wird gelöscht, sobald es neu gestartet wird. Es sollte mit dem Schreiben beginnen, sobald es die "Boot-Animation" zeigt (oder vielleicht sogar etwas früher).
Wie würden Sie ohne "adb" auf logcat zugreifen? Adb funktioniert nur, wenn sich das Telefon in einem stabilen Zustand befindet, was meiner Meinung nach dem ganzen Punkt widerspricht, warum logcat existiert (wen interessiert es, ob das Telefon erfolgreich startet, es wird nicht viel für das Tool benötigt).
adb ist einer der ersten Dienste, die starten. Wenn Sie die Boot-Animation sehen, wird adb bereits ausgeführt. adb ist sogar verfügbar, wenn Sie sich im Wiederherstellungsmodus befinden.
Nun, ich bin mir nicht sicher, ob ich die Boot-Animation sehe, von der Sie sprechen. Nach dem Symbol „Laden“ des Akkus hängt das Telefon am Begrüßungsbildschirm mit „Google“ in Weiß darauf, bevor es abstürzt. Danach kein "Android"-Begrüßungsbildschirm oder eine Boot-Animation. Ich glaube also nicht, dass ADB noch funktioniert ...

Antworten (3)

Es gibt ein paar Möglichkeiten, dies zu tun:

  • cat /proc/last_kmsg > /sdcard/last_kernel_message_log.txt
  • dmesg > /sdcard/kernel_boot_log.txt
  • Schließen Sie das USB-Kabel bei ausgeschaltetem Smartphone an. Geben Sie dann den Befehl adb logcatvon Ihrem Windows-Cmd- oder Linux-Terminal aus, es bleibt hängen und wartet darauf, dass das Gerät online geht. Schalten Sie jetzt das Smartphone ein. Der Logcat sollte dann anfangen zu scrollen.

Da Sie Interesse daran bekundet haben, herauszufinden, wie weit das eigene Telefon in der Startphase kommt, bevor es abstürzt , sollten diese Methoden hilfreich sein. Die Sache ist, dass Sie ziemlich schnell sein müssen, um das Protokoll des Kernels zu erhalten (die ersten beiden Methoden, die oben gezeigt werden).

Was ich tun würde, ist Folgendes, auf meiner Arch-Linux-Box, zwei Terminalfenster, eines für die adb logcat, das andere, um das Protokoll abzurufen, sobald logcat mit dem Scrollen beginnt!

Bearbeiten:

Beachten Sie, dass es Unterschiede bei der Verwendung von adbund gibt fastboot!

fastbootfunktioniert anders, es wird nur zum Flashen von Images in bestimmte Partitionen verwendet und ist stärker mit dem Bootloader-Prozess verbunden, dh es kann den Bootloader-Mechanismus verstehen. Es erfordert auch, dass:

  • unter Windows, 'Administrator'-Privileg zum Ausführen
  • unter Linux, 'root'-Privileg

Der Grund dafür ist, dass es bestimmte Ein-/Ausgaben der Hardware umgeht und daher nicht im adbProtokoll "spricht", sondern direkt mit dem Bootloader "spricht". Etwas, das als normaler Benutzer nicht möglich ist. Hier ist die Hilfe zur Verwendung von 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

Eine bekannte Verwendung von fastbootist zum Beispiel das Flashen eines Wiederherstellungsabbilds: sudo fastboot flash recovery recovery.img, eine andere ist das direkte Flashen eines RAW-Abbilds, sudo fastboot flash system system.img. Um mehr für den Fall der Kernel-Entwicklung zu verwenden fastboot boot new_kernel, lädt dies vorübergehend einen neuen Kernel herunter und bootet damit, ohne den eigenen Boot des Bootloaders zu berühren.

Es gibt auch eine Begrenzung für die Größe eines Rohbildes, das geflasht werden muss. Wenn ich Rohbild sage, beziehe ich mich auf eine Datei mit einer .imgErweiterung, das Bild darf 128 MB nicht überschreiten. ( Ich habe dies bei der Entwicklung von ics4blade herausgefunden, nachdem der Build abgeschlossen war, war die system.img 162 MB groß, und ich versuchte, sie zu flashen, aber Fastboot lehnte ab! Um die Einschränkung zu umgehen, musste ich eine CWM-flashfähige ZIP-Datei erstellen, um dies zu tun und herumzukommen es! )

Seien Sie vorsichtig und stellen Sie sicher, dass die Partition korrekt ist, und überprüfen Sie sie und überprüfen Sie sie erneut, wenn nötig, gehen Sie vom Computer weg, machen Sie eine Pause, kommen Sie wieder zurück und überprüfen Sie sie erneut, hier kann es schrecklich schief gehen. Flashen Sie die falsche Datei in die falsche Partition ... na ja, zuckt mit den Schultern

Dies ist eine großartige Idee, aber es gibt ein Problem....adb funktioniert nur, wenn der adb-Daemon das Gerät erkennen kann. Wenn das Telefon nicht erfolgreich hochgefahren ist, funktioniert adb nicht. Ein "Boot-Loop", wenn Sie logcat am meisten benötigen, würde also nicht funktionieren, und das ist es im Moment nicht, da ich es versuche. Das einzige, worauf Sie befehlsmäßig Zugriff haben, ist "fastboot". Was ist denn in diesem Fall eine Alternative?
@ 9exceptionThrower9 hat meine Antwort bearbeitet, um das Konzept von Fastboot einzubeziehen, und um in Ihrem Kommentar zu antworten, funktioniert Fastboot nicht :)
cacheDie einzige Alternative, die mir einfällt, ist, die und Partition per Fastboot zu löschen data- ich bin nicht verantwortlich für etwas Unerwünschtes, wenn Sie fortfahren! Und versuchen Sie, das ROM erneut über CWM zu flashen. Noch besser , vergessen Sie Fastboot und verwenden Sie CWM, um sowohl Cache als auch Daten zu löschen. Es hört sich so an, als ob der Bootloop auf einen gebohrten Cache oder Daten zurückzuführen ist ...
Interessanterweise, was genau haben Sie getan, um es zum Bootloop zu bringen - das ist eine entscheidende Frage, und Sie möchten wissen, welche Schritte Sie unternommen haben?
Ich habe den Android-Kernel (Maguro) für Galaxy Nexus modifiziert, insbesondere die Datei „socket.h“, um die INET-Registrierung mit dem Forschungsprojekt FINS meines Teams (das Internetprotokolle für Netzwerkforscher in den Benutzerbereich bringt) zu überschreiben. Nachdem ich diese Datei geändert hatte (nur wenige Zeilen), habe ich den Kernel erfolgreich neu kompiliert, diesen Kernel in den Android-Maguro-Build-Tree eingefügt, das Android-Systemabbild neu erstellt und dann die neuen Wiederherstellungs-, Boot-, System- und userdata.img-Dateien in die Datei geflasht Telefon...
...Telefon bleibt nach Anzeige des Batteriesymbols hängen und hängt eine Weile am Splashscreen mit dem weißen "Google"-Text darauf, dann stürzt es ab. Irgendwelche Vorschläge basierend auf dieser einzigartigen Situation?
Was es wert ist, ist es aus Erfahrung, wenn es aus dem Quellcode erstellt wird und es am Splash hängt, dass es normalerweise einige Partitionen nicht mounten kann. Ich würde sowohl die Standard- als auch die modifizierte Fstab vergleichen, um zu sehen, ob sich etwas geändert hat. Sie können wahrscheinlich adb in der init.rc aktivieren und das Protokoll vor dem Absturz abfangen. aber es könnte noch vieles mehr sein.
fastbooterfordert nicht immer Root-Zugriff, zumindest nicht auf einigen Linux-Distributionen. Sie könnten die Leute einfach anweisen, sudo oder administrator zu verwenden, wenn ihnen die Berechtigung verweigert wird.

Sie können LiveBoot verwenden. Es ist im Google Play Store. Es wird genau das tun, worum Sie bitten.

Was ist, wenn ich Bootloop bekomme? Gibt es eine Möglichkeit, dies mit einem USB-Kabel zu tun?
Ich weiß nicht, ob das das Logging-Tag verdient, aber es ist ein nettes Gimmick :) play.google.com/store/apps/details?id=eu.chainfire.liveboot

Sie können auf diesem Bildschirm in die Wiederherstellung wechseln, damit Sie auf einige Protokolldateien zugreifen können, auf die Sie nach dem Hochfahren des Telefons nicht zugreifen können. Was Sie versuchen zu beheben, wird in diesen Pre-Boot-Protokollen stehen.

Android-Startmeldungen zum Debuggen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v