For information on Glide v4, see the documentation. This wiki covers Glide v3 only.

Glide includes a number of small and optional integration libraries that allow Glide to interface with external libraries. Currently Glide includes integration libraries for performing all http/https operations with Volley and OkHttp.

We strongly believe that your choice of a client side media library should neither dictate the networking library you use in your app, nor require you to include an additional networking library used only to load images. The integration libraries and Glide's ModelLoader system allow developers to use a consistent platform for all networking operations across their app.

Because you haven't written the integration library for it yet! OkHttp and Volley are popular libraries that many developers will find useful, but we certainly don't mean to exclude any other library. If you've written a ModelLoader for another library for your app and want to open source it, we'd love to see pull requests to support additional libraries.

There are two parts to depending on any integration library:

1. Include the corresponding Maven, Gradle, or jar dependency, because the optional integration libraries are not included in the glide jar dependency.
2. Make sure the app includes the integration library's GlideModule. For more information on GlideModules, see the Configuration wiki page. For specific instructions for each of Glide's current integration libraries, see below.

The integration libraries are versioned together with the Glide releases, but follow different numbering. Make sure you pick the version that corresponds to your Glide dependency version. Check the Downloads on releases page for versions.

The networking libraries have yet another versioning and the integration libraries depend on those versions via transitive Maven/Gradle dependencies when used through Maven Central/JCenter, you can override the version by explicitly including the networking library dependency.

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

dependencies {
    compile 'com.github.bumptech.glide:volley-integration:1.5.0@aar'
    //compile 'com.mcxiaoke.volley:library:1.0.8'
    // but should be compatible with latest as well, if you want to override it
}

When you use the @aar qualifier the integration library's GlideModule will be merged into your application's manifest automatically. When using @jar or omitting the qualifier you need include the library module yourself or use the classes in your own GlideModule.

<dependency>
    <groupId>com.github.bumptech.glide</groupId>
    <artifactId>volley-integration</artifactId>
    <version>1.5.0</version>
    <type>aar</type>
</dependency>
<dependency>
    <groupId>com.mcxiaoke.volley</groupId>
    <artifactId>library</artifactId>
    <version>1.0.8</version>
    <type>aar</type>
</dependency>

See the corresponding manifest section to include the integration library's GlideModule.

Download the glide-volley-integration-<version>.jar from the releases page and add it to your Android app's compile classpath.

See the corresponding manifest section to include the integration library's GlideModule.

If you build with Maven, Ant, or any build system that does not support manifest merging, you must manually add the GlideModule metadata tag in your AndroidManifest.xml:

<meta-data
    android:name="com.bumptech.glide.integration.volley.VolleyGlideModule"
    android:value="GlideModule" />

Regardless of the build system you use, you need to make sure proguard doesn't obfuscate or strip the VolleyGlideModule class so it can be instantiated using reflection. Add the following to your proguard.cfg file (or see the generic section):

-keep class com.bumptech.glide.integration.volley.VolleyGlideModule

OkHttp is an HTTP client that’s efficient by default, perseveres when the network is troublesome and is easy to use.

dependencies {
    compile 'com.github.bumptech.glide:okhttp-integration:1.5.0@aar'
    //compile 'com.squareup.okhttp:okhttp:2.2.0'
    // but should be compatible with latest as well, if you want to override it
}

When you use the @aar qualifier the integration library's GlideModule will be merged into your application's manifest automatically. When using @jar or omitting the qualifier you need include the library module yourself or use the classes in your own GlideModule.

<dependency>
    <groupId>com.github.bumptech.glide</groupId>
    <artifactId>okhttp-integration</artifactId>
    <version>1.5.0</version>
    <type>aar</type>
</dependency>
<!--
<dependency>
    <groupId>com.squareup.okhttp</groupId>
    <artifactId>okhttp</artifactId>
    <version>2.2.0</version>
    <type>jar</type>
</dependency>
-->

See the corresponding manifest section to include the integration library's GlideModule.

Download the glide-okhttp-integration-<version>.jar from the releases page and add it to your Android app's compile classpath.

See the corresponding manifest section to include the integration library's GlideModule.

If you build with Maven, Ant, or any build system that does not support manifest merging, you must manually add the GlideModule metadata tag in your AndroidManifest.xml:

<meta-data
    android:name="com.bumptech.glide.integration.okhttp.OkHttpGlideModule"
    android:value="GlideModule" />

Regardless of the build system you use, you need to make sure proguard doesn't obfuscate or strip the VolleyGlideModule class so it can be instantiated using reflection. Add the following to your proguard.cfg file (or see the generic section):

-keep class com.bumptech.glide.integration.okhttp.OkHttpGlideModule

OkHttp is an HTTP client that’s efficient by default, perseveres when the network is troublesome and is easy to use.

dependencies {
    compile 'com.github.bumptech.glide:okhttp3-integration:1.5.0@aar'
    //compile 'com.squareup.okhttp3:okhttp:3.2.0'
    // but should be compatible with latest as well, if you want to override it
}

When you use the @aar qualifier the integration library's GlideModule will be merged into your application's manifest automatically. When using @jar or omitting the qualifier you need include the library module yourself or use the classes in your own GlideModule.

<dependency>
    <groupId>com.github.bumptech.glide</groupId>
    <artifactId>okhttp3-integration</artifactId>
    <version>1.5.0</version>
    <type>aar</type>
</dependency>
<!--
<dependency>
    <groupId>com.squareup.okhttp3</groupId>
    <artifactId>okhttp</artifactId>
    <version>3.2.0</version>
    <type>jar</type>
</dependency>
-->

See the corresponding manifest section to include the integration library's GlideModule.

Download the glide-okhttp3-integration-<version>.jar from the releases page and add it to your Android app's compile classpath.

See the corresponding manifest section to include the integration library's GlideModule.

If you build with Maven, Ant, or any build system that does not support manifest merging, you must manually add the GlideModule metadata tag in your AndroidManifest.xml:

<meta-data
    android:name="com.bumptech.glide.integration.okhttp3.OkHttpGlideModule"
    android:value="GlideModule" />

Regardless of the build system you use, you need to make sure proguard doesn't obfuscate or strip the VolleyGlideModule class so it can be instantiated using reflection. Add the following to your proguard.cfg file (or see the generic section):

-keep class com.bumptech.glide.integration.okhttp3.OkHttpGlideModule

You have an alternative to keep all possible GlideModule modules:

-keep public class * implements com.bumptech.glide.module.GlideModule

This has the added benefit that it doesn't need to change if/when you change integration libraries, or customize the integration library's behavior. It also includes any additional modules which you may add later and portable between projects.

All integration libraries have additional options if you're not satisfied with the defaults. For example adding retry-behaviour. See the source code of the integration libraries' GlideModules at /integration/<lib>/src/main/java/<package> for how the default registration is done. You can then modify the behavior by changing the arguments for the UrlLoader.Factory class in your own custom GlideModule.

When overriding default behaviour make sure your custom GlideModule is registered in the manifest and the default one is excluded. Exclusion may mean removing the corresponding metadata from the manifest or using the jar dependency instead of the aar one. For more info on GlideModules see the Configuration wiki page.