Potential debug logging even when DEBUG is False

[vorlon77]

core/src/main/java/com/android/volley/toolbox/NetworkUtility.java logs the message request when the network response is "slow" even when DEBUG is turned off since the conditional statement uses || rather than && when checking whether the message should be logged.

[jpd236]

Thanks for the report!

This is actually working as intended, though the behavior may be surprising. The log is logging details about the HTTP response; the default behavior is to do this only when there are slow responses, because those may be a sign of a client/server issue or misuse of Volley; we feel that it is on balance more helpful to enable this by default than require a special setting to do so, so that if a user/developer complains about slow app behavior, this information is readily available. The "|| DEBUG" is to enable this logging on all requests, not just slow ones.

So we wouldn't want to change this to "&&". If you really don't want this logging to ever happen, one simple solution that wouldn't require library changes would be to add a Proguard config to -assumenosideeffects for VolleyLog.d, which would strip out all calls to VolleyLog.d at compile time. I might be open to an API that provides a way to turn off this logging specifically, although there's not really a great place to put it other than VolleyLog itself.

[vorlon77]

If this is working as intended, then perhaps is there a way to remove the surprise for developers who are trying to do the right thing when they attempt to disable debug logging in production builds? Is there a good place to clarify this in the documentation? From what I've seen with published apps, it might be asking too much for most developers to know that you need to add that Proguard config to disable all of the debug messages.

There is the potential to leak sensitive data to the log since the entire request string is logged, not just information about the response. There are apps in the PlayStore that use GET requests with access tokens, IDs, etc. and these do end up in the logs.
Sensitive information ending up in the logs and then being accessed by other apps is the motivation behind the changes to the LogcatManagerService. See https://cs.android.com/android/_/android/platform/frameworks/base/+/256519a529fc7f742dd962d859ab1ab7bdc0b033 for the first in a series of commits.

Somehow it should be easy for developers to discover how to disable ALL debug-level logging for a library.

[jpd236]

Fair points - I'm raising them internally to decide on next steps.

[jpd236]

OK. Agreed that logging URLs shouldn't be done by default.

I don't feel that the slow request logging is providing enough value to be worth keeping if it means having to add an API to opt into it. And I don't think it's useful to log without the URL or worth going down the road of trying to figure out other identifying information to log. Better to just let applications apply their own monitoring however they see fit, with their own thresholds for what is "slow". And probably using a more structured mechanism than a log line.

Will leave concrete suggestions on the PR, but at a high level I think we should just log this line if VolleyLog.DEBUG is true and remove the concept of "slow logging" altogether.

[vorlon77]

I agree. When developing an app, "slow" might mean different things depending on what is expected and the log message does include the response time.

[jpd236]

Thanks.

If this is needed before the next release, see these instructions for how to depend on a SNAPSHOT build. We aim to keep our master branch stable.