Android 4.1 és újabb

Az előnyben részesített módszer az SDK letöltése és a adb logcat (a ” fejlesztői opciók ” aktiválásához szükséges az eszközön).

Vannak elérhető alkalmazások a teljes rendszernapló megtekintése, azonban ezek csak gyökérzetű eszközökön működnek, vagy kézi parancs kiadására van szükség a adb útján, hogy működjenek. További információkért lásd: ezt a kérdést.

Android 4.0 és régebbi

Vagy letöltheti a SDK , és használja a adb logcat alkalmazást, vagy szerezzen be Logcat Extrem Google Play Áruház, amely közvetlenül a telefonján jeleníti meg a naplót.

Megjegyzések

• Alternatív megoldásként használhatja a Terminal Emulator parancsot a logcat > /sdcard/log.txt” a napló folyamatos írásához az SD-fájlba Kártya. Ez segíthet a véletlenszerű újraindítással kapcsolatos problémák kitalálásában.
• Jó pont. Egyes telefonok általában triviális információkkal töltik a naplót, ezért ha minimalizálni kívánja a fájlméretet és az átmenő adatokat, nézze meg a ” napló kimenet szűrése szakaszt ” itt: developer.android.com/guide/developing/tools/adb.html#logcat
• A LogCat alkalmazások nem ‘ nem működik anymory a JellyBean-nal. A Google megváltoztatta az Android API-t, az alkalmazások nem ‘ nem rendelkeznek többé engedéllyel a sajátjuktól eltérő alkalmazások naplóinak olvasására.
• Létrehoztam egy egyszerű segédprogramot a gyűjtéshez. naplók PC-ről: gist.github.com/hrj/5983971
• A Logcat Extreme a szép alkalmazás a napló megtekintéséhez

Naplófájl helyei

Számos könyvtár található, ahol a naplók (beleértve az összeomlásokból származóakat is) megjelenhet – nem mindegyik szabványosított (azaz egyesek ROM-specifikusak lehetnek).

• /data/anr: Úgy tűnik, hogy néhány nyomfájl ideér (Dalvik veremnyomokat ír ide az ANR-re, azaz “Application Not Responding” más néven “Force-Close”; lásd például a naplórészleteket itt )

i Úgy tűnik, hogy a /data/dontpanic szabványos hely (AOSP), és tartalmaz néhány összeomlási naplót, beleértve a nyomokat is (lásd pl. viaForensics és Szent ackOverflow )

• /data/kernelpanics egy másik hely – Android-eszközeimen nem volt “kernelpánik”, ott még nem láttam tartalmat.
• a /data/panic/panic_daemon.config más konfigurált helyekre mutathat – a 2. Droidomon megemlíti a /sdcard/panic_data/
• az említett Droid 2 /data/panicreports könyvtárral is rendelkezik (itt üres)
• /data/tombstones több tombstone_nn fájlok (nn sorozatszámmal, minden új fájl növekedésével). Mivel a sírköveket a halottak számára helyezik el, itt történik a “véletlenül elhunyt folyamatok” (azaz összeomlott) esetében – és ez az úgynevezett “core dump” a Linux / Unix rendszereken. Azonban nem minden alkalmazás hoz létre sírköveket; ezt a fejlesztőnek kifejezetten engedélyeznie kell (lásd: Az Android Core dumpok hibakeresése ).

Lehet, hogy van még néhány hely, amely megszökött tőlem; de mivel a legtöbb naplózást tmpfs készüléken hajtják végre, ezek az adatok újraindításkor elvesznek, és nem felelnek meg az OP-k kérdésének.

A terminálhoz használandó naplóparancsok alkalmazás (vagy adb)

Több parancs rengeteg információhoz juthat. Legtöbbjük számára azt javasoljuk, hogy irányítsák át őket egy fájlba (> filename.ext), vagy húzzák át őket egy szűrőn (| grep search-for-this ):

Kernel napló

A következő root nélkül működik:

$ dmesg <6>[82839.126586] PM: Syncing filesystems ... done. <7>[82839.189056] PM: Preparing system for mem sleep <4>[82839.189361] Freezing user space processes ... (elapsed 0.05 seconds) done. <4>[82839.240661] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. <snip> 

Logcat

Itt pl adja meg, hogy melyik terület érdekli – rádió, események …

# logcat -b events I/am_create_service( 3457): [1085416560,nitro.phonestats/.widget.WidgetProvider4x1$WidgetUpdateService4x1,,3721] I/am_destroy_service( 3457): [1085416560,nitro.phonestats/.widget.WidgetProvider4x1$WidgetUpdateService4x1,3721] I/notification_cancel( 3457): [nitro.phonestats,4,0] <snip> 

Eszközinformációk beszerzése

És rengeteg: Eszköz sajátosságok, számlainformációk, szolgáltatások …

