viernes, junio 10, 2016

Build Variants | Variantes de compilación de Android Studio.

Android Studio es una herramienta maravillosa con muchas características que facilitan el desarrollo de nuestras aplicaciones.

Hoy les quiero hablar sobre las variantes de compilación, o Build Variants en inglés. Quizá no sea la mejor traducción pero es la que me parece correcta.

Las variantes de compilación te permiten generar diferentes versiones de tu aplicaciones según sea la necesidad de tu proyecto. El ejemplo que tiene la documentación de Android sería una aplicación que tiene la versión full y la versión demo. Voy a crear estas dos variantes de compilación en el siguiente tutorial.

Una vez creado nuestro proyecto, lo primero que vamos a hacer es abrir la configuración del módulo de la aplicación. Hacemos clic derecho en app -> Open Module Settings o en Mac, presionamos Command + Flecha hacia abajo.

Open Module Settings

Esto nos mostrará el dialogo de la estructura del proyecto.

Project Structure

Este dialogo tiene las pestañas Properties, Signing, Flavors, Build Types y Dependencies. Voy a explicar un poco para qué es cada pestaña

Properties

Sirve para configurar las propiedades del proyecto.

Compile SDK Version. Aquí seleccionamos la versión del SDK de compilación, para este ejemplo estoy usando 6.0 Marshmallow.
Build Tools Version. La versión de Android build tools.
Library Repository. Esto no se qué hace. Lo dejamos en blanco
Ignore Assets Pattern. Tampoco sé qué hace. Lo dejamos en blanco
Incremental Dex, true o false para activar o desactivar la compilación incremental dex
Source compatibility, Es la versión de java mínima.
Target compatibility, Es la versión de java que se usará en el proyecto. 

Estas dos últimas por defecto son la 1.7 pero si queremos por ejemplo desarrollar para android N y java 8, podríamos seleccionar target compatibility en 1.8 

Signing 

Sirve para configurar los certificados con los que se firmará la aplicación. Les describo un ejemplo de su uso.

Para la empresa donde trabajo uno de sus clientes tiene configurado su perfil de desarrollador en Google Play, y la compañía también. Cuando el cliente sube la aplicación a Google Play hay que firmar la app con el certificado que ellos usaron inicialmente. En la empresa tenemos la misma aplicación para propósitos de pruebas pero firmada con otro certificado. Recuerden que una vez subida una aplicación a Google Play siempre se tiene que firmar la app con el mismo certificado, sino Google Play nos va mostrar un error como este


Dicho esto, vamos a tener el caso hipotético que necesitamos que la versión full tenga un certificado y la versión demo tenga otro. 

Para agregar los certificados, le damos clic al botón más y llenamos los datos que se pide.

Certificado para la versión demo

Certificado para la versión Full
Key Alias, es el alias del certificado
Key Password, el password del certificado
Store File, la ubicación del certificado, en este caso la agregué dentro del directorio app/ luego esto se reemplazará, en el .gradle
Store password, el password del key store, usualmente utilizo el mismo que el key password.

Para saber como crear los certificados desde Android Studio ve el post Crear certificados desde Android Studio (aún no lo he escrito)

Flavors



Aquí viene lo divertido, es donde crearemos los sabores o Flavors de nuestra aplicación. Hay una fórmula que dice.
Flavor + Build Type = Build Variant.
La fórmula lo que quiere decir es que por cada Flavor y Build Type obtendremos un Build Variant. 

Comenté que la aplicación tendría dos variantes: Demo y Full. En esta pestaña definimos estos valores, por defecto todos los proyectos tienen un Flavor llamado defaultConfig es importante saber que NO debemos borrar este Flavor, puesto que los demás van a heredar de defaultConfig.

Para agregar un Flavor, hacemos clic en el botón de más y llenamos los datos que nos pide.

Flavor demo

Flavor full

 Cada campos significa lo siguiente. 

Name, nombre del Flavor
Min SDK version, al estar definido en defaultConfig, los demás Flavors no tienen por qué llenarse a menos, que estemos creando una versión de la aplicación específica para una versión de Android.
Application Id, para que nuestra app se compile con diferente id. Si se fijan en las dos imágenes anteriores, los id son com.pedrovarela.android.demo com.pedrovarela.android.full 
Proguard File, es el archivo Pro Guard que se usa para reducir el tamaño de la aplicación eliminado código y recursos que no se utilizan para más información lee Shrink Your Code and Resources.
Signing Config, el certificado con el que se firmara cada versión, estos los creamos anteriormente.
Target Sdk Version, la versión máxima de android en la que correrá nuestra app, la dejamos en blanco puesto que ya está definida en defaultConfig, a menos claro, que sea un caso específico. 
Test Instrumentation Runner, esto es nuevo pero es para configurar pruebas unitarias 
Test Application Id, el id de la app para las pruebas.
Version Code, el código de versión.
Version Name, el nombre de la versión.
Version Name Suffix, el sufijo del nombre de la versión.

