Volley is an HTTP library that makes networking for Android apps easier and, most importantly, faster.

I have two testing phones one is on 8.1 and the other one is on 9.0 volley is working fine on 8.1 but on 9.0 it's giving null in Volley Error I traced it its network issue. My Volley version is 1.1.1 How can I solve this any help would be appreciated.

I have met a issue , when I try to get the "contentType" from cache, it always return null. Then I checked the source code of "DiskBasedCache" and "BasicNetwork".

It turns out that in "DiskBasedCache" , the volley use "HaspMap" to save the http headers and in "BasicNetwork" it uses "new TreeMap<String, String>(String.CASE_INSENSITIVE_ORDER)" which is not case sensitive.

So if the server's response header, uses "content-type" rather than "Content-Type", it can work properly with a response from network but can't get contentType from the cache.

And because of this issue , you can't parse the charset from cache , and it will use the default charset which is "ISO_8859_1" , and if it doesn't match the actually charset which you should get from "content-type" , then you can't get the right response content with the right charset from cache.

Hi Team, com.android.volley.Request#finish is not clearing mErrorListener, not its calling onFinish as is the case with https://github.com/mcxiaoke/android-volley/blob/master/src/main/java/com/android/volley/Request.java finish. due to which error listener is not getting cleared and memory leak is there.

Hiding all VolleyLogs by setting VolleyLog.DEBUG to false is not working for all logs. How can we Disable all Logs(Log.e, Log.d etc) from volley. It seems like only the log.v can handle with the VolleyLog.DEBUG key.

I need to clear error listener after request is cancel (when call onStop()).

Currently that is no way to clear mErrorListener in Request class, which will cause leaked if the error listener implementation is reference fragment or activity.

Hi,

That branch provides two listeners in order to follow up on the progress of sending and receiving data.

Thank you for your time,

Best regards,

Nicolas Dagnas

Do you know when these recent updates will be included in a build published to jCenter/bintray?

Currently is the only way to get the "NegativeArraySizeException" update is to pull down the entire project and include/build locally?

I would rather use the gradle file for including the dependency.

dependencies { ... compile 'com.android.volley:volley:1.0.0' }

DiskBasedCache may fail repeatedly if a cached header is corrupt. In the event of failure, the most common error is OutOfMemoryError thrown from streamToBytes, caused by trying to allocate a huge number of bytes resulting from the bogus length calculated due to the corruption.

Once a header has been corrupt, the cache initialization will continue to fail, and the errant header will not be removed.

A less common failure was NegativeArraySizeException, but that was recently patched.

DiscBasedCache needs to be updated to guard against corruption.

Related to:

https://code.google.com/p/android/issues/detail?id=230219 https://github.com/mcxiaoke/android-volley/issues/141 (mirror) http://stackoverflow.com/a/42196956/901597

Volley currently depends on Apache HTTP. We can mostly remove the dependency except that HttpStack#performRequest returns an org.apache.http.HttpResponse, which means it'd be an API-breaking change to remove.

It might be worth biting the bullet and just doing a major version bump that breaks the API. There are other known issues that we could potentially address alongside this. However, one avenue worth exploring would be to see if we could treat Apache HTTP as a "provided" dependency - that is, one which is available at compile time, but not runtime - and then deprecate the old performRequest and add a new one that is implemented by all built-in clients (except HttpClientStack, which should be deprecated as well).

I think the result would compile and let apps build against Volley without pulling in the Apache HTTP dependency, but existing users could continue to use the Apache stack as long as they pulled in the dependency at runtime (and it should be there on an actual Android device).

Apart from the ugliness, my main concern is how proguard would respond to the missing reference - we could add a consumer proguard rule to not warn on org.apache stuff though that might be a bit overbearing.

Implemented the get function in AsyncCache that takes in a callback function in two different ways. In the one (DiskBasedAsyncCache), it uses an asynchronous file channel, and for the fallback version, it works very similarly to the current DiskBasedCache. Most of the code in those files are from that, aside from the get method. There are not tests yet for this, as not enough has really been implemented to test it, but was more to check the direction of the code.

I could not reproduce, but I usually got crash message from Fabric Crashlytics Report.

Device:

• Nexus 5X and Nexus 6P. OS version 8.1.0

