¿Por qué los tipos de construcción son distintos de los sabores de productos?

Prefacio: no se trata de cómo usar tipos de compilación y sabores de productos en una aplicación de Android. Entiendo los conceptos básicos involucrados. Esta pregunta trata más acerca de tratar de comprender qué configuración debe especificarse en un tipo de compilación, qué configuración debe especificarse en un sabor de producto y si realmente es necesaria alguna distinción.

Esta semana, he estado aprendiendo más sobre la configuración de gradle para aplicaciones de Android. Inicialmente pensé que tenía un buen manejo de los tipos de compilación frente a los sabores de productos, pero cuanto más profundicé en la documentación, más me di cuenta de que la distinción entre los dos no estaba clara para mí.

Dado que existe una jerarquía bien definida (en el sentido de que las propiedades especificadas en los tipos de compilación tienen prioridad sobre las especificadas en los sabores de productos), no entiendo por qué es necesario distinguir entre los tipos de compilaciones y los sabores de productos. ¿No sería mejor fusionar todas las propiedades y métodos en el objeto DSL de sabor del producto y luego tratar el tipo de compilación como una dimensión de sabor (predeterminada)?

Algunos ejemplos concretos que llevaron a mi confusión:

• La signingConfigpropiedad se puede establecer tanto en tipos de compilación como en sabores de productos ... pero minifyEnabled(y, supongo shrinkResources,?) Solo se puede configurar en tipos de compilación.

• applicationId¿solo se puede especificar en sabores de productos ... y applicationIdSuffixsolo se puede especificar en tipos de compilación?

La (s) pregunta (s) real (es) :

Dados los ejemplos anteriores: ¿existe una clara distinción entre los roles de los tipos de compilación y los sabores de los productos?

Si es así, ¿cuál es la mejor manera de entenderlo?

Si no es así, ¿el plan es fusionar eventualmente los tipos de compilación y los sabores de productos en un único objeto DSL configurable?

Ampliando lo que @CommonsWare dijo en los comentarios, la idea básica es que los tipos de compilación son para diferentes compilaciones de su aplicación que no son funcionalmente diferentes: si tiene una versión de depuración y lanzamiento de su aplicación, son la misma aplicación , pero uno contiene código de depuración, quizás más registros, etc., y el otro está optimizado y optimizado y posiblemente ofuscado a través de ProGuard. Con sabores, la intención es que la aplicación sea notablemente diferente de alguna manera. El ejemplo más claro sería una versión gratuita frente a una versión paga de su aplicación, pero los desarrolladores también pueden diferenciar en función de dónde se distribuye (lo que podría afectar el uso de la API de facturación en la aplicación).

Hay desarrolladores que hacen muchas, muchas versiones diferentes de una aplicación similar para diferentes clientes; un ejemplo podría ser una aplicación simple que abre una página web en una vista web, con diferentes URL y marcas para cada versión; esta es una buen uso de sabores.

Para reiterar, si es "la misma aplicación", module algunas diferencias que no son importantes para el usuario final, y especialmente si todas las variantes, excepto una, son para su propio uso de pruebas y desarrollo y solo se implementará una variante en usuarios finales, entonces es un buen candidato para los tipos de compilación. Si se trata de una aplicación "diferente" y se implementarían múltiples variantes para los usuarios, entonces tal vez sea un candidato para un sabor de producto.

Ya ha visto que existen algunas diferencias de funcionalidad entre los tipos de compilación y los tipos, ya que algunas opciones son compatibles con una pero no con la otra. Pero los conceptos son diferentes a pesar de que son similares, y no hay ningún plan para fusionarlos.

buildType configura cómo empaquetamos nuestra aplicación

• shrinkResources
• progaurdFile
• etc.

Flavor configura diferentes clases y recursos.

• en Flavor1 su MainActivity puede hacer algo, y en Flavor2 diferentes implementaciones

• nombre de la aplicación diferente

• etc.

Cada sabor de producto puede tener sus propios valores de las siguientes propiedades, entre otras, que se basan en las mismas propiedades de defaultConfig:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

Así es como destilo la diferencia hasta su esencia:

• buildTypeEs el cómo de la construcción.
• flavorEs el qué de la construcción.

Se build typesutilizan para indicar el debug/releasemodo con diferentes certificados y habilitar Proguardodebuggable marca.

Se flavorsutilizan para tener características personalizadas (por ejemplo, versión gratuita o de pago), minimum and target APIniveles, requisitos de dispositivo y API como el layout, drawablepara que pueda tener diferentes códigos y recursos en diferentes flavors.