I've been experiencing a great deal of instability on my Verizon Galaxy S III, and I believe it's related to the WiFi driver, or at least something in the networking stack. I get daily full system crashes that cause soft reboots of the OS.
In order to trace to the root of the issue, I'd like to see historical crash data for the Android OS. Please note that I am NOT developing an app, and I do not want instruction on how to use LogCat to trace issues within an in-development app. I want to see the Android system crash logs, but I'm not sure where to look for them.
After ANR happens, you would find call stack of related process at /data/anr/traces.txt
After application crashes, you might find call stack of crashed application under /data/tombstones directory.
See Android: How to get kernel logs after kernel panic?
It looks like /data/dontpanic/ should contain some "apanic" files, but only if the kernel's apanic support is enabled, and it worked. (I haven't seen anything there in my case, but maybe you'll be luckier than I ...)
crash report can be found at default path: /data/anr/
some manufacture place in custom path like: /data/system/ckerror
use cmd: adb pull /data/anr "dest path"
example:
in windows cmd prompt:
adb pull /data/anr c:\trace
The document states that
Android stores trace information when it experiences an ANR. On older OS releases, there's >a single /data/anr/traces.txt file on the device.
On newer OS releases, there are multiple >/data/anr/anr_* files. You can access ANR traces from a device or emulator by using >Android Debug Bridge (adb) as root:
adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>
Usually the every crash is stored in traces.txt file under /data/anr/ folder of internal storage. Try checking this file.
I found a file call crash.txt inside the directory /data/Logging which seems to contain brief stack-traces from the last several crashes that occurred on the device.
Related
I am attempting to mount an android device on a machine running Windows 10 for the purpose of accessing files via a Java application. I am aware that the consensus is one should use a WebDav or FTP server, but I would like to avoid this if possible. I have spent many weeks researching this and have finally decided to reach out to the brilliant minds of stack overflow.
To mount the MTP device we need a file system library similar to fuse for Unix. For windows the two obvious choices are:
dokany
winfsp
As far as I understand there are two main APIs/libraries to access MTP devices:
libmtp
WPD
I have managed to compile libmtp for windows using msys2/Mingw64.
The way I see it I should use an application like mtpmount or try to port a linux application like simple-mtpfs using a file-system library like dokany instead of fuse.
However, when I try to use mtp-mount (which uses the WPD API) it doesn't list any devices, and when I test libMTP using the provided examples I get errors like this:
libusb_open() failed!: No error
libmtp version: 1.1.18
Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is a Samsung Galaxy models (MTP).
Found 1 device(s):
Samsung: Galaxy models (MTP) (04e8:6860) # bus 1, dev 10
Attempting to connect device(s)
OK.
LIBMTP PANIC: Unable to initialize device
Unable to open raw device 0
I don't know how to proceed. Any help would be greatly appreciated.
Update
I got libmtp working using libusbk-dev-kit. Specifically, I used the libusbK-inf-wizard, to create drivers for my device. I tested the libusbk driver and the WinUSB driver and found they both solve my problem.
Also, I build mtpmount from sources and found it to work as well.
I found your question while looking for something very similar: how to talk with MTP (a Garmin Alpha 200i handheld GPS unit - not a phone) using Python 3 on Windows 10.
Glad to see you found a solution! I found a partial solution for my issue using your leads (Specifically, mtpmount), and am wondering if it provides another alternate solution for your issue.
I'm also wondering if you've discovered any more about mtpmount since you found your solution.
Based on your lead, I went to the mtpmount link. I was able to get a full solution for the windows command line by 1) downloading and running the latest .msi for dokany, making sure to select all the components for installation, then 2) downloading the latest .exe (it's not an installer - it's the actual mtpmount executable) for mtpmount. That's about as smooth of an installation process as one could hope for in this realm! Hats off to the developers on both of those projects!
The only differences vs the mtpmount docs I found were that 1) the executable name in the docs didn't exactly match the executable name from the downloads - certainly not a big deal, and 2) the pound sign has to be in double quotes - at least that was the case in powershell, and 3) a good thing: you can specify the drive letter in the same ID# syntax:
PS C:\Users\caver\Downloads> .\mtpmount-x64.exe list available
This is mtpmount, version 19.8.0 from commit 43033d6
This program comes with NO WARRANTY. Usage only at your own risk.
Available Connections and Storage Media:
Connection Elements: Contains 1 storages that can be mounted
|-- Storage E: [ID #0]
Connection My Passport: Contains 1 storages that can be mounted
|-- Storage F: [ID #1]
Connection Alpha 200i: Contains 2 storages that can be mounted
|-- Storage Internal Storage [ID #3]
|-- Storage Memory Card [ID #4]
Use mount command to make one of them a windows removable drive
PS C:\Users\caver\Downloads> .\mtpmount-x64.exe mount "#3" h:
This is mtpmount, version 19.8.0 from commit 43033d6
This program comes with NO WARRANTY. Usage only at your own risk.
Drive H:\ is now Alpha 200i\Internal Storage. Don't forget to unmount the drive (using unmount command) before disconnecting your device
PS C:\Users\caver\Downloads>
Then you do your drive access work. Then you run this to dismount:
PS C:\Users\caver\Downloads> .\mtpmount-x64.exe unmount "#3"
This is mtpmount, version 19.8.0 from commit 43033d6
This program comes with NO WARRANTY. Usage only at your own risk.
Alpha 200i\Internal Storage has been unmounted successfully.
Syncing Alpha 200i. DO NOT UNPLUG THIS DEVICE YET!
the terminal pauses for about 5 seconds here
Cache OK
All content synced to Alpha 200i. You may now unplug this device.
PS C:\Users\caver\Downloads>
My questions about this:
does dokany affect the rest of your file system access, by running all file system operations through its proxy for all drives? If so, does that slow things down or add another possible route for file system corruption in the event of an undiscovered bug in dokany or such?
we work with the Garmin GPS units in an environment where unplug timing can't really be reliably controlled. In other words, we really need to be able to unplug immediately after the transfer is done, without waiting for the pregnant pause during the unmount process. What's the word on hot-unplugging of a MTP device that's mounted using mtpmount? Unplugging without running 'mtpmount unmount', and also, unplugging during the pregnant pause? Of those two options, seems like it would be safer to just not run unmount - you get the impression that the 5-second sync would be a really bad time to unplug... For USB Mass Storage Devices, I know it's always recommended to properly eject the device from Windows first, before physically unplugging, but we've never experienced a problem due to hot-unplugging of USB Mass Storage Mode Garmin GPSes.
have you made this all into a turnkey installer solution, i.e. one overall installer that installs dokany then installs mtpmount then also installs the rest of your application? I am not familiar with installers like Nullsoft or such and I definitely plan to RTFM there, but just wondering if you've encountered any specific hiccups on these lines.
Thanks and congrats on getting it working!
I met a weird issue when I tried to search some logs during emulator booting.
When I create an emulator, the adb device started with "offline" first, then I type
adb logcat -v time | tee log1.txt
and adb will keep "wait-for-device" until the adb became online.
Then when the emulator boots up, I type adb logcat -v time | tee log2.txt again except the destination of the log file.
Now, I use vimdiff log1.txt log2.txt to compare these two logs and found log1 missed many logs as Log_Diff
I have no idea why some logs in log1.txt will missed.
Any ideas?
P.S. I am using Android 5.1-64bit Emulator in sdk.
After some research, finally I found the root cause in Android log daemon.
The main problem is the LogBufferElement is using a CLOCK_MONOTONIC timestamp as the sorting index.
When the timestamp of the multiple LogBufferElement are the same, LogReader may only dump the last entry. That's why some logs seem being lost.
AOSP Android 5.1 still had this issue, but Android 6.0 had fixed it.
You can refer to this patch.
Btw, I also did some modification for this patch.
The main reason is Android 6.0 supports the C++ 11 atomic std libs, but Android 5.1 is not yet. Some the atomic APIs need to roll back. (e.g. atomic_fetch_add_explicit())
I am writing an app to capture tombstones logs.
How to get the default location of tombstones logs in any Android device?
Even if the tombstones logs are not available yet, where do they get stored when any crash or something happen?
AFAIK these logs get saved in '/data/tombstones/' but is this path universal across all devices?
Do I need to read some property from "adb shell getprop" etc in the code dynamically?
If you haven't rooted you device, you should use bugreport adb command:
adb bugreport ./bugreport.zip
Inside the zip you will have everything you need to analyse.
In order to disassembly the tombstone:
get the AOSP source code and follow the instructions of the https://source.android.com/setup/start until the lunch command.
Run the command (replace tombstone_01 by the interest file):
disassemble_tombstone.py ./bugreport/FS/data/tombstones/tombstone_01
More tools do debug the bugreport.zip in https://source.android.com/devices/tech/debug
Not to say this can't change in the future (and of course, being open source any vendor could modify this if they choose), but tombstone files are written by debuggerd in the engrave_tombstone() function implemented in tombstone.cpp (formerly tombstone.c):
https://android.googlesource.com/platform/system/core/+/master/debuggerd/tombstone.cpp
This uses a hardcoded path using the macro:
#define TOMBSTONE_DIR "/data/tombstones"
Even the Java side of Android uses the hardcoded path:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/com/android/server/BootReceiver.java
And it appears that using /data/tombstones goes at least back to Android 1.6 Donut's debuggerd
You may run below command at "/" directory from "adb shell" to locate tombstones location for a specific device.
find . |grep tombs
The path is NOT universal, in fact that isn't one I've seen in a long time. Generally when a tombstone occurs you get a line in logcat saying where the logs are. Otherwise you need to poke around.
I'm in trouble with my android device in which log folder under /dev is unreachable or maybe even does not exists.
$ pwd
pwd
/dev
$ cd log
cd log
cd: can't cd to log
$
So LogCat is out-of-service and I cannot view device's stdout or stderr logs in DDMS.
I googled a little bit and tried to find some information for about this problem:
http://developer.android.com/guide/developing/tools/adb.html#alternativebuffers
Viewing stdout and stderr topic seemed to be useful but this thread says it is unsupported :
Why is redirecting stdout/stderr on android not working?
Here is another one having the same problem:
"Unable to open log device '/dev/log/main': No such file or directory"
I found a temporary solution to dump my logs in a file on device manually but as usual I cannot monitor system just my application logs.
Is there any solution you can suggest? Any way to redirect stdout and stderr logs to files,console etc.?
Any kind of help will be appreciated.
Solution:
On call screen
type *#*#2846579#*#*
opens system management menu
Project menu -> background settings -> Log setting
Log level setting -> VERBOSE
Log switch -> LOG on
Dump and Log -> Checked all the boxes
Restart device.
Thats all.
What device is this? If it ships with Market, it must pass the CDD, and that includes having the development tools needed for app development which includes logcat support (though this just means the logcat command, technically the implementation could be different). For such a device the manufacturer must supply an update to make it compatible.
If it is not a compatible device, all bets are off, and you will just need to get help from the manufacturers or any hackers who are working with the device.
RunO NesrE - I finally found the solution to this.
There is a recent post on the xda-developers forum for a different Huawei phone with the same problem and it has a fix.
http://forum.xda-developers.com/showpost.php?p=17774398&postcount=93
It worked a treat on my Huawei Sonic (U8650).
I know that the boot up log can be obtained by pulling out contents of kmsg or dmesg through ADB.
But I'm not aware of how to retrieve the shutdown logs in Android as there's no /var folder in Android (place where most desktop linux distros generally store their shutdown logs).
So how can I obtain the shutdown logs in Android?
Look in some locations such as these:
/proc/last_kmsg
/data/tombstones/
/data/dontpanic/
/data/system/dropbox/
(This list isn't strictly kernel logs, including framework and application logs too, which are also sometimes of interest)
One work around I found for collecting shutdown logs in Android is to run adb pull /proc/kmsg C:\Logs.txt on the host PC and then switch off the device. You will get the logs till the USB communication between the host and the device snaps! I know this is only one case out of the numerous shutdown scenarios but I haven't found satisfactory answers for other cases!
TL;DR:
Run command through adb that copies logcat and proc/kmsg to a file and keep it running even when adb disconnects with nohup, disown or setsid. Probably needs busybox, needs root and adb root, too.
setsid cat proc/kmsg > /sdcard/kmsg.txt &
and
logcat -v long -f /sdcard/logcat.txt (somehow only works without setsid)
Or add normal copy commands to some startup script.
/TL;DR
You can constantly copy proc/kmsg and logcat to a file on your android device or a microSD card to get the logs even after adb disconnects.
You need root access and adb root access for this to work. For the latter, use the setting in the developer options if you have a custom rom or the adbd insecure app.
After using adb shell to get your android shell, type su to get superuser access.
Then you not only need to put an ampersand (&) after the command but also make sure that the command keeps running after adb disconnects. That is done by nohup, disown or setsid (see here for usage).
If it doesn't work because you don't have these commands, you need to install busybox.
See my question here.
See here for how to get logcat and kernel logs and print it to some file or merge it.
See developer.android.com/tools/help/logcat.html for parameters for the logcat command.
In the end you could have a command like setsid cat proc/kmsg > /sdcard/kmsg.txt & for the kernel messages.
For logcat you could have one of the following commands: logcat -v long -f /sdcard/logcat.txt or logcat -v long > /sdcard/logcat.txt
I don't know why, but sometimes it didn't work with setsid and just didn't copy continuously but stopped shortly after executing the command. In these situations, it also showed up when entering jobs, which it didn't otherwise. Then it just worked without setsid, it stayed alive after disconnecting and reconnecting. I guess you must just try when the file does keep getting larger. If someone figured out why it is behaving like it is... let me know and I'll edit the answer.
Probably adding the commands to a startup script could be a solution for some, too.
Hope this helps.
fightcookie
Newer phones do NOT use any of these locations so if you're reading this article then as of now
The kernel crash logs are now in /sys/fs/pstore instead of /proc/last_kmsg
I was looking for the same thing, and finally, I found the answer!
In android 8 all logs are located in \data\log\android_logs\... including apps and kernel logs. Kernel logs are called kmsgcat-log_timestamp_.gz
edit: Although this is a very old thread, I think the answer might be helpful.