1

I recently had to capture my logcat for my HTC EVO 4G device to try and identify the reason why updates sometimes fail claiming there is insufficient memory (issue discussed more extensively here).

However, the log captures EVERYTHING which means you have a lot of unnecessary information as well which makes it hard to look at the raw data without getting overwhelmed with the amount of data. I am trying to isolate the data relevant to the updating process so we can see what's going on that is triggering the error when there is enough space on the internal storage that can't be exhausted by the size of the installer and/or application size.

Does anyone have a suggestion for a LogCat viewer or recommendation? What solution works best? Preferably a visual (GUI) tool that can process the file with filtering capability and hopefully intelligent grouping and so on.

Improve this question
1

1 Answer 1

Reset to default
1

A good starting point is a Google search on "adb logcat filter", which yields interesting results already on its first page. Including the logcat help page from the Android project itself, which lists quite detailed options. Especially follow up to the Reading and writing logs link, where filtering options are explained.

The basic syntax is specified as

[adb] logcat [<option>] ... [<filter-spec>] ...

Interesting options include to write the output to a file (-f <filename>) and using human-readable timestamps (-v time). The filtering example given should get you started on the second part:

adb logcat ActivityManager:I MyApp:D *:S

In short terms: Show all Info messages from ActivityManager, Debug messages from MyApp, and Silence everything else.

As long as you're completely out of ideas what exactly you're looking for, you might at least have some ideas on what you are not looking for, and could use something like GamesApp:S FunnyApp:S MoreApp:S [...] to filter out stuff which is definitely not of interest. So your command could look like

adb logcat -f special.log -v time GamesApp:S FunnyApp:S MoreApp:S

When you have excluded the impossible, whatever remains, however improbable, must be the truth. – Arthur Conan Doyle: The Adventure of the Beryl Coronet (Sherlock Holmes)

Improve this answer
3
  • For the output I did the old school windows trick of just running adb logcat > log.txt and that's how I got mine which was fine. The output is surely the same but good to know there is a built-in option for it, will use that next time. How do I identify the tag for the item I am trying to capture, remember that we are trying to observe what the updater is doing so we can see why its causing insufficient memory when there is space. SO what tag should I use? play updater or application specific? not sure how they are grouped or performed.
    – GµårÐïåñ
    Commented Nov 1, 2013 at 21:13
  • I totally agree with alternatively excluding things to tidy up the massive spammy output but if we can find out the output specifically generated by the update process (which is what we are trying to observe for space management behavior) that would be more useful, no? Ideas? I am not familiar too much with how Android tags each process, so not sure if the update process is tagged under play or under the specific application being updated, or some core process than handles updates in general. Thoughts?
    – GµårÐïåñ
    Commented Nov 1, 2013 at 21:15
  • I'm no developer either. So my approach would be as described above, to narrow down results by filtering out what I'm sure I definitely don't need. The human-readable timestamp is helpful here as well, as you usually know what time you've triggered the action (substract a little at start and end, and cut off heads and tails). Sorry that I can't be more helpful; but with some luck someone else might be able to jump in?
    – Izzy
    Commented Nov 1, 2013 at 21:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .