1-> Custom HAR multi-objective construction products
Each HAR module supports customization of different targets, and the customization of device types (deviceType), resources, buildOption configuration items (such as C++ dependent .so, obfuscated configurations, abi types, cppFlags, etc.) and source code sets is implemented in the build-profile.json5 file in the module.
illustrate
In the current version, only modules whose target is default are supported when compiling in DevEco Studio. If you want to specify a different target, you need to specify it from the command line and compile it from the command line.
For example, to build a custom target:free harr, run the following command:
hvigorw --mode module -p product=default -p module=library@free -p buildMode=debug assembleHar
1.1 -> Define the deviceType of the product
Each target can be specified with or without deviceType. If it is not defined, the target supports the device type defined in config.json or module.json5 by default.
At the same time, when defining the deviceType of each target, the supported device types must have been defined in config.json or module.json5. For example, in the two targets defined above, default supports all device types by default, and the free version supports only 2-in1 devices.
{
"apiType": 'stageMode',
"buildOption": {
},
"targets": [
{
"name": "default" //未定义deviceType，默认支持config.json或module.json5中定义的设备类型
},
{
"name": "free",
"config": {
"deviceType": [ //定义free支持的设备类型为2in1
"2in1"
]
}
}
]
}
1.2 -> Define the C++ project dependencies. SO file
In a C++ project, you can customize the .so files that each target depends on. For example, a module depends on the function1.so, function2.so, and function3.so files, and the product with target is default depends on the function1.so and function2.so. If the target is a product of VIP and depends on function1.so and function3.so, the sample code is as follows:
{
"apiType": 'stageMode',
"buildOption": {
"externalNativeOptions": {
"path": "./src/main/cpp/CMakeLists.txt",
"arguments": [],
"abiFilters": [
"arm64-v8a",
"x86_64"
],
"cppFlags": "",
}
},
"targets": [ //定义不同的target
{
"name": "default",
"config": {
"buildOption": {
"nativeLib": {
"filter": {
//按照.so文件的优先级顺序，打包最高优先级的function1.so文件
"pickFirsts": [
"**/function1.so"
],
//排除不打包的function3.so文件
"excludes": [
"**/function3.so"
],
//允许当.so中资源重名冲突时，使用高优先级的.so文件覆盖低优先级的.so文件
"enableOverride": true
}
}
}
}
},
{
"name": "vip",
"config": {
"buildOption": {
"nativeLib": {
"filter": {
//按照.so文件的优先级顺序，打包最高优先级的function1.so文件
"pickFirsts": [
"**/function1.so"
],
//排除不打包的function2.so文件
"excludes": [
"**/function2.so"
],
//允许当.so中资源重名冲突时，使用高优先级的.so文件覆盖低优先级的.so文件
"enableOverride": true
}
}
}
}
}
]
}
1.3 -> Define the resources of the product
There may be differences in the resource files used by each target, and developers can store the resources used by each target in different resource directories during the development process. Among them, the ArkTS project supports customization of the resource file directory in the main directory. JS projects support customization of the resource file directory (resource) in the main directory and the resource file directory (res) in Ability. The following is an example of customizing the resource file directory of an ArkTS project:
{
"apiType": 'stageMode',
"buildOption": {
},
"targets": [
{
"name": "default",
"resource": { //定义默认版target使用的资源文件目录
"directories": [
"./src/main/resources_default"
]
}
},
{
"name": "free",
"config": {
"deviceType": [
"2in1"
]
},
"resource": { //定义免费版target使用的资源文件目录
"directories": [
"./src/main/resources_default",
"./src/main/resources_free"
]
}
},
]
}
2 -> Configure the APP multi-objective build product
APP is used for the release of applications/meta-services, and different products can be customized for different application scenarios, and each product supports customization of bundleName, bundleType, signature information, icon and label, and the target included.
Define the target product
Each product corresponds to a customized APP package, so the name of the product that needs to be customized should be planned in advance before customizing the APP multi-target construction product. For example, define productA and productB. An example of the project-level build-profile.json5 file is as follows:
When customizing a product, there must be a "default" product, otherwise there will be an error when compiling.
"app": {
"signingConfigs": [],
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
},
{
"name": "productA",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
},
{
"name": "productB",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
}
],
"buildModeSet": [
{
"name": "debug",
},
{
"name": "release"
}
]
}
2.1 -> Define the APP package name and supplier name of the product
Each product can be specified with a product name and a supplier name.
{
"app": {
"signingConfigs": [],
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"output": {
"artifactName": "customizedProductOutputName-1.0.0" //产物名称为customizedProductOutputName-1.0.0
},
"vendor": "customizedProductVendorName" //供应商名称为customizedProductVendorName
},
{
"name": "productA",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"output": {
"artifactName": "customizedProductOutputNameA-1.0.0" //产物名称为customizedProductOutputNameA-1.0.0
},
"vendor": "customizedProductVendorNameA" //供应商名称为customizedProductVendorNameA
},
{
"name": "productB",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"output": {
"artifactName": "customizedProductOutputNameB-1.0.0" //产物名称为customizedProductOutputNameB-1.0.0
},
"vendor": "customizedProductVendorNameB" //供应商名称为customizedProductVendorNameB
}
],
"buildModeSet": [
{
"name": "debug",
},
{
"name": "release"
}
]
},
}
If a signature has been configured, the APP package name corresponding to the product is the name customized by the developer. If no signature is configured, the app package name corresponding to the product is the customized name + unsigned.
2.2 -> Define the bundleName of the product
Different bundleNames can be customized for each defined product, and if the product does not have a bundleName, the default bundleName of the project is used. An example is shown below:
"app": {
"signingConfigs": [],
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example00.com" //定义default的bundleName信息
},
{
"name": "productA",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example01.com" //定义productA的bundleName信息
},
{
"name": "productB",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example02.com" //定义productB的bundleName信息
}
],
"buildModeSet": [
{
"name": "debug",
},
{
"name": "release"
}
]
}
2.3 -> Define the bundleType of the product
Different bundleTypes can be customized for each defined product. Developers can define the product type by defining the bundleType of each product:
The bundleType value is app, which indicates that the product is an application.
The bundleType value is atomicService, indicating that the product is a metaservice.
If the product does not have a bundleType defined, the bundleType of the project (that is, the Application/Atomic Service selected when creating the project) is used. An example is shown below:
"app": {
"signingConfigs": [],
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example00.com",
"bundleType": "app" //定义default的bundleType信息
},
{
"name": "productA",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example01.com",
"bundleType": "atomicService" //定义productA的bundleType信息
},
{
"name": "productB",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example02.com",
"bundleType": "atomicService" //定义productB的bundleType信息
}
],
"buildModeSet": [
{
"name": "debug",
},
{
"name": "release"
}
]
}
2.4 -> Define the signature configuration information of the product
For each defined product, different signingConfig signature files can be customized, and if the product does not have a signingConfig defined, the unsigned APP package will be built.
In most cases, you first need to configure the signature information on the signature configuration page or in the build-profile.json5 file of the project. For example, on the File > Project Structure > Project > Signing Configs page, configure the signatures of default, productA, and productB, as shown in the following figure:
After the signature information is configured, add the signature file corresponding to each product, as shown in the following example:
You can also define the signature file information in the product in advance, and then sign each product on the signature page to ensure that the product signature file is the same as the signature file on the signature page.
"app": {
"signingConfigs": [], //此处通过界面配置签名后会自动生成相应的签名配置，本文略
"products": [
{
"name": "default",
"signingConfig": "default", //定义default的签名文件信息
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example00.com"
},
{
"name": "productA",
"signingConfig": "productA", //定义productA的签名文件信息
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example01.com"
},
{
"name": "productB",
"signingConfig": "productB", //定义productB的签名文件信息
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example02.com"
}
],
"buildModeSet": [
{
"name": "debug",
},
{
"name": "release"
}
]
}
2.5 -> Define the icon and label of the product
Different icons and labels can be customized for each defined product, and if the product does not have icons and labels defined, the default icons and labels of the project are used. An example is shown below:
illustrate
The icon and label fields in products will replace the corresponding fields in app.json5 at compile time, and both app.json5 and module.json5 can be configured.
{
"app": {
"signingConfigs": [],
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"icon":"$media:default_icon", //定义default的icon
"label":"$string:default_name", //定义default的label
},
{
"name": "productA",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"icon":"$media:productA_icon", //定义productA的icon
"label":"$string:productA_name", //定义productA的label
},
{
"name": "productB",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"icon":"$media:productB_icon", //定义productB的icon
"label":"$string:productB_name", //定义productB的label
}
],
"buildModeSet": [
{
"name": "debug",
},
{
"name": "release"
}
]
},
...
}
2.6 -> Define the target contained in the product
You can select the product to which you want to package the defined targets, and each product can specify one or more targets.
At the same time, each target can also be packaged into a different product, but different targets of the same module cannot be packaged into the same product (unless different targets of the module are configured with different deviceType or distributionFilter/distroFilter).
For example, if you have defined default, free, and pay, you need to package the default target into the default product. Package the free target into productA; Package the pay target into productB, and the corresponding sample code is as follows:
{
"app": {
"signingConfigs": [], //此处通过界面配置签名后会自动生成相应的签名配置，本文略
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example00.com"
},
{
"name": "productA",
"signingConfig": "productA",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example01.com"
},
{
"name": "productB",
"signingConfig": "productB",
"compatibleSdkVersion": "5.0.2(14)",
"runtimeOS": "HarmonyOS",
"bundleName": "com.example02.com"
}
],
"modules": [
{
"name": "entry",
"srcPath": "./entry",
"targets": [
{
"name": "default", //将default target打包到default APP中
"applyToProducts": [
"default"
]
},
{
"name": "free", //将free target打包到productA APP中
"applyToProducts": [
"productA"
]
},
{
"name": "pay", //将pay target打包到productB APP中
"applyToProducts": [
"productB"
]
}
]
}
]
}
3 -> Multi-product construction target
align target: the target with the highest priority during compilation and build. After the align target is configured in the project, if the align target exists in the module, the align target is automatically selected for construction. The scope of align target is the entire project, and only one can be configured, and it supports two modes: command line and configuration file.
The following is an example of a command-line approach:
hvigorw -c properties.ohos.align.target=target1 assembleHap
Add ohos.align.target to the hvigor-config.json5 configuration file, as shown below:
"properties": {
'ohos.align.target': 'target1'
},
fallback target: If the module does not have a specified target, default will be used to build, but if you do not want to use default to build, you can configure a fallback target, and if the specified target cannot be found, if there is a fallback target in the module, the fallback target will be used to build. The scope of the fallback target is the entire project, which can be configured with multiple items, and when multiple are configured, the first hit will take effect in the order of the array.
The following is an example of a command-line approach:
hvigorw -c properties.ohos.fallback.target=target1,target2 assembleHap
Add ohos.fallback.target to the hvigor-config.json5 configuration file, as shown below:
"properties": {
'ohos.fallback.target': ['target1', 'target2']
}
illustrate
The align target and fallback target configuration mode take precedence over the configuration file.
If you use a configuration file to configure align target and fallback target, you can use the HDC command line to push and run packages.
The priority order of multiple targets is as follows: align target > the command line specifies the module target > the parent module target > fallback target > default.
Illustrate:
The project relies on entry->lib1->lib2 and needs to build multiple products A, B, and C.
entry: A、B、default
lib1: B、C、default
lib2: A、C、default
Set align target to A and fallback target to C. Then the compilation command when building the hap is:
hvigorw --mode module -p module=entry -c properties.ohos.align.target=A -c properties.ohos.fallback.target=C assembleHap
The target selection for compilation is: entry@A, lib1@C, lib2@A.
illustrate
All of the above instructions are for non-ohosTest mode only. In ohosTest mode, the dependent target is fixed to default, and no other targets take effect.
Top comments (0)