android - paquete - Use la aplicación y con el tipo de compilación personalizado con applicationIdSuffix

generate signed apk

Question

Tengo una aplicación en la que me gustaría agregar una extensión de la aplicación Android Wear. La aplicación principal tiene tres tipos de compilación (depuración, beta y versión). Las versiones Beta tienen un applicationIdSuffix que me permite instalar la versión de Play Store y la versión de desarrollo actual en paralelo en el mismo dispositivo. Todo esto funcionó bien hasta que agregué la aplicación de desgaste.

La aplicación principal build.gradle se ve así:

apply plugin: ''com.android.application''

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

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

La aplicación Wear tiene los mismos tipos de compilación con los mismos valores de applicationIdSuffix. Sin embargo, cuando gradle assembleBeta la aplicación beta (al llamar a gradle assembleBeta ), el proceso de compilación genera :wear:assembleRelease lugar de :wear:assembleBeta por eso recibo el siguiente mensaje de error durante la compilación:

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.

¿Cómo puedo indicar el proceso de compilación para compilar el tipo de compilación correcto al empaquetar la aplicación principal con el tipo de compilación beta ?

Answer 1

No puedes hacer lo que quieres; la variante de compilación de un módulo no se propaga a las compilaciones de módulos dependientes en la compilación. Esto se rastrea en https://code.google.com/p/android/issues/detail?id=52962

Existe la posibilidad de que un módulo dependa de una variante específica de otro, como se documenta en http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication , pero No creo que este mecanismo pueda extenderse para hacer un empaquetado diferencial de las aplicaciones Wear.

Answer 2

No te preocupes, PUEDES hacer lo que quieras hacer. Acabo de hacerlo para la aplicación empresarial en la que trabajo.

La clave es NO usar el proyecto wearApp ('': wear''), ya que solo funciona cuando tienes el mismo applicationId en tu aplicación de desgaste como tu aplicación principal. Y seamos sinceros, ¿con qué frecuencia en la vida real ocurre esa situación? Si sucede, probablemente no estés usando Gradle de la mejor manera posible.

Desea seguir las instrucciones para Empaquetar manualmente en los documentos de Google Wear https://developer.android.com/training/wearables/apps/packaging.html#PackageManually

Desafortunadamente, esto requerirá que genere su aplicación de desgaste con la misma aplicación que la variante de construcción particular que está creando en ese momento, pero le permite empaquetar con éxito la aplicación de desgaste dentro de una aplicación con múltiples Id.

Además, un truco que hago que ayuda es no poner el apk de desgaste dentro / res / raw, pero en / asset, de esa manera no tienes que lidiar con Andriod Studio comprimiendo el apk.

¡Espero que esto ayude! Me volví loco por un par de días encontrando una solución. Y el único tutorial que hay en francés, ¡y tuve que traducir el sitio web para leerlo! 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 3

Siguiendo el enlace publicado por Scott Barta ( http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication ) se me ocurrió esto:

En el build.gradle de la aplicación de desgaste, agregue publishNonDefault true (para publicar todas las variantes):

android {
    publishNonDefault true
}

En el build.gradle de la aplicación principal,
Reemplazar

wearApp project('':wear'')

Por

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

Answer 4

ACTUALIZACIÓN Ahora hay soporte oficial para las variantes de compilación (ver respuesta de Cyril Leroux ). De ahí que esta respuesta quede en desuso.

Encontré una solución muy (muy) fea que tiene algunos inconvenientes pero funciona por ahora hasta que haya soporte para variantes de compilación para aplicaciones de desgaste.

Establecí una variable global en rootProject que contiene el applicationIdSuffix de la aplicación principal actualmente construida.

Dentro de build.gradle de la aplicación principal , agregué lo siguiente:

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

En el build.gradle de la aplicación de desgaste agregué el siguiente recorte:

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

Esto tiene varios inconvenientes:

1. No puede compilar múltiples variantes (es decir, gradle assembleBeta assembleRelease ) porque la aplicación de desgaste solo se gradle assembleBeta assembleRelease una vez y, por lo tanto, el segundo tipo de compilación falla
2. gradle check falla debido a la razón 1
3. La aplicación de desgaste aún se construye con la versión de tipo de compilación, pero el nombre del paquete solo se cambia de acuerdo con el sufijo de id de la aplicación principal