Glide: Release Build Failed for Android Studio 3

Created on 7 Sep 2017  路  19Comments  路  Source: bumptech/glide


Glide Version: 4.0.0, 4.1.0, 4.1.1, 4.2.0-SNAPSHOT


Integration libraries: No


Device/Android Version: Build Fail


Issue details / Repro steps / Use case background: While making a release build, the following error occurs:

Warning: there were 10 unresolved references to classes or interfaces.
         You may need to add missing library jars or update their versions.
         If your code works fine without the missing classes, you can suppress
         the warnings with '-dontwarn' options.
         (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
Warning: there were 2 unresolved references to program class members.
         Your input classes appear to be inconsistent.
         You may need to recompile the code.
         (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedprogramclassmember)
Warning: there were 3 unresolved references to library class members.
         You probably need to update the library versions.
         Alternatively, you may have to specify the option 
         '-dontskipnonpubliclibraryclassmembers'.
         (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedlibraryclassmember)
Warning: Exception while processing task java.io.IOException: Please correct the above warnings first.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:transformClassesAndResourcesWithProguardForProductionRelease'.

Android Studio

Android Studio 3.0 Beta 2
Build #AI-171.4263559, built on August 11, 2017
JRE: 1.8.0_152-release-915-b01 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.6

Gradle & Kotlin

classpath 'com.android.tools.build:gradle:3.0.0-beta2'
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.1.4-3"  

Tried all 4 versions as mentioned above.
Works fine with 3.6.1.
Works fine for debug build.

question stale

Most helpful comment

As #2356 (thanks @SIARAY) shows, the problem is Glide referencing android.graphics.Bitmap$Config.HARDWARE. I checked all usages and they're all guarded properly by VERSION_CODES.O, which means that it's safe to ignore these warnings:

-dontwarn com.bumptech.glide.load.engine.bitmap_recycle.LruBitmapPool
-dontwarn com.bumptech.glide.load.resource.bitmap.Downsampler
-dontwarn com.bumptech.glide.load.resource.bitmap.HardwareConfigState

The real solution, however, is to up your compileSdkVersion to 26 where HARDWARE was introduced. Note that this shouldn't change app behavior, because that is controlled by targetSdkVersion. Still, it'll bring in a few deprecated warnings probably.

All 19 comments

It doesn't look like you included the actual error message?

This is what the gradlew installRelease gives. Other parts look irrelevant.
Two of us Devs have spent half a day trying to find the exact error, if you can point out where we can look for it?

Maybe try https://docs.gradle.org/current/userguide/logging.html?

Usually somewhere in the gradle output is the thing that actually failed.

Gradle Properties

# The Gradle daemon aims to improve the startup and execution time of Gradle.
# When set to true the Gradle daemon is to run the build.
org.gradle.daemon=true

# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
# Default value: -Xmx10248m -XX:MaxPermSize=256m
org.gradle.jvmargs=-Xmx4608m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

# When configured, Gradle will run in incubating parallel mode.
# This option should only be used with decoupled projects. More details, visit
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects
org.gradle.parallel=true

# Enables new incubating mode that makes Gradle selective when configuring projects.
# Only relevant projects are configured which results in faster builds for large multi-projects.
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:configuration_on_demand
org.gradle.configureondemand=false

Logs

[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:transformClassesAndResourcesWithProguardForProductionRelease'.
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100)
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Caused by: java.io.IOException: Please correct the above warnings first.

Nothing more relevant in the debug logs and stack trace. I will try to make a build with a new app and incrementally add our project libraries to see if there's any conflict.

Oh, ok maybe it is caused by the proguard warnings then. Those are pretty non-specific though. I think proguard outputs a log? Maybe https://www.guardsquare.com/en/proguard/manual/troubleshooting?

Hard to tell what it's referencing from the logs you have now.

I'm 99% sure it prints class names and everything to help resolve this, maybe you have some filter.

Add -verbose line into your proguard config file and run gradlew task --debug --stacktrace for most output possible.

As #2356 (thanks @SIARAY) shows, the problem is Glide referencing android.graphics.Bitmap$Config.HARDWARE. I checked all usages and they're all guarded properly by VERSION_CODES.O, which means that it's safe to ignore these warnings:

-dontwarn com.bumptech.glide.load.engine.bitmap_recycle.LruBitmapPool
-dontwarn com.bumptech.glide.load.resource.bitmap.Downsampler
-dontwarn com.bumptech.glide.load.resource.bitmap.HardwareConfigState

The real solution, however, is to up your compileSdkVersion to 26 where HARDWARE was introduced. Note that this shouldn't change app behavior, because that is controlled by targetSdkVersion. Still, it'll bring in a few deprecated warnings probably.

Thank you @TWiStErRob , my problem resolved.

Adding those in proguard resolved for those.
But I got 2 more:

can't find referenced method 'com.bumptech.glide.DrawableTypeRequest load(java.lang.String)' in program class com.bumptech.glide.RequestManager
can't find referenced class com.bumptech.glide.DrawableTypeRequest

Thanks @TWiStErRob.

I wonder if there's a useful way to document which sdk people should compile against for Glide?

Not working when compileSdkVersion is set to 26
No visible errors (resolved above two by including transitive dependencies of the module)

DrawableTypeRequest is from Glide v3. Are you using both Glide v3 and v4 in the same project? If so, that might be the source of the issues.

I am using Glide4 in my project but one of my dependency is including Glide 3.

@WhiteHatArpit Unfortunately that's unsafe, there's probably no good way to make that work. Even if you could, you're going to end up with two disk caches (maybe sharing the same folder!), two memory caches, two thread pools etc.

Thanks for all the effort and help. For now, I have reverted back to Glide 3 on my project. I guess it would take some time before migrating to Glide 4.
Though, I still don't understand why won't it compile.

Resolved my issue. @TWiStErRob, Thank you for your solution.

Thanks @TWiStErRob , save my time.

This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings