Error while generating release apk android studio [duplicate] - android

I have an app where I'd like to add an Android Wear app extension. The main app has three build types (debug, beta and release). Beta builds have an applicationIdSuffix which allows me to install the play-store version and the current development version in parallel on the same device. This all worked fine until I added the wear app.
The main app`s build.gradle looks like this:
apply plugin: 'com.android.application'
android {
...
defaultConfig {
...
applicationId "com.example.mainApp"
...
}
buildTypes {
debug {
applicationIdSuffix '.debug'
}
beta {
applicationIdSuffix '.beta'
}
release {
}
}
}
dependencies {
...
wearApp project(':wear')
}
The Wear-App has the same build types with the same applicationIdSuffix values. However, when I build the beta app (by calling gradle assembleBeta) the build process builds :wear:assembleRelease instead of :wear:assembleBeta which is why I get the following error message during build:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:handleBetaMicroApk'.
> The main and the micro apps do not have the same package name.
How can I tell the build process to build the correct build type when packaging the main app with build type beta?

Following the link posted by Scott Barta (http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication) I came up with this :
In the build.gradle of the wear app, add publishNonDefault true (to publish all variants):
android {
publishNonDefault true
}
In the build.gradle of the main app,
Replace
wearApp project(':wear')
By
debugWearApp project(path:':wear', configuration: 'debug')
releaseWearApp project(path:':wear', configuration: 'release')

You can't do what you want; the build variant of a module isn't propagated to the builds of dependent modules on build. This is tracked in https://code.google.com/p/android/issues/detail?id=52962
There's a facility to make one module depend on a specific variant of another one, as documented in http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication, but I don't think this mechanism can be extended to do differential packaging of Wear apps.

UPDATE
Now there is official support for build variants (see answer of Cyril Leroux). Hence this answer is deprecated.
I found a very (very) ugly solution which has some drawbacks but works for now until there is support for build variants for wear apps.
I set a global variable in the rootProject which contains the applicationIdSuffix of the currently built main app.
Within build.gradle of the main app I added the following:
// Set a global variable, depending on the currently built build-type.
// This allows us to set the applicationIdSuffix of the wear app depending on
// the build-type of the main app.
android.applicationVariants.all { variant ->
def task = variant.checkManifest
def suffix = variant.buildType.applicationIdSuffix
task.doLast {
rootProject.ext.currentApplicationIdSuffix = suffix
}
}
In the build.gradleof the wear app I added the following snipped:
android.applicationVariants.all { variant ->
def task = variant.generateBuildConfig
task.dependsOn(propagateApplicationIdSuffix)
}
task propagateApplicationIdSuffix << {
project.android.buildTypes.all { type ->
if (rootProject.hasProperty('currentApplicationIdSuffix')) {
type.applicationIdSuffix = rootProject.ext.currentApplicationIdSuffix
}
}
}
This has several drawbacks:
You can't build multiple variants (i.e. gradle assembleBeta assembleRelease) because the wear app is only built once and hence the second build type fails
gradle check fails because of reason 1
The wear app is still built with build type release but the package name is just changed according to to application id suffix of the main app

Don't worry, you CAN do what you want to do. I just did it for the enterprise app I work on.
The key is NOT to use wearApp project(':wear'), since that only works when you have the same applicationId in your wear app as your main app. And let's face it, how often in real life does that situation happen? If it happens, you probably aren't using Gradle to the best of it's ability.
You want to follow the instructions for Package Manually in the google wear docs
https://developer.android.com/training/wearables/apps/packaging.html#PackageManually
Unfortunately, this will require you to build your wear app with the same applicationId as the particular build variant you are making at the time, but it does allow you to successfully package the wear app inside an app with multiple applicationId.
Also, one trick I do that helps is to not put the wear apk inside /res/raw, but in /assets, that way you don't have to deal with Andriod Studio compressing the apk.
Hope this helps! Drove me crazy for a couple days finding a solution. And the only tutorial out there is in French, and I had to translate the website to read it!
https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fblog.octo.com%2Fpackager-une-application-android-wear-dans-la-vraie-vie%2F

Related

Why does Android Studio want the debug version of a library in a release build?

Why does a release build complain about a missing debug library?
In order to verify that a release version of an app uses only the release components, I deleted the debug variants of some externally-built libraries, and then tried building the release version of the app. The build variant 'release" is selected, yet the build stops immediately with this error: 'Expecting a file or a directory: theLibrary-debug.aar'.
When theLibrary-debug.aar is present, the release version of the app builds fine, and shows up in its correct place. The app behaves correctly, with release variants in behavior also, so it appears that the build completes correctly, and that the debug library isn't used.
So why does the release build complain about the missing debug library? Is this a normal build behavior in Android Studio (version 4.1.1) or does this require further investigation?
With the names changed, the relevant parts of the app's build.gradle look like this:
...
android {
...
buildTypes {
release {
...
}
debug {
...
}
}
...
}
dependencies {
debugImplementation files ('theLibrary-debug.aar')
releaseImplementation files ('theLibrary-release.aar')
}
P.S. The Module Settings view in Android Studio is awful, and it only makes sense to work in the gradle files, as far as I can see. Any one of the many Eclipse IDEs out there does this sort of settings work much better. Maybe some of the more recent Android Studio versions have some improvements...

Version name and code from files with gradle plugin 3

My android build is set to use a versionName and versionCode from a file in release mode. They are set to static values when not creating a release build to keep incremental builds working.
The relevant parts of the gradle file are:
android {
defaultConfig {
versionCode 1
versionName "1.0"
// SNIP...
}
applicationVariants.all { variant ->
if (variant.buildType.name == "release") {
variant.versionCode = file('version-code.txt').text as int
variant.versionName = file('version.txt').text
}
}
// SNIP ...
}
Example contents of the version files could be:
version.txt: 0.7
version-code.txt: 7
This was done by following the Use static build config values with your debug build section in the recommended guidelines for keeping incremental builds working.
For example, using dynamic version codes, version names, resources, or any other build logic that changes the manifest file requires a full APK build every time you want to run a change—even though the actual change might otherwise require only a hot swap. If your build configuration requires such dynamic properties, then isolate them to your release build variants and keep the values static for your debug builds, as shown in the build.gradle file below.
However, we've found this has broken since upgrading to version 3 of the gradle plugin this no longer works. The Modifying variant outputs at build time may not work section of the gradle plugin 3.0.0 migration guide says:
Using the Variant API to manipulate variant outputs is broken with the new plugin. It still works for simple tasks, such as changing the APK name during build time, as shown below:
However, more complicated tasks that involve accessing outputFile objects no longer work. That's because variant-specific tasks are no longer created during the configuration stage. This results in the plugin not knowing all of its outputs up front, but it also means faster configuration times.
There doesn't seem to be any alternative recommended in the migration guide. Is there another way this can be achieved?
UPDATE
Thanks to the answer from #nhoxbypass, changing my gradle file to contain following got things working again:
applicationVariants.all { variant ->
if (variant.buildType.name == "release") {
variant.outputs.all { output ->
output.setVersionNameOverride(file('version.txt').text)
output.setVersionCodeOverride(file('version-code.txt').text as int)
}
}
}
The migration guide still works for simple tasks, such as changing the APK name during build time (at least worked for my project). However, more complicated tasks that involve accessing outputFile objects no longer work.
But if you need to try a workaround there is one existing before the 3.0 release, if anybody is looking for a solution, you can use:
output.setVersionCodeOverride(Integer.parseInt(buildTimeSmall()))
See: Unable to change project versionCode for different build types

Unable to switch to debug build variant in Android Studio

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:

Gradle does not distinguish between buildType release and debug

I have a gradle build i need to have different configurations based whether it is a release or debug build.
The problem is that the gradle build does not distinguish between those two.
for example :
apply plugin: 'com.android.library'
android {
compileSdkVersion 22
buildToolsVersion "22.0.1"
buildTypes {
debug {
println 'debug'
}
release {
println 'release'
}
}
}
When i build using 'gradle assembleRelsease' or using 'gradle assembleDebug', it prints both 'release' and 'debug' in both cases or even when i build using debug (from Build Variants) in android studio. It simply does not distinguish it. What i would excpect is when i build release it only prints 'release' and when i build degub it only prints 'debug'. Does any body have a solution to this problem ? am i do doing something wrong?
Your script will produce the expected results (different .aar's) for debug and release library variants: it just prints everything all the time.
What you're encountering is the Gradle lifecycle, which goes through an Initialization, Configuration and Execution phase.
Since many build.gradle files (Android projects usually have at least 2) are used in the build process for different directories and subprojects, and you can define tasks after you use them in the ordering of the build file, I am guessing the first two phases perform scanning and analysis on the build files before actually building anything.
Configuration goes through all commands, including your println statement. (see this example) Maybe they've chosen to have println actually print during configuration to ease debugging.

Android Gradle Running Tests on Non-Debug Builds

I have a project with three different build types: debug, beta, and release. My test package is always created for debug builds, but QA uses the beta build and we want QA to run these tests on their vast array of devices.
I'm trying to create a testing apk for QA that is signed by the same key as the beta build. Looking through the Android-Gradle documentation, I don't see anything telling me that I can't do this, but I don't see anyway to configure this. Is there anyway I can configure which keystore is used when assembling a test apk? Or is there a way to create an unsigned test apk?
You can now point this to a different target, I don't know when this happened, but from the docs:
Currently only one Build Type is tested. By default it is the debug
Build Type, but this can be reconfigured with:
android {
...
testBuildType "staging"
}
This is an incomplete answer to your question in that it documents what you can't do, but the connectedAndroidTest task, which is what runs the androidTest tests in your project, is hardcoded to run against the debug build type, and I don't see a way to point it at a different build type.
Taking the advice from Is there a way to list task dependencies in Gradle? and examining the task dependency tree, if you run:
./gradlew tasks --all
you get this in your output:
Verification tasks
------------------
app:check - Runs all checks. [app:lint]
app:connectedAndroidTest - Installs and runs the tests for Build 'debug' on connected devices. [app:assembleDebug, app:assembleDebugTest]
app:connectedCheck - Runs all device checks on currently connected devices. [app:connectedAndroidTest]
app:deviceCheck - Runs all device checks using Device Providers and Test Servers.
The documentation for the connectedAndroidTest task claims it runs tests against debug, and the task dependencies (which you see with the -all flag) confirm that the task depends on assembleDebug.
Adding additional build types and flavors doesn't seem to affect the dependency on the built-in debug type.
It's possible that with greater Gradle-fu than mine, you could rewire the tasks to make the tests depend on a different build type, but doing this is likely to be fragile since it's bound to depend on things that aren't supported API in the Android Gradle plugin.
To answer your question most directly, though, if all you want is to run tests against a build with a different certificate, you could change the signing config on your debug build to use the beta certificate:
android {
signingConfigs {
beta {
keyAlias 'key'
keyPassword 'password'
storeFile file('/path/to/beta_keystore.jks')
storePassword 'password'
}
}
buildTypes {
debug {
signingConfig signingConfigs.beta
}
beta {
signingConfig signingConfigs.beta
}
}
}
I tested it and I am able to run androidTest targets against debug builds that use a custom keystore in this way. However, I doubt this solves your problem, because I suspect you want to run your tests against the beta build, not a debug build with the beta certificate.
To add a testing source set for your build variant, follow these steps:
In the Project window on the left, click the drop-down menu and
select the Project view.
Within the appropriate module folder,
right-click the src folder and click New > Directory.
For the directory name, enter "androidTestVariantName." For example,
if you have a build variant called "MyFlavor" then the directory name
shoulbe "androidTestMyFlavor." Then click OK.
Right-click on the new directory and click New > Directory. Enter
"java" as the directory name, and then click OK.
Now you can add tests to this new source set by following the steps above to add a new test. When you reach the Choose Destination Directory dialog, select the new variant test source set.
The instrumented tests in src/androidTest/ source set are shared by all build variants. When building a test APK for the "MyFlavor" variant of your app, Gradle combines both the src/androidTest/ and src/androidTestMyFlavor/ source sets.
Another way is to put following line your in default config.
Currently only one Build Type is tested. By default it is the debug Build Type, but this can be reconfigured with:
android {
...
testBuildType "staging"
}

Categories

Resources