Android productFlavors传导

Android productFlavors

首先需要参考 Android官方对于 productFlavors的定义，以及在该定义下的能够实现的内容。
build variants

参考官方的gradle文件的配置信息

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        dev{
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension "version"
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        pre{
            dimension "version"
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
        prod {
            dimension "version"
            applicationIdSuffix ".prod"
            versionNameSuffix "-prod"
        }
    }
}

此时在配置完成之后
创建并配置产品变种后，点击通知栏中的 Sync Now。同步完成后，Gradle 会根据 build 类型和产品变种自动创建 build 变体，并按照 product-flavor Build-Type 为其命名。例如，如果您创建了“demo”和“full”产品变种，并保留了默认的“debug”和“release”build 类型，则 Gradle 会创建以下 build 变体：

1. devRelease
2. preDebug
3. prodRelease

如何实现 productFlavors配置信息在不同模块之间的穿透

我们常常有这样的诉求：希望能够在不同的Android模块之间统一些变量信息，诸如网络请求的host、统一的渠道id等等。但是productFlavors 的配置有个缺点就是，在android lib module当中不能单独的进行配置。而且即便是通过一定的技术手段实现了之后，也很难做到统一的改变其中一个，进而实现另外一个的改变。
这里根据gradle的tasks的register的思想，给出如下配置。
1 在app module的gradle当中实现productFlavors的配置

    flavorDimensions "env"
    productFlavors {
        dev {
            dimension "env"
        }
        pre {
            dimension "env"
        }
        prod {
            dimension "env"
        }
    }

接着在不同的其他module当中register该productFlavors

    flavorDimensions "env"
    productFlavors {
        register("dev")
        register("pre")
        register("prod")
    }

实现效果如下图所示：
当在Build Variant标签当中进行切换productFlavors时，其他所有的productFlavors都会随着改变。