I have a Gradle plugin I wrote for an Android app project. Amongst other things - this plugin adds a custom ProGuard rules file to all ApplicationVariants being built.
the has worked fine until Android Gradle plugin 7.2 was introduced. Since I started using AGP 7.2 to compile my app - the ProGuard file that's added by the plugin is ignored.
Code:
project.android.buildTypes[<variant.buildType.name>].proguardFile = new File(<custom Proguard rules file path>)
This worked in AGP <= 7.0 without any problems. There are no exceptions in the logs of the build process.
I tried another approach and got the same results :
I tried to add a ProGuard file with a script (not using a plugin at all) - but the results were the same - this file is ignored.
This is the code I added in build.gradle :
afterEvaluate {
for (def buildType : project.android.buildTypes) {
buildType.proguardFile file(< full path>)
}
}
Any ideas?
In Groovy the value can be set for android.defaultConfig:
// this sets one file
android.defaultConfig { config ->
proguardFile new File("../general.pro")
}
// this adds an additional file
android.defaultConfig { config ->
proguardFiles.add(new File("../general.pro"))
}
// proof of concept
android.buildTypes { buildType ->
println buildType
}
This happens before :prepareKotlinBuildScriptModel, which means early on.
Where do i report this error? or could anyone help me?
“Directory X specified for property ‘$2’ does not exist” error when executing crashlyticsGenerateSymbols task
with
android gradle plugin 3.6.0
gradle version 5.6.4
fabric gradle plugin 1.31.2
[Error logs]
Some problems were found with the configuration of task ':~~~~~:crashlyticsGenerateSymbolsRelease' (type 'DefaultTask').
Directory '~~~' specified for property '$1' does not exist.
Directory '~~~~' specified for property '$2' does not exist.
Fabric/Firebaser here. This error comes up when the Fabric Gradle plugin is trying to parse your project structure in order to find your stripped and unstripped binaries, and is unable to do so. When it asks for properties $1 and $2 it means it could not find the default paths to the "obj" and "libs" folders that contain your supported ABIs folders with your supported native libraries there.
Using the legacy Fabric Gradle plugin, you can specify these paths under your crashlytics block in the build.gradle, like so:
crashlytics {
enableNdk true
androidNdkOut 'obj'
androidNdkLibsOut 'libs'
}
In the case for builds that are on Android Studio 3.5 or later, you can usually find the paths for these somewhere in the outputted build folders under "merged_native_libs" and "stripped_native_libs."
If you're using the new Firebase Crashlytics SDKs and Gradle plugin, those paths are controlled by "strippedNativeLibsDir" and "unstrippedNativeLibsDir" flags in the firebaseCrashlytics block in your build.gradle.
If you continue running into problems feel free to file a case with Firebase support with more details about your project and what you've tried to configure so far, and you can also still reach out to support#fabric.io.
I got the same issue on my side, and I fixed it by removing ext.enableCrashlytics = false from my app-level build.gradle in
android {
buildTypes {
debug {
// ext.enableCrashlytics = false
}
}
}
I added a new Java source folder release (app/src/release/java) for our release buildType. For this Android Studio automatically added this line to my app/build.gradle:
sourceSets { release { java.srcDirs = ['src/release/java', 'src/release/java/'] } }
We already had some code in the debug folder (app/src/debug/java) for our debug buildType. And there is no entry in the app/build.gradle file for debug source set.
And our release and debug builds are working as expected with and without the sourceSet entry.
So, is it that gradle looks for the source for build type x in app/src/x/java by default while building.
If yes, why did Android-Studio added the sourceSet line in build.gradle for me?
As far as I know you can create different "sourceSets" which basically just help you to organize code between different variants of your application. Every sourceSet except for the "main" set is optional.
You can find more in depth information about this topic on the android developer hub.
Ok, so Android Studio had added sourceSet to build.gradle cause I had marked 'Change Folder Location' while adding folder 'release' for buildType 'release'.
And by default Gradle does look for the source for build type x in app/src/x/java.
For example, for debug build type, there's no sourceSet entry in build.gradle. And on ./gradlew sourceSets it gives:
So there's no need to add sourceSet to build.gradle if you are not using custom folder structure.
I've switched to release build variant and configured signingConfigs. Now when I try to check the debug build variant from the drop down menu it switches immediately back to the release build variant. So I'm not able to run my app in debug mode any more.
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
apply plugin: 'kotlin-kapt'
apply plugin: 'realm-android'
android {
signingConfigs {
config {
...
}
}
compileSdkVersion rootProject.compileSdkVersion
buildToolsVersion rootProject.buildToolsVersion
defaultConfig {
applicationId "com.kost.foo"
minSdkVersion rootProject.minSdkVersion
targetSdkVersion rootProject.targetSdkVersion
versionCode 2
versionName "1.1"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
ndk {
abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'
}
externalNativeBuild {
cmake {
...
}
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
debuggable true
signingConfig signingConfigs.config
}
}
sourceSets {
main.java.srcDirs += 'src/main/kotlin'
main {
jniLibs.srcDirs = ['src/main/jni']
}
}
externalNativeBuild {
cmake {
path 'src/main/jni/CMakeLists.txt'
}
}
}
kapt {
generateStubs = true
}
repositories {
maven { url 'https://github.com/linchaolong/stetho-realm/raw/master/maven-repo' }
mavenCentral()
}
I've tried to revert all changes in build.gradle as it was before configuring, but with no luck.
Any ideas how to fix the issue?
I had a similar problem where most of the Build menu items were greyed out.
'Sync project with Gradle files' didn't fix.
I noticed a 'Build Variants' toggle button on the bottom left of Android Studio (v 3.1.2) and with this was finally able to choose the variant I needed.
Maybe this will work for you too.
Maybe you have got your solution to this, just in case, i provide my solution here.
For Android Studio 2.x
It may because that you compile your dependent project using:
compile project('module_a')
Above setting will force your project to compile the release version of your modules. Just change it to below:
releaseCompile project(path: ':module_a', configuration: 'release')
debugCompile project(path: ':module_a', configuration: 'debug')
For Android Studio 3.x
You don't need to explicitly specify the build variant for a "module project". Just using
implementation project(':library')
will automatically help select the correct build variant.
Here is a detailed explanation: https://developer.android.com/studio/build/?utm_source=android-studio#variant_aware
For Android Studio 3.x Upgraded from 2.x
Delete the .idea folder under your project root directory and restart your Android Studio.
Below is the GUI screenshot:
Hope it helps!
Just need to cut ".idea" Folder and paste it outside Project root folder( For Back up if you need).These files will be auto regenerated. On Opening the project it"ll ask add module (app) to your project. You can ignore the same.
It set set default build variant to be "debug".
You can see build variant tab on left corner or hover on "Monitor" Symbol on left bottom to get build variant option.
I just had the same issue. Solved it by closing Android Studio, removing the generated files and folders: .gradle, .idea, app/.externalNativeBuild, app/build, build, app/app.iml, ProjectName.iml, local.properties, then relaunching Android Studio and allowing it regenerate all these files from scratch.
Had the same problem, solved creating a new temporary Build Type, Build > Edit Build Types, select Build Types and add a new one. Sync, then you can select the new build type, and then revert back to original Debug build type.
Open your module setting. (Click F4)
Go to build types and create a new Build by clicking on plus(+) sign.
Name it anything, like "demo".
Duplicate all the data of debug build.
Now when you open Build Variant you will be able to switch to Debug as well as Demo.
For me I was unable to switch to our 'devDebug' variant but I could switch to another variant like 'devRelease' and then 'devDebug'. So try switching to another variant first.
I ran into a similar issue. My module level build.gradle reflected configurations specified for "debug" AND "release" accordingly. I was able to successfully run my app on emulator and device (LG) prior To Building and Signing My Release Version Of My App. After Building and Signing The Release Version and attempting to Run The Signed APK on My Phone and Device, i received an Error PM Session 'mobile': Error Launching activity....Error while Launching activity..So I started retracing my steps and realized that before deploying the signed release variant, i opened up the run/debug Configurations Dialog
and mistakenly selected the the Value APK from app bundle value From The Deploy attribute, under the Installation category
I Signed My APK In its ENTIRETY and NOT Via Bundle, so the option selected was attempting to Deploy an invalid App Bundle That Was Never Generated To Begin With, even if it was for the correct Build Variant.
I have this question too. My solution is checkout to the branch which i had changed the build variants. And at that branch, I can change from release back to debug. Then just checkout to current branch and everything is OK. It seems to be a Android Studio bug.
English is not my native language; please excuse typing errors.
I also meet this situation. i do this to solv .
Solv:
1. delete each module's impl suffix type file and build folder;
2. then click this button to sync project with gradle build file. button position
finally. and then this problem will be fix.
I fixed this issued by:
Add a new build type named debug1 via edit build.gradle;Enable debug function of this build type;
Sync and select the new build type debug1;
This issue seems to occur when opening the project in a symlinked location on linux. Opening the project directly fixed this issue for me.
relevant link: https://issuetracker.google.com/issues/156857164
For me, it was an issue with the gradle version. Make sure your plugin version and the required gradle version fit together, as defined here.
https://developer.android.com/studio/releases/gradle-plugin
You can find out which gradle versions you are using under:
File -> Project Structure... -> Project
I tried all the above to no effect. Eventually stumbled across File > Invalidate Caches/Restart... for other reasons and found it worked for me.
in main root of app in build.gradle
replace it from:
dependencies {
classpath 'com.android.tools.build:gradle:3.2.1'
}
to my Android Studio v3.0.1 in my case:
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
}
March 26, 2021:
Would not switch from Release to Debug,
File | Invalidate Caches fixed it for me
Unrelated to your build.gradle file,
Sharing hoping it might help someone else -
I was having similar issue it was because one of the line in build.gradle -
android {
...
publishNonDefault true // remove this line and it should work!
}
Here you can get more detail about publishNonDefualt -
It is also possible to publish all variants of a library. We are planning to allow this while using a normal project-to-project dependency (like shown above), but this is not possible right now due to limitations in Gradle (we are working toward fixing those as well).
Publishing of all variants are not enabled by default. The snippet below enables this feature:
I have an Android project (already ported to Android Studio and using Gradle) that is made up of different modules.
The project is actually used to create two different apps, where the code is pretty much the same, except for some resources.
Thus the resources have been split into two different modules.
The original author of this project used to work in Eclipse and switch the resource modules included in the dependencies based on which app he wanted to build. And he also used to change by hand the package name in AndroidManifest.xml
I would like to automate all of this and still have a single code base, but have two build targets with specific modules for each target. Is that doable with Gradle?
Update:
To make things even harder, my project has a hierarchy that is pretty much the following:
--+--MainProject
+--LibData
+--LibBase
+--LibResA
+--LibResB
Where:
MainProject depends on LibBase and LibData.
LibData depends on LibBase
LibBase either depends on LibResA or LibResB based on the final APK that I need to build.
As suggested, I've tried implementing this with flavors by adding in the MainProject build.gradle the following:
productFlavors {
producta {
}
productb {
}
}
And then in LibBase I've added the following to its build.gradle:
dependencies {
productaCompile project(':LibResA')
productbCompile project(':LibResB')
}
But then, when I build the project, LibData can't find the classes and resources inherited from LibBase. So now I'm stuck with this error. To me it looks like LibBase isn't being copied to the intermediates of LibData. That way LibData can't resolve the classes in LibBase, but it's just my assumption.
Update 2:
I kept investigating this issue and now I've changed my build.gradle files to look like this:
Main Project build.gradle:
defaultPublishConfig "productaRelease"
publishNonDefault true
productFlavors {
producta {
applicationId "com.producta"
}
productb {
applicationId "com.productb"
}
}
dependencies {
compile project(':LibData')
}
LibData build.gradle (has no product flavors, just the dependencies):
dependencies {
compile project(':LibBase')
}
LibBase build.gradle:
defaultPublishConfig "productaRelease"
publishNonDefault true
productFlavors {
producta {
}
productb {
}
}
dependencies {
productaCompile project(path: ':LibResA')
productbCompile project(path: ':LibResB')
}
This way I get no errors when doing the usual gradle clean build but I can see that the resources included are always those of LibResA just like the defaultPublishConfig is the only one used at all times.
If I open this project in Android Studio (0.8.1 atm) the result is that if I try to switch the build variant of the LibBase module and set it to productbRelease, the following error is being shown: Error:Module 'LibBase' has variant 'productbRelease' selected, but the module ''LibData'' depends on variant 'productaRelease'.
I'm running out of ideas.
Since you already have the product flavors:
productFlavors {
producta {
}
productb {
}
}
Define your dependencies prefixed with flavor name.
Example:
dependencies {
productaImplementation 'com.google.android.gms:play-services:11.0.2'
productbImplementation 'com.google.android.gms:play-services:12.0.1'
}
Common dependencies will be defined normally.
Now build apk for individual flavors.
Not the best way to do it, but if productFlavors is not enough to specify conditional dependencies you can rely on an inline if and evaluate it based on some value that can be injected via external properties.
For example here is how I toggle LeakCanary (no-op is just the empty implementation of the other one):
build.gradle
dependencies {
compile "com.squareup.leakcanary:leakcanary-android"+(project.ext.has("leakCanary")?"":"-no-op")+":1.3.1"
}
To build with com.squareup.leakcanary:leakcanary-android:1.3.1:
$ ./gradlew :app:assembleDebug -PleakCanary
By default it builds with the empty implementation com.squareup.leakcanary:leakcanary-android-no-op:1.3.1:
$ ./gradlew :app:assembleDebug
This provides a quick and more flexible way to toggle things using build command, but too much of it and things will get messy real quick.
Yes, it is. New Android build system based on Gradle supports your use case with its concept of product flavors. http://tools.android.com/tech-docs/new-build-system/user-guide
Note that you will likely want to switch from Eclipse to Android Studio when you do migration to Gradle build.