Fatal Exception: java.lang.AssertionError: No NameTypeIndex match for SHORT_STANDARD at android.icu.impl.TimeZoneNamesImpl$ZNames.getNameTypeIndex(TimeZoneNamesImpl.java:724) at android.icu.impl.TimeZoneNamesImpl$ZNames.getName(TimeZoneNamesImpl.java:790) at android.icu.impl.TimeZoneNamesImpl.getTimeZoneDisplayName(TimeZoneNamesImpl.java:183) at android.icu.text.TimeZoneNames.getDisplayName(TimeZoneNames.java:261) at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1296) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:1004) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:974) at java.text.DateFormat.format(DateFormat.java:341) at com.android.volley.toolbox.HttpHeaderParser.formatEpochAsRfc1123(SourceFile:152) at com.android.volley.toolbox.BasicNetwork.getCacheHeaders(SourceFile:256) at com.android.volley.toolbox.BasicNetwork.performRequest(SourceFile:130) at com.android.volley.NetworkDispatcher.processRequest(SourceFile:120) at com.android.volley.NetworkDispatcher.run(SourceFile:87)

pls help do investigation on that crash.

After reading the documentation and looking into the Request.java file, it seems like there is currently no option to easily set the Priority for a Request, neither via Setter or Constructor. Is there any particular reason for this? I already found posts on Stackoverflow on how to get the desired functionality, but as basic as this is, I'm still curious to find out why the 'obvious' way hasn't been implemented, as I guess there is a good reason for it.

Thanks for any clarification.

If the server sends a 204 No Content, Volley still attempts to read the message body, and decode it. It shouldn't, or it should permit an empty body somehow.

(Forking from #402)

When an app depends on Volley (1.2.0+, possibly older as well), and doesn't also depend on androidx.annotation:annotation, the resulting build will have compiler warnings:

> Task :app:compileReleaseJavaWithJavac
warning: unknown enum constant Scope.LIBRARY_GROUP
  reason: class file for androidx.annotation.RestrictTo$Scope not found

These are non-fatal by default, but become fatal if -Werror is enabled.

This doesn't seem to have bothered anyone through now, but it'd be nice to fix. The problem is that neither option seems great. @RestrictTo needs to be retained at class-time, not source-time, so it's technically not safe to depend on as compileOnly. However, androidx.annotation:annotation isn't available on Maven Central, so we'd be requiring a dependency on something that can't actually be obtained there, though in practice this may be perfectly reasonable since you can't build a Google app without artifacts from the Google repository anyway. Removing the annotation wouldn't be ideal since it'd provide no protection (however light) against applications depending on methods meant for internal use in Volley.

Prior to #406, JsonArrayRequest required JSONArray request bodies, and JsonObjectRequest required JSONObject request bodies. Nothing should couple the request type and response type, so it's reasonable to want to send JSONObjects and get back JSONArray, or vice versa. However, the new constructors can end up breaking compilation of existing code which depend on Volley, since the request argument is nullable and thus ambiguous if null is provided. For example, code like:

JsonObjectRequest request = new JsonObjectRequest(Method.POST, url, null, listener, errorListener);

compiles fine with the current Volley production release, but suddenly fails to compile here since the compiler doesn't know whether this corresponds to the JSONObject or JSONArray constructor.

I don't see a great, backwards-compatible fix for this. Adding a factory method or builder isn't sufficient because subclassing the request is fairly common too (e.g. to populate custom headers). We could just reorder the arguments in one of them, but that would just make for a more confusing API.

So I think for the short term, we should just revert back to what was in place before. Longer term, if/when we make breaking API changes, we can consider improvements here.

The workaround is to extend JsonRequest directly, e.g.:

public class MyJsonObjectRequest extends JsonRequest<JSONObject> {
    public MyJsonObjectRequest(..., JSONArray request, ...) {
        super(..., request != null ? request.toString() : null, ...);
    }

    @Override
    protected Response<JSONObject> parseNetworkResponse(NetworkResponse response) {
        try {
            String jsonString =
                    new String(
                            response.data,
                            HttpHeaderParser.parseCharset(response.headers, PROTOCOL_CHARSET));
            return Response.success(
                    new JSONObject(jsonString), HttpHeaderParser.parseCacheHeaders(response));
        } catch (UnsupportedEncodingException e) {
            return Response.error(new ParseError(e));
        } catch (JSONException je) {
            return Response.error(new ParseError(je));
        }
    }
}

or just avoid using these classes entirely - they're not that complex, and you're probably better off using a strongly-typed JSON object instead.

E/Volley: [42916] NetworkUtility.shouldRetryException: Unexpected response code 403 for https://newsapi.org/v2/top-headlines?country=us&category=business&apiKey=271580bf514747cXXXXXXXXXXXXXXXXX

Code for reference: - https://github.com/msn2106/NewsApp/issues/2