Mögliches Duplikat:
Android-Startmeldungen zum Debuggen?
Bezogen auf diesen von mir erstellten Beitrag: Erzeugt der Android-Emulator eine Art Protokolldatei, auf die ich zugreifen kann, wenn er abstürzt?
Ich habe gesucht und versucht herauszufinden, ob es überhaupt eine Möglichkeit gibt, Debugging-Informationen oder Kernel-Meldungen von einem Android-Telefon zu erhalten, wenn es in einem Bootloop-Zustand hängen bleibt. Das bedeutet, dass das Telefon beim „Google“-Begrüßungsbildschirm hängen bleibt, dann abstürzt, dann dorthin geht und dann abstürzt.
Ich weiß, dass das Telefon mehrere Phasen des Bootloads hat, aber damit ich überhaupt herausfinden kann, warum mein Systemabbild/geänderter Kernel das Telefon zum Absturz bringt, muss ich zumindest wissen, wo das Telefon abstürzt?
Gibt es irgendeine Art von Protokoll, das der Android-Emulator vielleicht ausspuckt, das zeigt, dass er die Phasen des Bootens durchläuft: dh Bootloader der Stufe 1, Bootloader der Hauptstufe, geladener Kernel, Initialisierungsprozess, Zygote, Zygote initialisiert Dalvik VM, Ausführung des Systemservers, dann Boot abgeschlossen (wenn das ACTION_BOOT_COMPLETEFlag/Ereignis ausgelöst wird).
Ich habe versucht init.rc, Befehle an ein Boot-Protokoll zurückzugeben (aber es hat nicht funktioniert, obwohl ich nicht weiß, ob das Telefon es bis zu diesem Stadium schafft, alles, was ich habe, ist ein nutzloser Begrüßungsbildschirm). des ADB-Zeugs, aber natürlich funktioniert ADB nicht, wenn das Telefon keinen stabilen Zustand erreicht, der Linux- dmesgBefehl funktioniert nur, um anzuzeigen, dass das Telefon über USB angeschlossen ist, und die Android-Entwickler haben sich entschieden, dies zumindest nicht zu erklären mir, dass nur sie diese Art von Entwicklertools besitzen. Kann mir jemand eine Anleitung geben, was ich tun kann, um den Startvorgang zu debuggen? Es muss zumindest eine Art Protokoll geben, auf das Sie mit dem Emulator zugreifen können.
Mit anderen Worten, wie bekommt jemand irgendein Protokoll von seinem Telefon/Emulator, wenn er in einem Bootloop hängen bleibt?
Weitere Informationen, meine Kernel-Version, von der ich glaube, dass ich sie für meinen Telefon-Build heruntergeladen habe, ist die Linux-Kernel-Version 3.x (Standard-Kernel aus dem tunaOrdner und unter Verwendung des „omap“-Projekts) für Android Galaxy Nexus (maguro), wobei die Plattform ist Android 4.0.3 ICS.
Sie werden wissen, ob der Kernel hängen geblieben ist, das LED-Licht bleibt an und gehen Sie nicht weiter.
Was Ihre Frage betrifft, müssen Sie klarer und spezifischer sein, da wir es nicht wissen und da Sie zuvor eine ähnliche Frage gestellt haben. Sie haben nicht angegeben, um welches Gerät es sich handelt, um welche Android-Version es sich handelt, um welchen Kernel es sich handelt, all dies wird ausgelassen und spielt hier ein Ratespiel.
Viel zu viele Dinge hier, um darüber zu spekulieren.
Bearbeiten:
Dieses Bit bezieht sich auf das Debugging auf Kernel-Ebene.
Sie können nur feststellen , ob der Kernel überhaupt bootet, indem Sie ein USB-zu-Seriell-TTY-Kabel mit JTAG-Pinbelegungen auf einer kleinen Platine verwenden, die an der Rückseite des betreffenden Geräts befestigt/gelötet ist, und den seriellen Treiber haben in den Kernel kompiliert und behandelt die Konsole als TTY-Gerät und liest daraus über Minicom oder Hyperterminal, um die Startsequenz zu sehen.
Was Bootloops angeht,
Die Ursache für Boot-Loops liegt im ROM selbst, die Initialisierungssequenz stürzt irgendwo ab. Seien Sie nun vorsichtig :), der Kernel selbst kann auch aufgrund von fehlerhaften Treibern, Paniken und Neustarts selbst booten.
Die Frage ist also, was ist das? , Ist es der Kernel, der sich ständig neu startet, oder hat er diese Phase überschritten und mit dem Laden des ROM begonnen? Wenn es in der Phase des Ladens des ROM ist, dann stürzt etwas in der Initialisierung ab, wenn das ROM abstürzt, sendet es ein Signal zum Herunterfahren von SurfaceFlinger, AudioFlinger, adb-Daemon, MedaServices usw.
Was Sie tun können, ist Folgendes - in der init.rc, wo Sie Folgendes haben:
service console /system/bin/sh
console
disabled
user shell
Wechseln Sie disabledzu enabled, beim nächsten Mal wird Android Sie in die Konsole werfen, dh keine vertraute grafische Oberfläche.
Suchen Sie auch nach den Zeilen mit servicemanager, wenn der adbd-Daemon dort aufgeführt ist, nehmen Sie ihn heraus, da dies die Direktivenklausel ist criticalund onrestartdazu führt, dass Sie keine adb-Einrichtung haben!
9AusnahmeWerfer9