-
Notifications
You must be signed in to change notification settings - Fork 752
Frequently Asked Questions
Volley is not suitable for large download or streaming operations, since Volley holds all requests and responses in memory during parsing. For large download operations, consider using an alternative like DownloadManager.
This also explains why Volley will run out of memory if you try to use it for a large request/response, and why Volley doesn't expose an API to get the progress of an individual in-flight request or pause/resume in-flight requests.
This decision is fundamental to Volley's architecture, as it simplifies the API for most operations which have small requests/responses, and cannot be changed to support streaming.
Android as a whole has disabled cleartext requests - that is, those using HTTP but not HTTPS - by default for any app which sets targetSdkVersion to 28 or higher. This is not specific to Volley; it applies to any network requests your app may be making.
If migrating to HTTPS-only requests is not an option for your use case, please see the network security configuration documentation for how to whitelist some or all cleartext HTTP requests for your app.
The app-facing API for making requests is asynchronous. You add requests to the queue and the provided response listener will be invoked when the request completes.
Some of Volley's internals are synchronous when it comes to dispatching the requests, but for most applications this would not be a major concern. If you are dispatching many parallel requests or are severely memory constrained, then Volley's design may not be ideal because the number of cache and network threads is fixed, and the threads remain idle as long as the RequestQueue is started. Fixing this is on the roadmap, but from the app's perspective this shouldn't result in any changes to the API surface unless you're making custom HTTP stacks or cache implementations.
In the meantime, you may consider using Cronet, which offers a fully asynchronous HTTP stack, if this is critical to your use cases.
Snapshot builds are automatically generated for every commit to Volley's master branch and published to Sonatype OSSRH's snapshot repository. You can add this repository to your build.gradle configuration with:
repositories {
maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
}
and then change your dependency to com.android.volley:volley:VERSION, where VERSION is the most recent version available in the snapshot repository.
This means your request is reaching the server, but the server is returning an HTTP error code. If you control the server, take a look at the server logs and inspect the request from there to understand what the client is doing incorrectly, if anything.
Volley itself is a thin layer over an underlying HTTP stack, such as HttpUrlConnection or Apache HTTP. If your request works from one client, but not Volley, the key is to determine why those requests are different.
Try just using HttpUrlConnection directly to make your request. If it doesn't work there either, then the issue is not with Volley, but with how you're assembling the request. If it does work with HttpUrlConnection, then look into HurlStack to see if it is doing anything differently on top of HttpUrlConnection.
I'm getting SSLProtocolException ("Failure in SSL library, usually a protocol error") on older Android versions
Many servers have disabled older, insecure SSL protocols in favor of newer ones. However, these newer protocols may not be supported or enabled by default on older platform versions, which can causes requests to fail.
If you already depend on Google Play Services or don't mind taking on that dependency, use ProviderInstaller to install a new SSL provider. This provider will have TLSv1.2 enabled by default and is generally preferable to any legacy platform provider as it will always have the latest updates.
Otherwise, HurlStack has a constructor which takes a custom SSLSocketFactory; you may provide one on API 16-19 devices which adds TLS v1.1 and v1.2 to the enabled protocols for any socket it creates. However, these implementations may have a bug or limitation as they are not enabled by default, so this approach may be riskier than using Google Play Services. You can look at PR #137 for an example of how to do this; although this will not be merged into Volley at this time, it should be straightforward enough to copy the classes here and/or adapt them to your needs.