Wear App and with custom build type with applicationIdSuffix

Question

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 applicationIdSuff

Answer 1

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

Answer 2

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')

Answer 3

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:

1. 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
2. gradle check fails because of reason 1
3. 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

Answer 4

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.