Trucos de código de versión de Android

Probemos esta opción. Primero configuraremos la aplicación y proporcionaremos 1 como versionCode por defecto y lo anularemos a 2 para todas las salidas variantes:

Pero luego si miramos dentro del archivo BuildConfig veremos que el código de versión sigue siendo 1. Aunque si miramos en el AndroidManifest resultante veremos que el código de versión está correctamente configurado a 2.
¿Fallo o característica? Averigüemos qué está pasando.

Dentro del código podemos acceder al código de la versión desde BuildConfig.VERSION_CODE o desde PackageManager.packageInfo.versionCode:

Después de ejecutar el código en Logcat veremos exactamente lo que hemos observado anteriormente:

La razón por la que esto ocurre es que en las herramientas de construcción de android gradle hay dos tareas separadas para generar el archivo BuildConfig y para procesar AndroidManifest.

Si miramos dentro de GenerateBuildConfig veremos que la propiedad VERSION_CODE se genera desde el método getVersionCode():

Y que getVersionCode hace referencia al valor almacenado en variantConfiguration:

A diferencia de la generación de BuildConfig en ProcessApplicationManifest vemos que el código de la versión se recupera de apkData.

Si comprobamos variantConfiguration y apkData antes y después de establecer el código de la versión anulado:

Veremos que el valor dentro de apkData de salida fue cambiado aunque el valor original en variantConfiguration sigue siendo el mismo (como se esperaba):

Como se indica en este tema se hace intencionadamente por motivos de rendimiento.

Conclusión

Tenga cuidado si utiliza setVersionCodeOverride ya que podría tener diferentes códigos de versión en BuildConfig y AndroidManifest.

Además, según la documentación, la forma recomendada de comprobar el código de la versión es acceder a él a través de PackageManager, no a través de BuildConfig:

Incluso es mejor tener la lógica de versionado fuera de build.gradle y proporcionarla a través del parámetro gradle por su CI.

También es una sabia elección no depender mucho en su código base de BuildConfig.VERSION_CODE. Para los casos de migración es mejor introducir su propio versionado local (como se hace con las bases de datos SQL).

¡Feliz codificación!