Comments (6)
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.
from volley.
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.
from volley.
Fair points - I'm raising them internally to decide on next steps.
from volley.
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.
from volley.
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.
from volley.
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.
from volley.
Related Issues (20)
- The JsonObjectRequest and JsonArrayRequest don't support 204: No Content HOT 5
- Unexpected response code 511 for HOT 1
- Support digest authentication HOT 2
- Type com.android.volley.Cache$Entry is defined multiple times HOT 1
- Caused by: com.android.tools.r8.utils.AbortException: Error: Program type already present: com.google.android.youtube.player.YouTubeApiServiceUtil HOT 1
- Volley unable to parse dateStr HOT 1
- setPriority() for Request HOT 1
- E/Volley: [18667] NetworkUtility.shouldRetryException: Unexpected response code 403 HOT 1
- -
- Com.android.volley.2015.05.28.jar HOT 1
- Support Proxy functionality HOT 1
- Volley: [5311] NetworkUtility.logSlowRequests: HTTP response for request=<[ ] HOT 3
- NetworkUtility.logSlowRequests: HTTP response for request=<[ ] https://www.google.com/ 0xd61ac103 NORMAL 1> [lifetime=6472], [size=159525], [rc=200], [retryCount=1]
- Fix nullability issues in Kotlin sample code HOT 4
- Pagination HOT 1
- Getting E/Volley: [19618] NetworkDispatcher.processRequest: Unhandled exception HOT 4
- pls rply me what can i do for this HOT 1
- ConcurrentModificationException on cancel HOT 1
- App Crashed on Android version 4.3 java.lang.NoClassDefFoundError: com.android.volley.toolbox.Volley HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from volley.