Support Android's Logcat

[thedpws]

I propose support for Android's logcat format.

Scope

• Support default logcat format (not brief, long, etc.)
• Log level colorization
• Inclusive + Exclusive Filtering by tag regex, PID, message regex

Details

Android Logcat looks like this example.

...
02-15 08:00:12.370  2009  2009 I MediaCodecsXmlParser: limit: blocks-per-second-range = 1-489600
02-15 08:00:12.370  2009  2009 I MediaCodecsXmlParser: limit: bitrate-range = 1-60000000
02-15 08:00:12.370  2009  2009 I MediaCodecsXmlParser: limit: feature-adaptive-playback = 0
02-15 08:00:12.370  2009  2009 I MediaCodecsXmlParser: limit: max-concurrent-instances = 4
02-15 08:00:12.370  2009  2009 I MediaCodecsXmlParser: limit: performance-point-1920x1080-range = 50-50
02-15 08:00:12.370  2009  2009 I MediaCodecsXmlParser: limit: size-range = 32x32-1920x1080
...

Or more concisely, date time PID TID log-level tag: message

[thedpws]

Hi all! I'd like to implement this. I haven't used logview yet. What roadblocks specific to logcat should I anticipate? Alternatively, is this better implemented by extension rather than directly in the package?

[thedpws]

For my reference, this is an example of a solution by extension.

(use-package logview
    :config
    (add-to-list 'logview-additional-submodes
        '("Android"
            ((format . "TIMESTAMP PID LEVEL: MESSAGE")
             (timestamp . "AndroidTimestamp"))))
    (add-to-list 'logview-additional-level-mappings
        '("Android"
            ((error "E")
             (warning "W")
             (information "I")
             (debug "D")
             (trace "V"))))
    (add-to-list 'logview-additional-timestamp-formats
         '("AndroidTimestamp" (java-pattern . "MM-dd HH:mm:ss.SSS"))))

[doublep]

What roadblocks specific to logcat should I anticipate?

Probably none. Basically, you just need to add appropriate values to logview-std-* variables instead of logview-additional-* to make this standard.

PID

As Logview doesn't support that, I'd suggest using THREAD. It also has a comparable meaning in this case, as each process' messages can be seen as a (mostly) independent stream, which are then all collected into one file.

About timestamp format: is it specified anywhere that timestamps are formatted exactly like this? Can it somehow be dependent on your machine's locale instead?

[doublep]

Also, e.g. this page shows substantially different examples. Can you point me to some specification?

[thedpws]

Hey @doublep ,
It seems Android supports different formats for the logs. My example can be reproduced with the -v threadtime modifier (which is default). What do you think about supporting the default as the standard?

[doublep]

My example can be reproduced with the -v threadtime modifier (which is default).

Sorry, I have no idea with what that modifier is used, I don't develop anything on Android. Can you provide any link?

What do you think about supporting the default as the standard?

That would be the best, but I haven't yet seen the standard. We could also add support for several common formats, not necessarily just one, but I need to see them somewhere first.

[chetstone]

@doublep I think he meant -v threadtime is the default format produced by the adb logcat command: https://developer.android.com/tools/logcat#outputFormat

I wanted to look at some Robo test logs produced by Google's Firebase Test Lab. The format of those logs appears to be the same as that mentioned in the first post of this issue, so I think it would be safe to assume that as a standard format.

I tried adding a submode using @thedpws code above but got several errors. Here's what works for me:

(use-package logview
  :ensure t
  :config
  (add-to-list 'logview-additional-submodes
               '("Android" .
                 ((format . "TIMESTAMP THREAD IGNORED LEVEL NAME : MESSAGE")
                  (levels . "AndroidLevels")
                  (timestamp  "AndroidTimestamp"))))
  (add-to-list 'logview-additional-level-mappings
               '("AndroidLevels"
                 ((error "E")
                  (warning "W")
                  (information "I")
                  (debug "D")
                  (trace "V"))))
  (add-to-list 'logview-additional-timestamp-formats
               '("AndroidTimestamp" (java-pattern . "MM-dd HH:mm:ss.SSS")))
  )

Here is the result, with filters for Name = "Robo" and "ReactNativeJS":

[doublep]

In your screenshot lines with "I" and "D" are indistinguishable, and that appears to mean that the entry level is not properly understood. Is that so? E.g. does l 3 filter out "D" lines?

At the very bottom of the linked page, I see an example:

For example, using the following call:

Log.i("MyActivity", "MyClass.getView() — get item number " + position);

logcat outputs something similar to the following:

I/MyActivity( 1557): MyClass.getView() — get item number 1

But it looks completely unlike what is shown in your screenshot. Where does the difference come from?

[jimmeta]

Hi,
The reason the levels aren't working is because there's an extra level of parenthesis in the logview-additional-level-mappings. Defining the AndroidTimestamp format makes the built-in UNIX submode match, which is why it partially worked.

This config adds full support:

(use-package logview
  :ensure t
  :config
  (add-to-list 'logview-additional-submodes
               '("Android" .
                 ((format . "TIMESTAMP THREAD IGNORED LEVEL NAME: MESSAGE")
                  (levels . "AndroidLevels")
                  (timestamp . "AndroidTimestamp"))))
  (add-to-list 'logview-additional-level-mappings
               '("AndroidLevels"
                 (error "E")
                 (warning "W")
                 (information "I")
                 (debug "D")
                 (trace "V")))
  (add-to-list 'logview-additional-timestamp-formats
               '("AndroidTimestamp" (java-pattern . "MM-dd HH:mm:ss.SSS")))
  )

as tested with this random example I found online:
https://gist.github.com/mraphael2101/8ee64d588228332ffa8c3aab57eee781

@doublep Maybe this could be added to the default submodes?

[doublep]

@jimmeta: I formalized that as PR #64, please comment there. Questions: 1) is timestamp format specified anywhere; 2) levels (E/I/etc.) look similar to those used in Jupyter, is this some sort of a standard?