我知道 Boot 日志可以通过从ADB中取出kmsg或dmesg的内容来获得。但是我不知道如何在Android中检索关机日志,因为Android中没有/var文件夹(大多数桌面Linux发行版通常存储关机日志的地方)。那么如何才能获得Android中的关机日志呢?
ADB
kmsg
dmesg
/var
mcdcgff01#
看看一些地方,如这些:
/proc/last_kmsg /data/tombstones/ /data/dontpanic/ /data/system/dropbox/
字符串(This列表并不是严格意义上的内核日志,也包括框架和应用程序日志,这些日志有时也会引起人们的兴趣)
kjthegm62#
TL;DR:
通过adb运行命令,将logcat和proc/kmsg复制到一个文件中,并使用nohup、disown或setsid使其即使在adb断开连接时仍保持运行。可能还需要busybox、root和adb root。setsid cat proc/kmsg > /sdcard/kmsg.txt &个和logcat -v long -f /sdcard/logcat.txt(不知何故,只有在没有setsid的情况下才能工作)或者将普通的复制命令添加到一些启动脚本中。
adb
proc/kmsg
nohup
disown
setsid
setsid cat proc/kmsg > /sdcard/kmsg.txt &
logcat -v long -f /sdcard/logcat.txt
/TL;DR
你可以不断地将proc/kmsg和logcat复制到你的安卓设备或microSD卡上的文件中,即使在adb断开连接后也可以获得日志。你需要root权限和adb root权限才能工作。对于后者,如果你有一个自定义的rom或adbdx 1 e0f1x,请使用开发者选项中的设置。使用adb shell获取android shell后,键入su获取超级用户访问权限。然后,您不仅需要在命令后放置一个“and”符号(&),而且还需要确保在adb断开连接后命令仍在运行。这可以通过nohup、disown或setsid来完成(请参阅this superuser question了解用法)。如果因为没有这些命令而无法运行,则需要安装busybox。看我的unix stackexchange question。有关如何获取logcat和内核日志并将其打印到某个文件或合并日志的信息,请参阅this stackoverflow question。有关logcat命令的参数,请参阅https://developer.android.com/tools/logcat。最后,您可以使用类似于setsid cat proc/kmsg > /sdcard/kmsg.txt &的命令来处理内核消息。对于logcat,可以使用以下命令之一:logcat -v long -f /sdcard/logcat.txt或logcat -v long > /sdcard/logcat.txt不知道为什么,有时候setsid不好用,就是不连续拷贝,执行完命令就停了,这种情况下,输入jobs也会出现,否则就不出现了,然后没有setsid就好用了,它在断开连接并重新连接后仍保持活动状态。我想您必须在文件确实不断变大时尝试。如果有人发现了它的行为为何如此...请告诉我,我将编辑答案对于某些人来说,将命令添加到启动脚本可能也是一种解决方案。希望这对你有帮助。
logcat
adb shell
su
&
logcat -v long > /sdcard/logcat.txt
jobs
dojqjjoe3#
我发现在Android中收集关机日志的一个方法是在主机PC上运行adb pull /proc/kmsg C:\Logs.txt,然后关闭设备。你会得到日志,直到主机和设备之间的USB通信快照!我知道这只是众多关机场景中的一种情况,但我还没有找到其他情况的满意答案!
adb pull /proc/kmsg C:\Logs.txt
dfddblmv4#
较新的手机不使用任何这些位置,所以如果你阅读这篇文章,那么截至目前内核崩溃日志现在位于/sys/fs/pstore而不是/proc/last_kmsg中
rhfm7lfc5#
getprop还有sys. Boot .reason.last,其中包含上次重新启动Android设备的基本细节:
adb shell getprop | grep -A3 boot.reason [persist.sys.boot.reason]: [] [persist.sys.boot.reason.history]: [watchdog,1692290965 reboot,userrequested,1692249163 watchdog,1691516754 watchdog,1691078769] -- [sys.boot.reason]: [watchdog] [sys.boot.reason.last]: [watchdog] [sys.boot_completed]: [1] [sys.bootstat.first_boot_completed]: [1] [sys.fuse.transcode_enabled]: [true]
字符串
4ioopgfo6#
我也在寻找同样的东西,最后,我找到了答案!在Android 8中,所有日志都位于\data\log\android_logs\...中,包括应用程序和内核日志。内核日志称为kmsgcat-log_timestamp_.gz编辑:虽然这是一个非常古老的线程,我认为答案可能是有帮助的。
\data\log\android_logs\...
kmsgcat-log_timestamp_.gz
6条答案
按热度按时间mcdcgff01#
看看一些地方,如这些:
字符串
(This列表并不是严格意义上的内核日志,也包括框架和应用程序日志,这些日志有时也会引起人们的兴趣)
kjthegm62#
TL;DR:
通过
adb
运行命令,将logcat和proc/kmsg
复制到一个文件中,并使用nohup
、disown
或setsid
使其即使在adb断开连接时仍保持运行。可能还需要busybox、root和adb root。setsid cat proc/kmsg > /sdcard/kmsg.txt &
个和
logcat -v long -f /sdcard/logcat.txt
(不知何故,只有在没有setsid
的情况下才能工作)或者将普通的复制命令添加到一些启动脚本中。
/TL;DR
你可以不断地将
proc/kmsg
和logcat
复制到你的安卓设备或microSD卡上的文件中,即使在adb断开连接后也可以获得日志。你需要root权限和adb root权限才能工作。对于后者,如果你有一个自定义的rom或adbdx 1 e0f1x,请使用开发者选项中的设置。
使用
adb shell
获取android shell后,键入su
获取超级用户访问权限。然后,您不仅需要在命令后放置一个“and”符号(
&
),而且还需要确保在adb断开连接后命令仍在运行。这可以通过nohup
、disown
或setsid
来完成(请参阅this superuser question了解用法)。如果因为没有这些命令而无法运行,则需要安装busybox。
看我的unix stackexchange question。
有关如何获取logcat和内核日志并将其打印到某个文件或合并日志的信息,请参阅this stackoverflow question。有关logcat命令的参数,请参阅https://developer.android.com/tools/logcat。
最后,您可以使用类似于
setsid cat proc/kmsg > /sdcard/kmsg.txt &
的命令来处理内核消息。对于logcat,可以使用以下命令之一:
logcat -v long -f /sdcard/logcat.txt
或logcat -v long > /sdcard/logcat.txt
不知道为什么,有时候
setsid
不好用,就是不连续拷贝,执行完命令就停了,这种情况下,输入jobs
也会出现,否则就不出现了,然后没有setsid
就好用了,它在断开连接并重新连接后仍保持活动状态。我想您必须在文件确实不断变大时尝试。如果有人发现了它的行为为何如此...请告诉我,我将编辑答案对于某些人来说,将命令添加到启动脚本可能也是一种解决方案。
希望这对你有帮助。
dojqjjoe3#
我发现在Android中收集关机日志的一个方法是在主机PC上运行
adb pull /proc/kmsg C:\Logs.txt
,然后关闭设备。你会得到日志,直到主机和设备之间的USB通信快照!我知道这只是众多关机场景中的一种情况,但我还没有找到其他情况的满意答案!dfddblmv4#
较新的手机不使用任何这些位置,所以如果你阅读这篇文章,那么截至目前
内核崩溃日志现在位于/sys/fs/pstore而不是/proc/last_kmsg中
rhfm7lfc5#
getprop还有sys. Boot .reason.last,其中包含上次重新启动Android设备的基本细节:
字符串
4ioopgfo6#
我也在寻找同样的东西,最后,我找到了答案!
在Android 8中,所有日志都位于
\data\log\android_logs\...
中,包括应用程序和内核日志。内核日志称为kmsgcat-log_timestamp_.gz
编辑:虽然这是一个非常古老的线程,我认为答案可能是有帮助的。