$ dumpsys Currently running services: LocationProxyService SurfaceFlinger accessibility account activity <snip> DUMP OF SERVICE account: Accounts: 1 Account {[email protected], type=com.google} <snip> $ dumpstate ======================================================== == dumpstate: 2012-08-18 23:39:53 ======================================================== Build: Gingerbread GWK74 - CyanogenMilestone2 Bootloader: 0x0000 Radio: unknown <snip> ------ MEMORY INFO (/proc/meminfo) ------ MemTotal: 487344 kB MemFree: 10436 kB <snip> 

Többfunkciós készülék

Készítsen egy nagy labdát minden mellett, a logcattól a dumpstateig:

$ bugreport > /mnt/sdcard/bugreport.txt 

Biztos vagyok benne, hogy valóban át akarod irányítani az utolsó parancsot … xD

Valami a jogosultságokról

PS: Természetesen ezekhez az információkhoz való hozzáférés root-t igényelhet, mivel a legtöbb forrás a belső tárhelyen található.

Megjegyzések

• Az adb logcat parancsok további betekintéséhez lásd itt .
• Vagy csak ellenőrizze a naplózási tag-wiki @ tesztet – amely még több hivatkozással rendelkezik 🙂
• A ” Az Android Core dumpok hibakeresése ” halott, kaphatunk-e alternatívát?
• @Spidey there ‘ s mindig Archive.ORG ehhez a problémához (a hivatkozás egy működő példányra megy t itt).
• Bárki más számára, mint én, aki még nem ismerte az Android alkalmazást, a fenti parancsok futtatásához először futtatnia kell az $ adb shell parancsot, hogy csatlakozzon az eszközhöz. terminálon keresztül. (Természetesen ellenőrizze, hogy eszköze csatlakozik-e a számítógépéhez, és hogy be van-e kapcsolva az USB hibakeresés.)

Megállapította, hogy a CatLog valamivel jobban megjeleníti az Android naplót, mint az aLogcat. A adb logcat mellett ezt használom.

Megjegyzések

• Lásd a fenti megjegyzésemet, a LogCat alkalmazásokkal kapcsolatban.
• Frissítettem a kérdést. Felhívjuk figyelmét, hogy a relatív helyzetinformációk (pl. ” fent ” ) könnyen elavulttá válhat, mivel a válaszok sorrendje az idő függvényében változhat.

A módszer root nélkül, amely még az új Android verzióknál is használható:

Előfeltételek:

• Linux, Windows vagy Mac
• USB-kábel az eszközhöz
• Android-eszköz

Utasítások:

1. Telepítse az eszközillesztőt az adb használatához. Mindent megtalál, amire szüksége van: itt
2. Töltse le az operációs rendszerhez futtatható adb futtatható fájlt. Ez az Android SDK része, de előfordulhat, hogy az adb futtatható fájlt külön is megtalálja.
3. Csatlakoztassa androidos eszközét.
4. Engedélyezze a fejlesztői beállításokat .
5. Engedélyezze az USB hibakeresést.
6. Nyisson meg egy parancssort (windows) vagy terminált (linux / mac). Hogyan kell csinálni: Windows rendszeren: Windows + r> írja be a “cmd” szót (idézőjelek nélkül)> kattintson az Enter | gombra Linuxon: Nem tudja, hogyan kell megnyitni egy terminált? LOL | Mac: Írja be a Terminal parancsot a Spotlightba, és nyissa meg
7. CD-t a könyvtárba, ahol a Az adb futtatható fájl található. Windows rendszeren: Lépjen abba a könyvtárba, ahová az adb futtatható fájlt letöltötte, a Shift + Jobb klikk és válassza az “Open Console” (vagy hasonló) elemet. Linux / Mac rendszeren: Kattintson jobb gombbal a könyvtárba, és válassza a “Terminál megnyitása itt” lehetőséget. (vagy egyszerűen CD-t a könyvtárba)
8. Írja be a cmd / terminált: adb devices az eszköz megfelelő csatlakoztatásának ellenőrzéséhez.
9. Ha az eszköz megfelelően van kiválasztva, írja be a adb logcat parancsot a hatalmas és varázslatos logcat, vagyis a stacktrace megjelenítéséhez.
10. Reprodukálja hibáját (vagy bármi mást) az eszközén.
11. Rögtön ezt követően illessze be a teljes cmd / terminál ablakot egy olyan beillesztési szolgáltatásba, mint a http://pastebin.com/ és küldje el nekünk.

(Többnyire a Leandrosból másolva )

A következő helyen található: /sdcard/bugreports.

Megjegyzések

• I ‘ még soha nem volt ilyen mappám a telefonomon … ez egy gyártó vagy eszköz sajátja?
• id = “453d0aa8c5”>