1.6 应用配置文件
1.6.1 配置文件介绍
应用的每个HAP的根目录下都存在一个config.json配置文件，如图1.42所示，主要涵盖以下3个方面：
图1.42 config.json资源文件
（1）应用的全局配置信息，包含应用的包名、生产厂商、版本号等基本信息。
（2）应用在具体设备上的配置信息。
（3）HAP包的配置信息，包含每个Ability必须定义的基本属性（如包名、类名、类型及Ability提供的能力），以及应用访问系统或其他应用受保护部分所需的权限等。
config.json由属性和值两部分构成，属性出现顺序不分先后，且每个属性最多只允许出现一次。每个属性的值为JSON的基本数据类型（数值、字符串、布尔值、数组、对象或者null类型）。如果属性值需要引用资源文件，可参见1.7.3节资源文件的使用。
1.6.2 配置信息App
应用的配置文件config.json中由app、deviceConfig和module 3个部分组成，缺一不可。app表示应用的全局配置信息。同一个应用的不同HAP包的app配置必须保持一致。deviceConfig表示应用在具体设备上的配置信息。module表示HAP包的配置信息。该标签下的配置只对当前HAP包生效。app的示例代码如下：
//config.json中app示例代码
"app":{
"bundleName":"com.huawei.mytestapp.example",
"vendor":"huawei",
"version":{
"code":2,
"name":"2.0"
}
"apiVersion":{
"compatible":3,
"target":3
}
}
其中，bundleName表示应用的包名，用于标识应用的唯一性。包名是由字母、数字、下画线（_）和点号（.）组成的字符串，必须以字母开头。支持的字符串长度为7～127字节。包名通常采用反域名形式表示（例如，com.huawei.mytestapp）。建议第一级为域名后缀com，第二级为厂商／个人名，第三级为应用名，也可以采用多级。
vendor表示对应用开发厂商的描述。字符串长度不超过255字节。vendor可以不定义，不定义就默认为空值。
version: code表示表示应用的版本号，仅用于HarmonyOS管理该应用，对用户不可见。取值为大于零的整数，不可以缺省。
version: name表示应用的版本号，用于向用户呈现。取值可以自定义，不可以缺省。
apiVersion: compatible表示应用运行需要的API最小版本。取值为大于零的整数，不可缺省。
apiVersion: target表示应用运行需要的API目标版本。取值为大于零的整数，可缺省，如果不填写则自动识别为应用所在设备的当前API版本。
1.6.3 配置信息deviceConfig
deviceConfig包含在具体设备上的应用配置信息，可以包含default、car、tv、wearable、liteWearable、smartVision等属性。default标签内的配置适用于所有设备，其他设备类型如果有特殊的需求，则需要在该设备类型的标签下进行配置。
deviceConfig的示例代码如下：
//config.json中deviceConfig示例代码
"deviceConfig":{
"default":{
"process":"com.huawei.hiworld.example",
"directLaunch":false,
"supportBackup":false,
"network":{
"usesCleartext":true,
"securityConfig":{
"domainSettings":{
"cleartextPermitted":true,
"domains":[
{
"subDomains":true,
"name":"example.ohos.com"
}
]
}
}
}
}
}
deviceConfig中基本有6类信息：
（1）default表示所有设备通用的应用配置信息。
（2）car表示车机特有的应用配置信息。
（3）tv表示智慧屏特有的应用配置信息。
（4）wearable表示智能穿戴特有的应用配置信息。
（5）liteWearable表示轻量级智能穿戴特有的应用配置信息。
（6）smartVision表示智能摄像头特有的应用配置信息。
本例中只举了default中设置的应用配置信息，default标签内的配置适用于所有设备，其他设备类型如果有特殊的需求，则需要在该设备类型的标签下进行配置。具体这6个对象的内部结构说明可查阅官方文档，此处不再赘述。
1.6.4 配置信息module
module中包含了HAP包的配置信息，示例代码如下：
//config.json中module示例代码
"module":{
"package":"com.example.myapplication.entry",
"name":".MyOHOSAbilityPackage",
"description":"$ string:description_application",
"supported Modes":[
"drive"
],
"deviceType":[
"car"
],
"distro":{
"delivery WithInstall":true,
"moduleName":"ohos_entry",
"moduleType":"entry"
},
"abilities":[
...
],
"shortcuts":[
...
],
"js":[
...
],
"reqPermissions":[
...
],
"defPermissions":[
...
]
}
（1）package表示HAP的包结构名称，在应用内应保证唯一性。采用反向域名格式（建议与HAP的工程目录保持一致）。字符串长度不超过127字节。该标签仅适用于智慧屏、智能穿戴、车机，不可缺省。
（2）name表示HAP的类名。采用反向域名方式表示，前缀需要与同级的package标签指定的包名一致，也可采用“.”开头的命名方式。字符串长度不超过255字节。该标签仅适用于智慧屏、智能穿戴、车机，不可缺省。
（3）description表示HAP的描述信息。字符串长度不超过255字节。如果字符串超出长度或者需要支持多语言，可以采用资源索引的方式添加描述内容。该标签仅适用于智慧屏、智能穿戴、车机，可以缺省，默认值为空。
（4）supported Modes表示应用支持的运行模式。当前只定义了驾驶模式（drive）。该标签仅适用于车机，可以缺省，默认值为空。
（5）deviceType表示允许Ability运行的设备类型。系统预定义的设备类型包括：tv（智慧屏）、car（车机）、wearable（智能穿戴）、liteWearable（轻量级智能穿戴）和default（通用）等，不可缺省。
（6）distro表示HAP发布的具体描述。该标签仅适用于智慧屏、智能穿戴、车机，不可缺省。distro示例代码如下：
"distro":{
"delivery WithInstall":true,
"moduleName":"ohos_entry",
"moduleType":"entry"
}
· deliveryWithInstall表示当前HAP是否支持随应用安装，是一个布尔类型的值，不可以缺省，如果其值是true，则表示支持随应用安装，如果其值是false，则表示不支持随应用安装。
· moduleName用字符串的形式表示当前HAP的名称，不可以缺省。
· moduleType用字符串的形式表示当前HAP的类型（entry和feature）。entry表示一个应用的主模块。一个App中，对于同一设备类型必须有且只有一个entry类型的HAP，可独立安装运行。feature表示应用的动态特性模块。一个App可以包含一个或多个feature类型的HAP，也可以不含。只有包含Ability的HAP才能够独立运行。
（7）ability表示当前模块内的所有Ability。采用对象数组格式，其中每个元素表示一个Ability对象，可缺省，默认值为空。Ability非常重要，每当我们创建新的Ability，都要确认该处的配置是否正确，后面将详细介绍Ability的形式。
（8）JS表示基于JS UI框架开发的JS模块集合，其中的每个元素代表一个JS模块的信息，不过不写则说明该模块没有使用JS框架，下面给出一个示例，page中定义了JS UI的页面路径+页面名称，JS UI具体用法可阅读第5章JS UI布局，示例代码如下：
（9）shortcuts表示应用的快捷方式信息。采用对象数组格式，其中的每个元素表示一个快捷方式对象，可缺省，默认值为空。
（10）defPermissions表示应用定义的权限。应用调用者必须申请这些权限，这样才能正常调用该应用，该值可缺省，默认值为空。
（11）reqPermissions表示应用运行时向系统申请的权限，该值可缺省，默认值为空。
这里再详细讲解一下abilities对象的内部结构，示例代码如下：
（1）第一行的name表示Ability名称。取值可采用反向域名方式表示，由包名和类名组成，如com.example.myapplication.MainAbility；也可采用“.”开头的类名方式表示，如.MainAbility。该标签仅适用于智慧屏、智能穿戴、车机，不可缺省。
（2）第二行的description则表示对Ability的描述。取值可以是描述性内容，也可以是对描述性内容的资源索引，以便支持多语言，可缺省，默认值为空。
（3）icon表示Ability图标资源文件的索引。如果写了如下代码：$ media: ability_icon就可以使用resource文件夹中的media中的名字为ability_icon图片作为App的图标来显示。如果在该Ability的skills属性中，actions的取值包含action.system.home, entities取值中包含entity.system.home，则该Ability的icon将同时作为应用的icon。如果存在多个符合条件的Ability，则取位置靠前的Ability的icon作为应用的icon。这个数值可缺省，默认值为空。
（4）label表示Ability对用户显示的名称。取值可以是Ability名称，也可以是对该名称的资源索引，以便支持多语言。如果在该Ability的skills属性中，actions的取值包含action.system.home, entities取值中包含entity.system.home，则该Ability的label将同时作为应用的label。如果存在多个符合条件的Ability，则取位置靠前的Ability的label作为应用的label。可缺省，默认值为空。
（5）uri表示Ability的统一资源标识符。格式为[scheme：][//authority][path][?query][#AbilitySlice]。可缺省，但对于data类型的Ability不可缺省。
（6）launchType表示Ability的启动模式，支持standard和singleton两种模式：standard表示该Ability可以有多实例。standard模式适用于大多数应用场景。singleton表示该Ability只可以有一个实例。例如，具有全局唯一性的呼叫来电界面即采用singleton模式。该标签仅适用于智慧屏、智能穿戴、车机。可缺省，默认值为standard。
（7）visible表示Ability是否可以被其他应用调用，是布尔类型的值。
（8）permissions表示其他应用的Ability调用此Ability时需要申请的权限。通常采用反向域名格式，取值可以是系统预定义的权限，也可以是开发者自定义的权限。如果是自定义权限，取值必须与defPermissions标签中定义的某个权限的name标签值一致。可缺省，默认值为空。
（9）skills表示Ability能够接收的Intent的特征，可缺省，默认值为空。
（10）deviceCapability表示Ability运行时要求设备具有的能力，采用字符串数组的格式表示。
（11）type表示Ability的类型。page表示基于Page模板开发的FA，用于提供与用户交互的能力。service表示基于Service模板开发的PA，用于提供后台运行任务的能力。data表示基于Data模板开发的PA，用于对外部提供统一的数据访问抽象。
（12）formEnabled和form是绑定使用的，formenabled表示FA类型的Ability是否提供卡片（form）能力。只有当formEnabled生效时，form才会生效，而form表示Ability Form的属性。
（13）orientation表示屏幕的方向，主要有4个选项：
· unspecified：由系统自动判断显示方向。
· landscape：横屏模式。
· portrait：竖屏模式。
· followRecent：跟随栈中最近的应用。
如果没有设置orientation，系统会自动使用unspecified属性。
（14）剩下的还有backgroundModes、readPermission、directLaunch、configChanges、mission、targetAbility、multiUserShared、supportPipMode等属性，具体完整的属性可查阅官方文档。