在build.gradle里面通过productFlavors就可以方便的实现不同的编译方案。

flavorDimensions定义维度

flavorDimensions 从单词字面理解知道是 “风味维度”，是需要结合 “产品风味(即productFlavors)” 来一起使用的。flavorDimensions 的使用会定义出维度，供接下来的 productFlavors 使用。

android {

// 省略其他参数

flavorDimensions('abi', 'version')

}

使用上面代码，则会定义出两个维度：version 和 abi。一个参数一个维度。

productFlavors的意义

productFlavors 从字面了解是“产品风味”。他需要和一个风味维度对接，否则会报错。

android{

// ...

flavorDimensions('abi', 'version')

// 创建产品风味

productFlavors {

v1 {

// 关联纬度

dimension 'version'

}

v2 {

dimension 'version'

}

x86 {

dimension 'abi'

}

armV7 {

dimension 'abi'

}

}

}

在 abi 维度上关联了两个产品，即 “armV7” 和 “x86”，在 version 的维度上关联了两个个产品，而这些维度的交织就会形成最终的风味，即我们上面所标出来的 “armV7V1”、“armV7V2”、“x86V1”、“x86V2”。

我们可以根据不同的风味，打出不同的apk包，便可以实现一套核心代码打出多个有些差异的包。

我的flavorDimensions & productFlavors

我的项目对abi不区分，只需要区分高通和mtk,所以维度就只定义了platform，cmake部分针对qcom和mtk分别定义了不同的宏，还可以指定其他native的参数。

flavorDimensions "platform"

productFlavors {

// Qualcomm platform

qcom {

dimension "platform"

externalNativeBuild {

cmake {

cppFlags "-std=c++11"

arguments "-DCMAKE_BUILD_TYPE=Release",

"-DUSE_QCOM=TRUE"

}

}

}

// mtk platform

mtk {

dimension "platform"

externalNativeBuild {

cmake {

cppFlags "-std=c++11"

arguments "-DCMAKE_BUILD_TYPE=Release",

"-DUSE_MTK=TRUE",

"-DCMAKE_ANDROID_NDK=\$(System.getenv('ANDROID_NDK_HOME'))"

}

}

}

}

实验证明上面的"-DCMAKE_ANDROID_NDK=$(System.getenv('ANDROID_NDK_HOME'))"不生效的。换成"-DANDROID_NDK=/home/tools/android-ndk/android-ndk-r19c"这样的绝对路径也不行。

只有通过修改local.properties才可以，可以通过编译脚本修改ndk.dir。

#!/usr/bin/env bash

#set build ndk to android-ndk-r19c

ndkdir=${ANDROID_NDK}

echo "ndk.dir=${ndkdir}" >> local.properties

# clean

./gradlew clean

# build qcom

./gradlew assembleqcomRelease

# build mtk

./gradlew assemblemtkRelease

参考：

https://blog.csdn.net/weixin_37625173/article/details/100867037