在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
————————————————
版權聲明:本文爲CSDN博主「hongszh」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/hongszh/article/details/106657535