1 -> Configuration File Description (Java)
This section provides a detailed explanation of all the properties in the profile 'config.json'.
DevEco Studio provides two ways to edit "config.json" files. In the edit window of the config.json, you can switch between code editing view or visual editing view in the upper-right corner.
1.1 -> Internal structure of the configuration file
The config.json consists of three parts: app, deviceConfig, and module, all of which are indispensable.
1.2 -> The internal structure of the app object
The app object contains the global configuration information of the app.
App examples:
"app": {
"bundleName": "com.huawei.hiworld.example",
"vendor": "huawei",
"version": {
"code": 2,
"name": "2.0.0"
}
}
1.3 -> The internal structure of the deviceConfig object
deviceConfig contains application configuration information on a specific device, including default, phone, tablet, tv, car, wearable, liteWearable, and smartVision. The configuration in the default tag is applicable to all devices, and other device types need to be configured under the tag of the device type if they have special requirements.
Descriptions of the internal structure of objects such as default, phone, tablet, tv, car, wearable, liteWearable, and smartVision.
deviceConfig example:
"deviceConfig": {
"default": {
"process": "com.huawei.hiworld.example",
"supportBackup": false,
"network": {
"cleartextTraffic": true,
"securityConfig": {
"domainSettings": {
"cleartextPermitted": true,
"domains": [
{
"subdomains": true,
"name": "example.ohos.com"
}
]
}
}
}
}
}
1.4 -> The internal structure of the module object
The module object contains the configuration information of the HAP package.
module example:
"module": {
"mainAbility": "MainAbility",
"package": "com.example.myapplication.entry",
"name": ".MyOHOSAbilityPackage",
"description": "$string:description_application",
"supportedModes": [
"drive"
],
"deviceType": [
"car"
],
"distro": {
"deliveryWithInstall": true,
"moduleName": "ohos_entry",
"moduleType": "entry"
},
"abilities": [
...
],
"shortcuts": [
...
],
"js": [
...
],
"reqPermissions": [
...
],
"defPermissions": [
...
],
"colorMode": "light"
}
Distro example:
"distro": {
"deliveryWithInstall": true,
"moduleName": "ohos_entry",
"moduleType": "entry",
"installationFree": true
}
Example of metaData:
"metaData": {
"parameters" : [{
"name" : "string",
"type" : "Float",
"description" : "$string:parameters_description"
}],
"results" : [{
"name" : "string",
"type" : "Float",
"description" : "$string:results_description"
}],
"customizeData" : [{
"name" : "string",
"value" : "string",
"extra" : "$string:customizeData_description"
}]
}
Examples of abilities:
"abilities": [
{
"name": ".MainAbility",
"description": "himusic main ability",
"icon": "$media:ic_launcher",
"label": "HiMusic",
"launchType": "standard",
"orientation": "unspecified",
"permissions": [
],
"visible": true,
"skills": [
{
"actions": [
"action.system.home"
],
"entities": [
"entity.system.home"
]
}
],
"configChanges": [
"locale",
"layout",
"fontSize",
"orientation"
],
"type": "page"
},
{
"name": ".PlayService",
"description": "himusic play ability",
"icon": "$media:ic_launcher",
"label": "HiMusic",
"launchType": "standard",
"orientation": "unspecified",
"visible": false,
"skills": [
{
"actions": [
"action.play.music",
"action.stop.music"
],
"entities": [
"entity.audio"
]
}
],
"type": "service",
"backgroundModes": [
"audioPlayback"
]
},
{
"name": ".UserADataAbility",
"type": "data",
"uri": "dataability://com.huawei.hiworld.himusic.UserADataAbility",
"visible": true
}
]
Examples of skills:
"skills": [
{
"actions": [
"action.system.home"
],
"entities": [
"entity.system.home"
],
"uris": [
{
"scheme": "http",
"host": "www.xxx.com",
"port": "8080",
"path": "query/student/name",
"type": "text/*"
}
]
}
]
Example of shortcuts:
"shortcuts": [
{
"shortcutId": "id",
"label": "$string:shortcut",
"intents": [
{
"targetBundle": "com.huawei.hiworld.himusic",
"targetClass": "com.huawei.hiworld.himusic.entry.MainAbility"
}
]
}
]
1.5 - > Merge of HAP and HAR profiles
If HAR is invoked in the application module, you need to merge the config.json file of the HAP and the config.json file of one or more HARs into a single config.json file when compiling and building the HAP. During the merge process, the values of the same tag in different files may conflict, and you need to configure mergeRule to resolve the conflict.
1.5.1 -> Profile Merge Rules
When merging the HAP with the HAR config.json file, you need to merge all the HAR configuration information into the HAP configuration file.
HAP always takes precedence over HAR. When HAP depends on multiple HARs, the HARs loaded first have a higher priority than the HARs loaded later, and are merged into the HAP file in the order in which the HARs are loaded.
1.5.2 -> Use of the mergeRule object
mergeRule is usually used in the "config.json" file of HAP and can be added to properties such as abilities, defPermissions, reqPermissions, js, etc. Merge policies for different attributes.
note
The HAR configuration file cannot contain action.system.home and entity.system.home configuration items, otherwise a compilation error will be reported.
The value of the name field in the abilities object must be the full class name, otherwise the merge error will occur.
Examples of mergeRule usage:
In the following example, the name value of the ability in HAP and HAR is the same, and the ability in the config.json file of the two needs to be merged. Since some fields (e.g., launchType) in the two files conflict, you need to add mergeRule to the abilities tag of HAP.
- The "config.json" file of the pre-merge HAP as follows:
Remove indicates the subtags that need to be removed after the merge, and replace indicates the subtags that need to be replaced after the merge (HAP replaces the HAR).
"abilities": [
{
"mergeRule": {
"remove": ["orientation"],
"replace": ["launchType"]
}
"name": "com.harmony.myapplication.entry.MainAbility",
"type": "page",
"launchType": "standard",
"visible": false
}
],
- The "config.json" file of the pre-merge HAR as follows:
"abilities": [
{
"name": "com.harmony.myapplication.entry.MainAbility",
"type": "page",
"launchType": "singleton",
"orientation": "portrait",
"visible": false
}
],
- Merge the above two "config.json" files according to the mergeRule, and the mergeRule field will be removed after the processing is completed. The result file after the merge looks like this:
"abilities": [
{
"name": "com.harmony.myapplication.entry.MainAbility",
"type": "page",
"launchType": "standard",
"visible": false
}
],
1.5.3 -> Use of bundleName placeholders
The package name needs to be used in many places in the "config.json" file of the HAR, such as custom permissions and custom actions, but the package name can only be determined when the HAR is compiled to the HAP. Before compilation, package names in HAR can be represented as placeholders, in the form of {bundleName}.
The following tags are supported for bundleName placeholders: actions, entities, permissions, readPermission, writePermission, and defPermissions.name.
Examples:
- When customizing actions in HAR, use {bundleName} instead of the package name. It looks like this:
"skills": [
{
"actions": [
"{bundleName}.ACTION_PLAY"
],
"entities": [
"{bundleName}.ENTITY_PLAY"
],
}
],
- After the HAR is compiled to the HAP package with bundleName com.huawei.hiworld, the original {bundleName} is replaced with the actual package name of the HAP. The result of the replacement is as follows:
"app": {
"bundleName": "com.huawei.hiworld",
……
},
"module": {
"abilities": [
{
"skills": [
{
"actions": [
"com.huawei.hiworld.ACTION_PLAY"
],
"entities": [
"com.huawei.hiworld.ENTITY_PLAY"
],
}
],
2 -> Application data management
HarmonyOS Application Data Management supports the persistence of various structured data on a single device, as well as the synchronization, sharing, and search functions of data across devices. Through application data management, developers can easily complete the seamless connection of application data between different terminal devices, and meet the consistent experience of users using data across devices.
2.1 -> Local application data management
Provides storage and access to structured data on a single device. Using SQLite as the persistent storage engine, it provides several types of local databases, namely Relational Database and Object Relational Mapping Database, as well as a lightweight preferred database (Light Weight). Preference Database) to meet the needs of developers using different data models to persist and access application data.
2.2 -> Distributed data services
The distributed database supports the synchronization of user data across devices, providing users with a consistent data access experience on multiple terminal devices. By calling the distributed data interface, the application can save data to a distributed database. By combining the account, unique application identity, and database triplet, a distributed database isolates data belonging to different applications.
2.3 -> Distributed File Services
Provides distributed sharing capabilities across multiple endpoints for files created by applications on a single device. A full file metadata is stored on each device, and applications can access the same application file across devices through the path in the file metadata.
2.4 - > Data Search Service
Provide applications with search engine-level full-text index management, indexing, and search capabilities on a single device.
2.5 -> Data storage management
It provides application developers with the query and management functions of system storage paths, storage device lists, and storage device attributes.
3 -> Application security management
3.1 -> Application development preparation stage
In accordance with the Provisions on the Administration of Mobile Internet Application Information Services, and in order to promote the healthy and orderly development of the ecosystem and protect the legitimate rights and interests of app developers and users, every HarmonyOS developer is required to register an account and perform real-name authentication at the same time. Real-name authentication includes real-name authentication for individual developers and real-name authentication for enterprise developers.
It is recommended to use the development tools downloaded from official channels.
Before publishing a HarmonyOS app, you can debug the app locally. HarmonyOS uses digital certificates and profile files to control applications, and only signed HAPs are allowed to run on devices.
3.2 -> Application development and debugging phase
3.2.1 -> Coding security
Ability to avoid external interaction can be directly accessed by other applications.
Avoid public events with sensitive features that can be directly accessed by other apps.
Avoid calling components implicitly to prevent component hijacking.
Avoid sending public events implicitly, and prevent the data carried by public events from being hijacked.
As a data user, the application needs to verify the identity of the data provider to prevent spoofing attacks.
The legitimacy of incoming intent across trust boundaries must be determined to prevent application crashes.
Avoid enabling app backup and restore in your configuration file.
Avoid storing sensitive data on the clipboard.
Avoid writing sensitive data to public databases and stores.
Do not directly use untrusted data to concatenate SQL statements.
Avoid passing untrusted data to executable functions.
Avoid using sockets for local communication, generate a random localhost port number, and authenticate and authenticate the port connection objects.
It is recommended that you use Https instead of HTTP for communication and perform strict verification of Https certificates.
We recommend that you use the verification mechanism to ensure the validity of the URL address of the WebView when loading the website service.
For applications involving payment and high-security data, it is recommended to monitor the mobile phone root environment.
It is recommended that you enable the secure compilation option to increase the difficulty of reverse application analysis.
Disable apps from performing hot updates, which can be done through the App Marketplace.
We recommend that your app self-test during the development phase.
3.2.2 -> Permission Usage
The permissions applied for by the application must have clear and reasonable usage scenarios and function descriptions to ensure that users can clearly and clearly know the purpose, scenario, and purpose of applying for permissions. It is forbidden to induce or mislead users into authorization; App usage rights must match the requirements described in the request.
Application permission application follows the principle of minimization, and only applies for permissions necessary for business functions, and prohibits unnecessary permissions.
When the application is launched for the first time, avoid frequent pop-up windows to apply for multiple sensitive permissions; Sensitive permissions must be dynamically applied for when users use the corresponding business functions.
If a user refuses to grant a permission, other business functions unrelated to this permission should be able to be used normally and should not affect the normal registration or login of the app.
When the user actively triggers the use of this business function or is necessary to realize the business function, the application can guide the user to authorize the user in the "System Settings" through the text guidance in the interface.
If you do not have a custom permission name for a system application, it is forbidden to use the system permission name prefix (for example, if the system permission starts with ohos), and it is recommended to prefix the application package name or the company antidomain name to prevent the same name as the permission defined by the system or other applications.
3.3 -> App release and distribution phase
After the application is debugged, you can package the HarmonyOS application and submit an application for listing it on AGC. To ensure the integrity of HarmonyOS applications and the legitimacy of the developers who submit them, HarmonyOS uses digital certificates and profile files to control applications. Apps that are listed on AppGallery must be signed before they can be listed. Therefore, in order to ensure the smooth release of the application, you need to apply for the corresponding release certificate and release profile in advance.
After submitting the release application, the app market will conduct a security review of the app, including permissions, privacy, security, etc., and if the review is not passed, it will not be listed. After an app is published, AppGallery will re-sign the app and replace the original app signature with a new one.
Top comments (0)