There are several directories where logs (including those from crashes) might appear -- not all of them are standardized (i.e. some may be ROM-specific).
/data/anr: Some trace files seem to get here (Dalvik writes stack traces here on ANR, i.e. "Application Not Responding" aka "Force-Close"; see e.g. log excerpts here)
Does anyone have any suggestions as to how I can see the full text of the errors which are occurring when trying to sync my K9 folders?
It seems that there is no way to see these log messages on the device without root access, but if you do have root access, there are a couple of options, either grant the required permissions to aLogcat or consider using a ...
/data/system/dropbox is not part of the cloud storage provider "Dropbox". It is part of the Android OS DropBoxManager (not related at all to "Dropbox", just happen to have the same name).
This puts data from application crashes and kernel logs and such in this log directory. I know the market app uses this directory (See #4) as well, probably to report ...
I think you have caught yourself out, in short, nothing you can do!
Have a look at this source that explains why, specifically in this section:
System Partition and Safe Mode
The system partition contains Android's kernel as well as the
operating system libraries, application runtime, application
framework, and applications. This partition is set to ...
No, for security reasons it is not possible to access android log files on the Nexus 7 (or any other device running Jelly Bean or higher) without root access. Google changed that with Jelly Bean.
I'd suggest you wait until logcat readers like aLogCat and such get fixed (i.e. they will require root access to show all logs then).
The only log I remember, that contains installation success/failure info is the one that can be accessed via ADB (android debug bridge). The command is:
But you might not have the Android debugging tools installed, so an easy way of looking at the logcat is to install aLogcat from market. Because that log is a memory buffer (I learned it form ...
The historical record is stored in memory, and is not directly available in the service API (as far as I'm aware). The Settings activity accesses it through the NotificationService.getHistoricalNotifications() method, but this method is not exposed in the NotificationManager API (only getActiveNotifications() is). You might be able to do it through ...
Not the best answer but maybe the information will be some what useful.
The only method I'm aware of that contains a log produced by the system after a reboot is /proc/last_kmsg.
Whether or not the kernel keeps this log file after a reboot, depends on settings provided during kernel compilation.
My experience has shown that some stock devices (HTC) have ...
If you want sane information, I recommend sane commands :) (no offense meant, just kidding). So the question should read:
How to obtain log information from an Android device?
And now we are on the better side. There are multiple approaches which can be used:
utilize apps to display (color-coded) log information
utilize ADB (part of the Android SDK) to ...
What is a LogCat?
A "LogCat" is for debugging applications / Android system. When applications / Android crash the output the "explanation" for the crash, the Exception Stacktrace, to a Log. This log can be saved and help developers to fix the crash.
What is it supposed to do?
It will help to solve your questions, if your asked for a LogCat it is always ...
I googled the file name and found this post on XDA:
i'm still having the storage is running out error from 3.8. I found
out it was caused by the signal lost issue because inside the log
folder located in data folder, it will generate many dumpstate ril
reset by........xxx..once my signal is lost. so, i'm wondering what's
the best worldwide modem ...
Logcat won't be much help here, as it only lasts back a limited time (it uses a ring buffer with a fixed size, so older entries get overwritten with new ones). Instead, better focus on the package manager:
adb shell "pm list packages -u -3"
gives you a list of all apps you have installed (the -3 restricts it to apps that didn't come pre-installed – ...
Its easier, what you can do is this, from the cmd window, adb logcat > my_logcat.txt and just let it run, now, you can pause, resume the scrolling, in that cmd window, same keystrokes for Linux terminal, IIRC, now launch an editor and open the file 'my_logcat.txt' and there the results will show, had there not being a pause/resume in the cmd ...
Not very active if you use apps like aLogcat. The permissions system regarding to logs was changed with Jelly Bean: The permission to read logs "READ_LOGS" is now systemOrSignature, which means that an app that is not signed with the ROM/system key can only view its own log. You can still view the full android log with adb logcat from the SDK.
I think that ...
Go to settings and turn on bluetooth. Click menu button and you will see the option Show received files. Alternatively every files sent via bluetooth will be stored in a folder named bluetooth in storage (if the files are not moved).
If nothing can be retrieved from logcat you are probably running into a kernel panic.
You could check via adb the output of: dmesg
Some devices also have a kernel feature where, on critical errors, the last received kernel message can be read from /proc/last_kmsg
Maybe this will give you some hints whats going wrong.
If not you could stream the full ...
You will know if the kernel has hung, the led light stays on and not go further.
As for your question, you need to be more clearer and specific as we do not know and since you posted a similar question before. You have not stated, what device is it, what android version is it, what kernel is it, all those are left out and thusly playing a guessing game ...
For developers (or other interested parties) who need to parse this raw file, here are some resources:
logcat (the program that can output binary logs), it calls android_logger_list_read() to gather log entries: https://android.googlesource.com/platform/system/core/+/master/logcat/logcat.cpp
Information about Android Logging in general: http://elinux.org/...
Ok, found the answer here
When you start the update process it loads that screen with the android character and the yellow progress bar, as soon as that screen shows up press both vol up and vol down at the same time and it will switch to verbose mode where it will show each step of the install process. When it fails it will typically display a directory ...
The files (if they are considered as such) to which logs are written by the device are not in /system but in /dev/log.
These "files" are reset at every boot, so unless the device you have has a boot-time script that automatically saves logs to a file in, say, /sdcard, there is sadly no way to retrieve the logs you want while in recovery.
Using apps: Current Activity and some similar apps will display the info in the form of floating texts above the screen content.
Using adb (from your PC): dumpsys window windows | grep -E 'mCurrentFocus', or dumpsys activity top (for full info meant for developers)
After some searching around, it turns out ConnectivityExt is a proprietary Qualcomm file (source - you can see that it is included in the proprietary-files.txt in LineageOS), related to the Qualcomm package com.qualcomm.qti.tetherstatsextension.tetherstatsreporting. I found some code for this here, line 107 onwards. As it seems to be about ...
Apart from traditional Discretionary Access Control (DAC), - that makes use of *NIX owner/group/mode of processes/files to allow/deny access - Android implements several other access control mechanisms of Linux kernel to make itself more secure, such as Seccomp Filter was implemented in Oreo.
While DAC is allowed by-default, SELinux (a ...
Back in 2012, /proc/last_kmsg (1) used to be a dump of kernel console messages, exported after reboots by Android's ram_console functionality (CONFIG_ANDROID_RAM_CONSOLE), which used persistent_ram (CONFIG_ANDROID_PERSISTENT_RAM) to handle a block of RAM that wasn't erased across reboots (2).
persistent_ram was based on Linux upstream RAMOOPS code which ...
If you're looking to change the default size for a log buffer, to persist between reboots, you can recompile the kernel with updated buffer sizes.
The file containing log buffer definitions is:
The versions I'm looking at use a macro to define log buffers in that file:
DEFINE_LOGGER_DEVICE(variable, name, ...