studio - ¿Cómo cambiar el nombre del paquete de la aplicación Android al ensamblar con Gradle?

id de aplicacion android

Question

¿Es posible cambiar el nombre del paquete de una aplicación de Android usando Gradle?

Necesito compilar dos copias de la misma aplicación, con un nombre de paquete único (para poder publicar en el mercado dos veces).

Answer 1

Como una alternativa más simple al uso de sabores del producto que en la respuesta de Ethan , también puede personalizar los tipos de compilación .

Cómo elegir entre los enfoques:

• Si necesita diferentes nombres de paquetes para poder tener instalados tanto los depbs como los releases en un dispositivo, entonces use el siguiente método de compilación , como lo acuerdan los plugins de Gradle . En este caso, los sabores son una exageración. (Creo que todos los proyectos deben hacerlo de manera predeterminada, ya que hará la vida más fácil, especialmente después de que haya publicado en la tienda y esté desarrollando nuevas funciones).
• Existen usos válidos para los sabores de los productos , el ejemplo típico es una aplicación con versiones gratuitas y de pago. En tal caso, verifique la respuesta de Ethan y lea la documentación también: Configuración de Gradle Builds y Gradle Plugin User Guide .

(Supongo que también puede combinar los dos enfoques, lo que daría como resultado que cada variante de compilación tenga un nombre de paquete distinto, pero no lo he probado).

Configuración de tipo de compilación

Para el tipo de compilación de depuración , y todos los demás tipos no liberados , defina applicationIdSuffix que se agregará al nombre del paquete predeterminado. (Antes de Android Gradle plugin versión 0.11, esta configuración se conocía como packageNameSuffix ).

android {
    buildTypes {
        debug {
            applicationIdSuffix ''.debug''
            versionNameSuffix ''-DEBUG''
        }

        beta {
            applicationIdSuffix ''.beta''
            versionNameSuffix ''-BETA''

            // NB: If you want to use the default debug key for a (non-debug) 
            // build type, you need to specify it:
            signingConfig signingConfigs.debug 
        }

        release {
            // signingConfig signingConfigs.release
            // runProguard true
            // ...
        }

    }
}

Arriba, la debug y el release son tipos de compilación predeterminados cuyos aspectos están configurados, mientras que beta es un tipo de compilación completamente personalizado. Para construir los diferentes tipos, use assembleDebug , assembleBeta , etc., como de costumbre.

Del mismo modo, puede usar versionNameSuffix para anular el nombre de versión predeterminado de AndroidManifest (que me parece muy útil). Por ejemplo, "0.8" → "0.8-BETA", como se configuró anteriormente.

Recursos:

• Este ejemplo es directo de la presentación de " Google I / O 2013: el nuevo Android SDK Build System " de Xavier Ducrohet.
• Tipos de compilación en la Guía del usuario .

Yo mismo he estado usando productFlavors hasta ahora para este propósito exacto, pero parece que la personalización del tipo de compilación puede estar más cerca de mis necesidades, además de mantener la configuración de compilación más simple.

Actualización (2016) : Desde entonces he utilizado este enfoque en todos mis proyectos, y creo que definitivamente es el camino a seguir. También lo incluí en la guía de Android Best Practices de Futurice.

Answer 2

Con la versión del complemento Gradle de 1.0.0+, debe usar applicationId como se indica en la guía de migración.

Propiedades renombradas en ProductFlavors

packageName => applicationId

Por lo tanto, en tu build.gradle ahora usarías:

productFlavors {
   flavor1 {
      applicationId "com.example.flavor1"
   }

   flavor2 {
      applicationId "com.example.flavor2"
   } 
}

Answer 3

De la respuesta de Ethan, tanto flavorGroups como packageName ya no están disponibles. A continuación funciona a partir de marzo de 2015.

android {
...

defaultConfig {
    minSdkVersion 8
    versionCode 10
}

flavorDimensions "flavor"

productFlavors {
    flavor1 {
        flavorDimension "flavor"
        applicationId "com.example.flavor1"
        versionCode 20
    }

    flavor2 {
        flavorDimension "flavor"
        applicationId "com.example.flavor2"
        minSdkVersion 14
    }
}
}

Answer 4

Podrías algo como esto

android {
    ...

    defaultConfig {
        minSdkVersion 8
        versionCode 10
    }

    flavorDimensions "flavor1", "flavor2"

    productFlavors {
        flavor1 {
            applicationId "com.example.flavor1"
            versionCode 20
        }

        flavor2 {
            applicationId "com.example.flavor2"
            minSdkVersion 14
        }
    }
}

También puede cambiar el campo android.defaultConfig.applicationId si desea hacer compilaciones únicas.

Tomado de: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavor-Configuration