Wear App и с пользовательским типом сборки с applicationIdSuffix

У меня есть приложение, где я бы хотел добавить расширение приложения для Android Wear. Основное приложение имеет три типа сборки (debug, beta и release). Бета-сборки имеют applicationIdSuffix, что позволяет мне устанавливать версию play-store и текущую версию разработки параллельно на одном устройстве. Все это отлично работало, пока я не добавил приложение для ношения.

Основное приложение build.gradle выглядит следующим образом:

apply plugin: 'com.android.application'

android {
    ...
    defaultConfig {
        ...
        applicationId "com.example.mainApp"
        ...
    }
    buildTypes {
        debug {
            applicationIdSuffix '.debug'                
        }
        beta {
            applicationIdSuffix '.beta'
        }
        release {
        }
    }
}

dependencies {
    ...
    wearApp project(':wear')
}

Wear-App имеет те же типы сборки, что и те же самые значения applicationIdSuffix. Однако, когда я создаю бета-приложение (вызывая gradle assembleBeta), процесс сборки строит :wear:assembleRelease вместо :wear:assembleBeta, поэтому я получаю следующее сообщение об ошибке во время сборки:

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.

Как я могу сказать, что процесс сборки создает правильный тип сборки при упаковке основного приложения с типом сборки beta?

ОТВЕТЫ

Ответ 1

Следуя ссылке, опубликованной Скоттом Бартой (http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication), я придумал следующее:

В build.gradle приложения для изнашивания добавьте publishNonDefault true (чтобы опубликовать все варианты):

android {
    publishNonDefault true
}

В build.gradle основного приложения,
Заменить

wearApp project(':wear')

По

debugWearApp project(path:':wear', configuration: 'debug')
releaseWearApp project(path:':wear', configuration: 'release')

Ответ 2

Вы не можете делать то, что хотите; вариант сборки модуля не распространяется на сборки зависимых модулей при сборке. Это отслеживается в https://code.google.com/p/android/issues/detail?id=52962

Здесь есть возможность сделать один модуль зависимым от конкретного варианта другого, как описано в http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication, но я не подумайте, что этот механизм можно расширить, чтобы сделать дифференциальную упаковку приложений Wear.

Ответ 3

UPDATE Теперь есть официальная поддержка вариантов сборки (см. Ответ Кирилла Леру). Следовательно, этот ответ устарел.

Я нашел очень (очень) уродливое решение, которое имеет некоторые недостатки, но работает до сих пор, пока не будет поддержки вариантов сборки для ношения приложений.

Я устанавливаю глобальную переменную в файле rootProject, который содержит applicationIdSuffix текущего встроенного основного приложения.

В build.gradle приложения main я добавил следующее:

// 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
    }
}

В build.gradle приложения изнашиваться я добавил следующие снимки:

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
        }
    }
}

Это имеет несколько недостатков:

  • Вы не можете создавать несколько вариантов (т.е. gradle assembleBeta assembleRelease), потому что приложение для изнашивания создается только один раз и, следовательно, второй тип сборки терпит неудачу.
  • gradle check не удается из-за причины 1
  • Приложение для ношения по-прежнему построено с типом сборки release, но имя пакета просто изменено в соответствии с суффиксом идентификатора приложения основного приложения.

Ответ 4

Не беспокойтесь, вы МОЖЕТЕ делать то, что хотите. Я просто сделал это для корпоративного приложения, над которым я работаю.

Ключ НЕ использовать проект wearApp (': wear'), так как это работает только тогда, когда вы используете одно приложение в своем приложении для ношения в качестве основного приложения. И пусть сталкиваются с этим, как часто в реальной жизни происходит такая ситуация? Если это произойдет, вы, вероятно, не используете Gradle, насколько это возможно.

Вы хотите следовать инструкциям для пакета вручную в документах google google https://developer.android.com/training/wearables/apps/packaging.html#PackageManually

К сожалению, это потребует от вас создания вашего приложения для ношения с тем же приложением, что и конкретный вариант сборки, который вы делаете в то время, но это позволяет вам успешно упаковать приложение для ношения в приложении с несколькими приложениями.

Кроме того, один трюк, который я делаю, помогает не помещать носок apk внутрь /res/raw, но в /assets, таким образом вам не нужно иметь дело с Andriod Studio, сжимающим apk.

Надеюсь, это поможет! В течение пары дней я сумасшедший, нашел решение. И единственный учебник на французском языке, и мне пришлось перевести сайт, чтобы прочитать его! 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