Les comenté sobre la compañía donde trabajo y uno des sus clientes, version code y version name pueden ser diferentes para cada caso, la versión de producción del cliente es las 2.0 pero nuestra versión interna iba por la versión 12, esto lo pueden modificar aquí, si van a mantener la misma versión para todas las variantes sencillamente se modifica en defaultConfig y dejamos la de los Flavors en blanco.

Build Types


Los Build Types son los tipos de compilado, siempre tendremos estos dos, no hay necesidad de agregar más. Tenemos debug, que se usa para las versiones para debug, por ejemplo la app mostraría la información del log si usamos adb, y la tipo release que se usa para la versión de producción.

No hay necesidad de cambiar nada aquí, a menos que seas un usuario avanzado y sepas lo que estás haciendo. 

Dependencies

Las dependencias y librerías de nuestro proyecto


Bien, ya tenemos configurado nuestro proyecto para trabajar con build variants, pero, eso no est todo amigos!!

Android studio no crea la estructura de directorios necesaria para que las variantes funcionen correctamente, lo que quiere decir que hay que agregarlas manualmente. Para esto, hacemos lo siguiente:


Cambiamos la vista del proyecto de Android a Project Files


Seleccionamos src, hacemos click derecho, y creamos un nuevo directorio. 


Para este ejemplo tenemos dos Flavours, así que serían dos directorios. Los directorios se tienen que llamar igual que los Flavours, es decir demo y full, quedando lo así.


Listo, ahora si tenemos todo casi listo para que nuestro proyecto funcione con Build Variants. En la imagen anterior vemos un archivo que se llama build.gradle.  Este archivo contiene todo lo que acabamos de configurar en el dialogo de la estructura del proyecto al abrirlo veremos algo como esto.



Si se fijan, tenemos todo los definido signingConfig, defaultConfig, buildTypes, productFlavors y dependencies. 

Bien, ahora cómo usamos todo esto. 

Supongamos que los nombres de nuestras aplicaciones tienen que ser diferentes para cada variante. Demo, se llamará Aplicación Demo, y Full se llamará Aplicación Full. 

Cada flavor puede tener sus propios archivos de strings, drawables, inclusive reemplazar actividades, fragmentos y clases. Para este ejemplo sencillo solo vamos a cambiar el nombre de la aplicación. ¿Qué hacemos? copiamos y pegamos los archivos que necesitamos en cada directorio del flavor, en este caso sería strings.xml. Es importante saber que todos los flavor tienen que reemplazar el archivo strings.xml. Por cierto, si hay algo que no queremos reemplazar o que se mantenga igual en ambos flavours, el directorio main es el principal (qué sería el que estuviésemos usando si no usamos los build variants) 

Una vez copiados y pegados los recursos que queremos abrimos cada strings.xml y modificamos el nombre,  quedando lo siguiente.



Para verificar que está funcionando, buscamos el panel que se llama Build Variants, yo lo tengo a la izquierda de Android Studio. Al abrirlo, vamos a ver dos columnas, Module y Build Variant. Aquí se aplica la fórmula que les comente anteriormente. Flavor + BuildType = BuildVariant. Tenemos entonces demoDebug, demoRelease, fullDebug, fullRelease.  Al seleccionar un Build Variant podemos ver automáticamente cambia todo. Abran el archivo main.xml y cambien de variant en variant para que vean como cambia el texto Hello World y el título de la actividad.

Aplicación Demo

Aplicaión Full

Listo ya esta todo funcional, si quieren correr la aplicación en su equipo, tienen que ver qué BuildVariant está seleccionada. La variante seleccionada es la que va a instalarse.

Al correr las dos variantes vemos en el equipo los dos iconos.



 


¿Cómo compilar las Build Variants?


Fácil, abrimos el terminal y escribimos (esto en Mac) ./gradlew assembleRelease


El resultado será los apk de las variantes de compilación. Los buscamos en

RutaDelProyecto/app/build/outputs/apk



Saludos, espero sus comentarios y les sea de utilidad. Código Fuente Aquí