Given the presence of the test runner's START line, I'm wondering if we're dropping lines in deobfuscation.

I removed complete logcat last night in https://chromium-review.googlesource.com/c/chromium/src/+/667808 b/c it's redundant.

(well, it's redundant *if per-test is working correctly*, which...)

Just searched my inbox for and example of this error message and came upon:

> 06-23 14:40:57.487 W/System.err(14869): java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.graphics.drawable.Drawable.getPadding(android.graphics.Rect)' on a null object reference
> 06-23 14:40:57.487 W/System.err(14869):         at org.chromium.ui.DropdownPopupWindow.<init>(DropdownPopupWindow.java:80)
> 06-23 14:40:57.487 W/System.err(14869):         at org.chromium.content.browser.input.SelectPopupDropdown.<init>(SelectPopupDropdown.java:37)
... 
06-23 14:40:57.488 F/chromium(14869): [FATAL:jni_android.cc(249)] Check failed: false. Please include Java exception stack in crash report

So I think the issue might be that the logcat filters are disabled for these messages:
https://cs.chromium.org/chromium/src/build/android/pylib/local/device/local_device_instrumentation_test_run.py?q=local_device_instr&sq=package:chromium&l=62

It's set to show everything at level E (these are just W), and does not have "System.err" tag whitelisted.

Ah. Yeah, that's more likely to be the case. :|

This is probably an indication that we should upstream the apk_wrapper.py piece of logic that filters based on PID (although I'm not convinced that logic is quite perfect yet).

why filter at all? things like activity manager logs are sometimes very useful

I think the filter may cause more confusions now. Should we remove it?

There's often quite a bit that's just useless noise. I'm reluctant to say we should remove it entirely, but if we want to expand what the filter accepts, I'm fine with that.

OK Let me change the filter to include these lines.

now that the full logcat is removed, how do you even hope to debug things like flaky devices and whatnot when all the test logs are filtered as well?

I think if we want a filter, we should do a blacklist instead. Figure out things that are clearly useless and then filter out those. Otherwise it's hard to even know if anything important got filtered out, no?

On nexus devices, logcat generally isn't all that noisy. Samsung on the other hand...

re flaky devices: we have more available to us than just the logcat for doing that.

I love that it's easy to find things in the filtered logcat, but if there's a change of it missing relevant logs, then it can be super frustrating.

If we're not worried about storage, can we keep both a filtered & unfiltered logcat?

We could alternatively consider coloring the logcat (like with apk_wrapper.py), such that it outputs an .html that has likely-irrelevant lines in a dim font color

talked to bo offline. I'm ok with a blacklist. I would prefer to not keep both filtered and unfiltered. I have no idea if logdog supports coloring; I know mikecase experimented with log coloring in the test runner's stdout.

as for html: logdog does not like html, which is why result_details lives in a GS bucket.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91eb1791edaf1200176bb6039dfc1950025ad509

commit 91eb1791edaf1200176bb6039dfc1950025ad509
Author: Zhiling Huang <hzl@chromium.org>
Date: Mon Sep 25 20:20:09 2017

Make the adb logcat print out all usefull logcat.

Previously, for tags that are unknown, we will include the logcat only
when its priority level is e(error). This condition makes us lose a lot of
usefull logcat, because the condition basically means we do not include
logcat by default. It was a whitelist only.

In this cl, I am removing this condition. Thus for all tags that are
unknown, we will include the logcat no matter what its priority level
is. This way we will make sure that no important logcats are lost, and
will include logcat by default.

In the future, if we find that we have included too many logcats and
want to blacklist a tag, we can simply add <tag>:S into the
LOGCAT_FILTERS to blacklist the logcat with that tag.

Bug:  766743 
Change-Id: I970a646a65b06fb66009a90c9a49df122c74d31d
Reviewed-on: https://chromium-review.googlesource.com/680894
Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Zhiling Huang <hzl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504149}
[modify] https://crrev.com/91eb1791edaf1200176bb6039dfc1950025ad509/build/android/pylib/local/device/local_device_environment.py