I have encountered this problem several time whenever I update my Gradle version & Gradle Android plugin. For example, I used to use:
Gradle 2.1
Gradle Android Plugin com.android.tools.build:gradle:0.13.3
With this version, my build script contains for example:
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'), \
'proguard.cfg'
}
debug {
runProguard false
}
}
Few weeks later, I saw a new Gradle version (2.2.1) was released, so, I updated my Gradle & Gradle Android Plugin to newer version:
Gradle 2.2.1
Gradle Android Plugin com.android.tools.build:gradle:1.0.0+
Then, I run command gradle clean build, suddenly, the build is not successful anymore, because with the newer version, I got error:
Could not find method runProguard()
My questions are:
(MAIN QUESTION) It seems everytime when the Gradle & Gradle Android Plugin are updated, there are always some methods are deprecated, it is understandable. BUT, I am really appreciate if there is a document summarizes all the deprecated methods & their replacements. So, where can I find such information? Seems Gradle & Gradle Android Plugin don't do a good job on this to facilitate developers to quickly migrate the build script to newer version.
How to get rid of the error: Could not find method runProguard() in my above case?
change
runProguard ****
to
minifyEnabled ****
you can get the deprecated methods or resources here http://tools.android.com/tech-docs/new-build-system for the android studio builds or releases
I really want to know where is the place to find out the replacements of deprecated methods in general when Gradle & Gradle Android Plugin are updated
That would be the documentation, particularly the release notes. 0.14.0 renamed runProguard to minifyEnabled, and 0.14.3 removed runProguard.
You should replace runProguard true with minifyEnabled true, there are a lot of question about this topic.
On your first question, I read some official statement here saying that, from now on, they'll try to stick to actual methods name and/or provide support info, to make the switch between gradle versions easier, so you shouldn't be worried.
From version 1.0.0 and going forward, we will strive much harder to not make incompatible changes, and if we do, we plan to write IDE support to help migrate the projects automatically.
Related
Latest Android gradle plugin 7.0.0-alpha15 removed the option isShrinkResources in BuildType.
Does isMinifyEnabled now superseeds it, or is there a new way to ensure the resources will be shrinked when building the app?
According to Google, the missing isShrinkResources issue is fixed in an upcoming AGP 7.0-beta1
https://issuetracker.google.com/issues/186806256
So today I decided to try my hand at making at making a dynamic feature module. I have R8 enabled with both minifyEnabled and shrinkResources set to true. Trying to compile gives me the following error.
Resource shrinker cannot be used for multi-apk applications
Affected Modules: app
Has anyone else seen this? There are similar questions around stack but nothing directly related to DFMs.
I would love to keep this flag enabled to avoid library bloat
Gradle Plugin: 4.0.0
Gradle Wrapper: 6.1.1
This feature is implemented starting Android Gradle Plugin 4.2.0 and can be enabled by setting android.experimental.enableNewResourceShrinker=true flag in gradle properties.
Details are available here.
I just updated Android Studio to 3.5.
BTW updated the Gradle version and several libraries.
To my surprise, the application does not fit into a single DEX (uses over 73,500 methods, previously in debug version as far as I remember ~50K)
What changes have I made:
Kotlin 1.3.41 -> 1.3.50
classpath 'com.android.tools.build:gradle:3.5.0' from 3.4.2
classpath 'com.google.gms:google-services:4.3.1' from 4.3.0
implementation 'com.google.android.gms:play-services-ads:18.1.1' from 18.1.0
implementation 'com.google.firebase:firebase-core:17.1.0' from 17.0.1
The new release APK has fewer (60) methods (26760) than the previous one.
Other problem I got:
NDK Resolution Outcome: Project settings: Gradle model version=5.4.1, NDK version is UNKNOWN error
App using AndroidX.
app is compiling & work now OK when set
debug {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
I imported settings from an older version of Android Studio. Maybe here is the problem?
Or there is no problem and I have to reconcile and use multiDEX (for development) and in release apk drop multiDEX?. Will multidex be better than minifyEnabled for debug version?
Changed:
debug {
// minifyEnabled true
// proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
multiDexEnabled true
}
And is working with multiDex when I run emulator with APK >=21.
Prior 21 API will test using release APK only.
BTW APK analyze my debug version show:
classes.dex 54806 methods
classes2.dex 1107 methods
classes3.dex 6725 methods
Total: 62638.
When I disable multiDex.
Cannot fit requested classes in a single dex file (# methods: 73883 > 65536) ;))
Something is not right ;)
set multiDexEnabled true globally or for both build-types - else the release build will exceed the 64k limit of a single DEX file. debug & release build can have different method count, because these are two merged source-sets - and unused classes may also be stripped (multiDexEnabled true also adds it's own library). While minifyEnabled true for debug builds is useless ...and I really don't understand why one would intend to do that. When the non-public class/method names in the APK do not match those class names in the IDE, one might find it difficult to debug that, because breakpoints will not catch; it's alike shooting oneself into the leg.
If a single library update introduces a new dependency, this can add lots of classes & methods.
According to documentation setting minifyEnabled to false must disable ProGuard run
integration {
minifyEnabled false
versionNameSuffix "-int"}
But the ProGuard is still started by Gradle! Any ideas why?
You will need to change the Build Variant to use one of the integration build variants (from the bottom left in android studio), if you want to use the configuration for integration buildType.
From what you describe you appear to be using a different buildType. By default it is debug. Make sure an integration Build Variant is selected and you should be good.
As it often happens, I found and answer after posting my question.
"This is not a bug, this is a feature":
https://groups.google.com/forum/m/#!topic/adt-dev/iS_lyRH8hL8
This is not really a problem, but certainly annoying.
The output you are seeing is related to the way the Android gradle plugin determines the set of classes that must be in the main dex file when multidex is enabled. For this purpose it uses ProGuard internally, but it is unrelated to your configuration.
In order to disable the logging output of this task, you can add the following to your build.gradle file:
tasks.whenTaskAdded { task ->
if (task.name.startsWith("transformClassesWithMultidexlistFor")) {
task.logging.level = LogLevel.ERROR
}
}
I am building an Android app with gradle 1.8 and Android Gradle plugin 0.6.3.
android {
...
buildTypes {
...
release {
runProguard true
proguardFile 'proguard.cfg'
proguardFile getDefaultProguardFile('proguard-android.txt')
}
...
}
Every time I run gradle assembleRelease, the proguard step seems to run each time - the results of the previous assemble do not seem to be reused, despite no code changes. The compile step also says UP-TO-DATEfor subsequent runs, which seems to confirm this. Running proguard adds a significant amount of time to every build. In particular, running connectedInstrumentTest currently requires proguard to run each time.
Is this normal behavior when using proguard/gradle? If not, what are some things that could cause the proguard step to run each time?
Note: It is not actually possible for me to build my app without proguard shrinking anymore, the dex step fails with the following error:
trouble writing output: Too many method references: 67195; max is 65536.
This should be solved when the Android Gradle task upgrades to the ProGuard Gradle task version 4.10. The latter has the necessary annotations for Gradle to check if the output is up to date.