Skip to content

D
Docs

OpenHarmony / Docs
大约 2 年 前同步成功

通知 161
Star 293
Fork 28
D
Docs
未验证 提交 d6de7eb7 编写于 作者: O openharmony_ci 提交者： Gitee
浏览文件
操作

!6201 Fix: 修改init 文档 

Merge pull request !6201 from Mupceet/init_guide
上级 6748708f eb4c363f
展开全部 显示空白变更内容
内联 并排
Showing with 2152 addition and 635 deletion
zh-cn/device-dev/faqs/faqs-startup.md
浏览文件 @ d6de7eb7
......@@ -2,11 +2,11 @@
## 启动恢复常见问题
### 系统启动过程中打印“parse failed!”错误后停止启动
### 设备启动过程中打印“parse failed!”错误后停止启动
**现象描述**
系统启动过程中，打印“[Init] InitReadCfg, parse failed! please check file /etc/init.cfg format.”错误，启动过程停止，如下图所示：
设备启动过程中，打印日志“[Init] InitReadCfg, parse failed! please check file /etc/init.cfg format.”错误，启动过程停止，如下图所示：
**图1** 运行报错图
......@@ -14,56 +14,57 @@
**可能原因**
修改init.cfg文件时，漏掉或多加了逗号或括号等，导致init.cfg文件的json格式被破坏。
init.cfg文件内容不符合JSON语法格式。
**解决办法**
仔细检查init.cfg文件，确保其格式符合json格式要求。
排查init.cfg文件，格式符合JSON格式要求。
### 系统启动过程未结束就自动重启，如此反复持续
### 设备开机后，反复重启。
**现象描述**
镜像烧写完成后系统启动，启动过程未完成即自动重新启动，如此反复持续。
设备启动过程中反复重启。
**可能原因**
被init启动的服务都有一个叫做“importance”的属性（详见[第2章表3](../subsystems/subsys-boot-init.md)描述）。
init服务中定义“importance”的属性（详见[参数说明](../subsystems/subsys-boot-init-service.md#参数说明)描述）。
- 当该属性为0时，表示若当前服务进程退出，init不需要重启单板。
- 属性值为0时，表示当前服务进程退出，设备不重启。
- 当该属性为1时，表示若当前服务进程退出，init需要重启单板。
因此出现上述现象的可能原因：有“importance”属性为1的服务在每次启动的过程中都会退出（可能是进程崩溃或出错自动退出），导致init进程自动重启单板。
- 属性值为1时，表示当前服务进程退出，设备重启。
**解决办法**
1. 需要通过日志确认崩溃或报错退出的服务，并解决其崩溃/报错的问题，然后重新烧写镜像即可。
1. 通过日志确认崩溃或报错退出的服务，并解决其崩溃/报错的问题，重新烧写镜像即可。
2. 也可以将崩溃/报错退出的服务的“importance”属性改为0，然后重新烧写镜像，这样即使其退出，init也不会重启单板。
2. 将崩溃/报错退出的服务的“importance”属性改为0，重新烧写镜像，设备不重启。
### 参数正确的情况下调用SetParameter/GetParameter返回失败
### 调用SetParameter/GetParameter返回失败
**现象描述**
在各参数正确的情况下调用SetParameter/GetParameter返回失败。
在参数正确的情况下，调用SetParameter/GetParameter返回失败。
**出现问题系统类型**
liteos-a
**可能原因**
程序对SetParameter/GetParameter这两个接口做了权限校验，在各参数正确的情况下调用SetParameter/GetParameter返回操作失败，很有可能是调用者的uid大于1000，没有调用权限。
程序有对SetParameter/GetParameter这两个接口做权限校验，因此在各参数正确的情况下，调用SetParameter/GetParameter返回操作失败，是调用者的uid大于1000，没有调用权限。
**解决办法**
无需处理
无需处理。
### ueventd服务启动后报获取socket失败，尝试创建
**现象描述**
ueventd服务启动后，首先出现打印 “Failed to get uevent socket, try to create”，并且应当伴随如下图所示错误日志：
ueventd服务启动后，打印日志 “Failed to get uevent socket, try to create”日志，并且有如下图所示错误日志：
**图2** ueventd获取socket失败
......@@ -71,25 +72,24 @@ ueventd服务启动后，首先出现打印 “Failed to get uevent socket, try
**可能原因**
由于ueventd服务是按需启动的服务，其启动后首先要做的就是从环境变量中拿到init为其创建的socket的fd。根据上述报错打印可知，是获取环境变量的值失败，这种情况可能是：
由于ueventd服务是按需启动的服务，其设备启动后，首先从环境变量中拿到init为其创建的socket的fd。根据上述报错打印可知，是获取环境变量的值失败，这种情况可能是：
1. cfg文件中的ueventd服务没有配置socket，导致init并没有为其创建socket，也就没有相应的环境变量能够让其获取。
2. cfg文件中的ueventd服务已经配置了socket，但仍然有此现象，那可能是在另外一个cfg文件中重复配置了ueventd服务，并且其中没有配置socket。
2. cfg文件中的ueventd服务已经配置了socket，那可能是在另外一个cfg文件中重复配置了ueventd服务，并且其中没有配置socket。
**解决办法**
对于原因1，需要在cfg文件中对ueventd服务进行socket配置，具体可参看init.cfg中[ueventd服务的配置](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-boot-init.md#%E5%BC%80%E5%8F%91%E6%8C%87%E5%AF%BC)（开发指导第3部分）。
对于原因2，则需要查看所有cfg文件找到重复配置的ueventd服务，并将其删除，最终只保留一个有效的ueventd服务配置。
1. cfg文件没有配置socket，需要在cfg文件中对ueventd服务进行socket配置，具体可参看init.cfg中ueventd[服务的socket配置](../subsystems/subsys-boot-init-service.md#参数说明)。
2. 重复配置socket，需要查看所有cfg文件找到重复配置的ueventd服务，并将其删除，保留一个有效的ueventd服务配置。
### ueventd服务轮询socket超时，并自动退出
**现象描述**
ueventd服务启动一段时间后，出现打印 “poll ueventd socket timeout, ueventd exit” 并自动退出。
ueventd服务启动一段时间后，出现打印日志 “poll ueventd socket timeout, ueventd exit” 并自动退出。
**可能原因**
由于ueventd服务是按需启动的服务，其行为是当有uevent事件上报时，init监听到socket消息，会将ueventd服务拉起使其处理相应的socket消息，ueventd服务处理完现有的socket消息后，会自己再轮询对应socket句柄30秒，若30秒内又有新消息上报，则继续处理，待处理结束后再次计时轮询30秒；若超过30秒都没有新消息上报，ueventd服务将会退出，并将socket交还给init轮询，此时就会出现现象中的打印，因此这是一个正常的行为逻辑。
由于ueventd服务是按需启动的服务，其行为是当有uevent事件上报时，init监听到socket消息，会将ueventd服务拉起使其处理相应的socket消息，ueventd服务处理完现有的socket消息后，会自己再轮询对应socket句柄30秒，若30秒内又有新消息上报，则继续处理，待处理结束后再次计时轮询30秒；若超过30秒都没有新消息上报，ueventd服务将会退出，并将socket交还给init轮询，此时就会出现日志中的打印，因此这是一个正常的行为逻辑。
**解决办法**
......@@ -99,50 +99,50 @@ ueventd服务启动一段时间后，出现打印 “poll ueventd socket timeout
**现象描述**
一个符合json格式的服务配置无法被正确解析，打印 “Service is invalid which has both critical and ondemand attribute”，启动该服务时提示Cannot find service.
符合JSON格式的服务配置无法被正确解析，打印日志 “Service is invalid which has both critical and ondemand attribute”，启动该服务时提示“Cannot find service”.
**可能原因**
首先应该确保该服务的配置符合json格式，否则将导致所在cfg文件解析失败，服务自然也会解析失败。其次需要检查配置了ondemand属性的服务，是否同时配置了critical属性值为1，或者critical属性数组的第一个值为1，若是如此，将导致服务解析失败，这是因为ondemand属性默认是按需启动的，只有当需要时才会拉起，空闲时退出，而配置了critical属性的服务被认为是系统关键服务，不可退出，所以这两种属性在同一服务中共存是不合理的，因此在逻辑上做了屏蔽处理。
ondemand属性默认是按需启动的，ondemand和critical属性互斥，两者同时配置，服务不能被正确解析 。
**解决办法**
确认该服务是否要做成按需启动的服务，如果不是，就不需要配置ondemand属性；如果是，则在配置了ondemand属性后，不可再配置critical属性，若是需要critical中的服务异常退出次数限制，请将critical属性数组中的第一个值配置为0再加次数限制，例如"critical" : [0, 15, 5]，代表该服务在5秒钟内启动退出超过15次，将不再启动该服务，并且不会导致系统重启。
1. 服务不按需启动， 不需要配置ondemand属性。
2. 服务按需启动， critical是常驻进程配置， 配置ondemand属性后，不需要再配置critical属性， 或者配置critical属性不使能。
### 配置了ondemand属性的服务不受并行启动控制
### 配置ondemand属性的服务不受并行启动控制
**现象描述**
配置了ondemand属性的服务并没有在并行启动阶段被拉起，不论是将start-mode配置为boot，normal还是使用缺省配置。
配置ondemand属性的服务并没有在并行启动阶段被拉起，start-mode设置无效
**可能原因**
由于ondemand属性是控制服务按需启动的属性，对于按需启动的服务，应当是当需要时，即满足其启动条件时启动，因此并行启动不会拉起配置有ondemand属性的服务，这是正常的行为逻辑。
ondemand属性属于按需启动配置， 服务未能满足启动条件，因此未能成功拉起服务， 属于正常现象。
**解决办法**
若要一个服务加入并行启动，不应为其配置ondemand属性。
并行启动的服务不配置ondemand属性。
### SA按需启动服务无法实现按需拉起
### SA按需启动服务无法按需拉起
**现象描述**
将一个SA服务配置为按需启动的情况下，在SA客户端发送请求后，samgr并没有动态拉起SA服务。
SA服务配置为按需启动的情况，在SA客户端发送请求后，samgr并没有动态拉起SA服务。
**可能原因**
在SA服务实现按需启动初期，还是使用统一接口SystemAbilityManager::CheckSystemAbility(int32_t systemAbilityId)，后续为了将按需启动的SA服务区分开来，专门新增了samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)，原接口不适配按需启动的SA服务，故可能是接口使用错误导致SA服务未能按需拉起。
在SA服务实现按需启动初期，使用统一接口SystemAbilityManager::CheckSystemAbility(int32_t systemAbilityId)，后续为了将按需启动的SA服务区分开来，新增samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)，原接口不适配按需启动的SA服务，故导致SA服务未能按需拉起。
**解决办法**
在按需启动的SA服务中使用samgr提供的动态加载接口LoadSystemAbility(int32_t systemAbilityId, const sptr& callback)。
### dac配置不合理
### caps配置不合理
**现象描述**
dac 配置错误，会导致配置失效，报错如下：
caps 配置错误，会导致配置失效，报错如下：
```
4.619955] [pid=1 0][Init][ERROR][init_capability.c:119]service=multimodalinput not support caps = CAP_DC_OVERRIDE caps 41
[ 4.620014] [pid=1 0][Init][ERROR][init_service_manager.c:818]GetServiceSecon secon section not found, skip
......@@ -151,71 +151,53 @@ dac 配置错误，会导致配置失效，报错如下：
```
**可能原因**
1. caps配置问题，防止配置最大属性。
2. 带CAP和非CAP开头的解析能力。
3. const问题。
**解决办法**
1. 支持带CAP和非CAP开头的解析能力。
2. 解决caps配置问题，防止配置最大属性。
3. 添加const属性文件，修复可以产品覆盖平台的。
1. 内核不支持。
2. cfg文件中配置错误。
### critical属性配置不生效
**出现问题版本**
**现象描述**
配置critical 不生效。
**可能原因**
1. critical 配置格式是否有效。
2. 配置critical 的服务是否拉起。
3. 修改的配置文件是否生效。
OpenHarmony-3.0-LTS
**解决办法**
1. 修改配置文件格式可能存在问题。
2. 配置critical的服务可能不存在。
3. 不同设备对应的配置文件不同。3516设备修改init.cfg， RK3568设备修改init.without_two_stages.cfg。
1. 内核不支持， 不需要配置caps。
2. 内核支持，cfg文件中caps配置不正确，导致在init中解析的时候，解析失败，参考base/startup/init_lite/services/init/init_capability.c中，capStrCapNum数据结构的定义，正确配置caps。
### 不支持socket类进程按需启动
### 打开沙盒功能
**现象描述**
不支持socket类进程按需启动。
通过hdc shell param get const.sandbox查看该parameter的值不是enable。
**可能原因**
ueventd按需启动，DISABLE_INIT_TWO_STAGES宏的修改失效。
无。
**解决办法**
在startUeventd中关闭socket，未能在在创建socket函数中增加了对socket有效性的检查， 故可能未做socket有效性检查导致的异常。
**解决方法**
在base/startup/init_lite/services/etc/param/ohos.para中配置const.sandbox=enable。具体参考[沙盒指导](../subsystems/subsys-boot-init-sandbox.md)
### 小型系统编译告警
### 查看服务中沙盒的挂载状态
**现象描述**
warning: implicit declaration of function 'usleep' is invalid in C99。
warning: implicit declaration of function 'setgroups' is invalid in C99。
无。
**可能原因**
头文件可能包含错误， _GNU_SOURCE宏可能未打开。
无。
**解决办法**
**解决方法**
检查对应头文件是否包含正确， 如果正确， _GNU_SOURCE宏是否打开。
设备进入hdc shell下， 执行sandbox -s service_name命令，模拟当前服务进入沙盒场景， 通过 ls 等shell命令查看当前服务沙盒目录。具体参考[沙盒命令](../subsystems/subsys-boot-init-plugin.md)
## Appspawn应用孵化常见问题
### 系统启动中，appspawn启动失败
### 设备启动中，appspawn启动失败
**现象描述**
系统启动过程中，系统停止开机动画中， 进入appspawn失败。
设备启动过程中，设备停止开机动画中， 进入appspawn失败。
**可能原因**
......@@ -226,7 +208,7 @@ warning: implicit declaration of function 'setgroups' is invalid in C99。
需要通过日志确认崩溃或报错退出的服务，并解决其崩溃/报错的问题，然后重新烧写镜像即可。
### 冷启动应用失败
### 冷启动命令启动应用失败
**现象描述**
......@@ -237,30 +219,32 @@ warning: implicit declaration of function 'setgroups' is invalid in C99。
**可能原因**
1. 冷启动未能生效。
2. 确认冷启动命令正确。
1. 冷启动状态未打开。
2. 冷启动命令参数输入错误。
**解决办法**
1. 需要设置 param set appspawn.cold.boot true 确认冷启动时候生效。
2. 确认冷启动命令正确。
1. 冷启动不使能， 通过param get appspawn.cold.boot命令查看状态，如果冷启动状态是false, 通过param set appspawn.cold.boot true 命令打开冷启动状态。
2. 冷启动命令参数不正确， 查看并确认冷启动参数。
### 应用沙盒创建失败
**现象描述**
systemui启动失败，卡顿在OpenHarmony开机动画中，或者计算器应用无法点击， 字体不能正常显示等。hilog日志中报错：
com.ohos.systemui应用启动失败、OpenHarmony开机动画退出失败、计算器应用无法使用、字体不能正常显示等。日志报错：
- bind mount `<src-path>` to `<sandbox-path>` failed errno `<errorCode>`。
- private mount to `<sandbox-path>` failed errno `<errorCode>`。
- symlink failed, `<link-name>`, errno is `<errorCode>`。
**可能原因**
1. 沙盒流程创建是否正确。
2. com.ohos.systemui 沙盒创建失败。
1. 沙盒流程创建失败。
2. com.ohos.systemui沙盒创建失败。
3. 沙盒应用依赖的文件配置失败。
**解决办法**
1. 查看hilog日志中，出现的相关hilog报错信息，针对报错修改对应的json文件。
2. 查看对应应用的pid情况，排查沙盒建立过程的代码逻辑，以及相应的json配置的正确性。
\ No newline at end of file
1. 查看hilog日志中，排查相关hilog报错信息，针对报错修改对应的JSON文件。
2. 查看对应应用的pid情况，排查沙盒建立过程的代码逻辑，以及相应的JSON配置的正确性。
具体参考[应用沙盒开发步骤](../subsystems/subsys-boot-appspawn.md#开发步骤)
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init-cfg.md 0 → 100644
浏览文件 @ d6de7eb7
# 引导启动配置文件
## 概述
### 功能简介
Init配置文件基于JSON格式，用来配置系统启动时必要的命令和服务。Init在系统启动时解析配置文件，并根据配置文件执行对应的命令，启动相应的服务。
### 基本概念
1. 分组配置文件（device.xxxx.group.cfg）（标准系统支持），文件由jobs、services和groups组成。用来限制能够执行的jobs和service。根据cmdline中的bootgroup属性决定当前的分区。当前支持下列分组：
- ​device.boot.group 系统默认配置，触发执行配置文件中的所有的job和服务。
- device.charge.group charge模式，限制只启动改文件中允许的job和服务。
2. 启动配置文件（init.cfg），文件由jobs、services和import组成。
- services（linux内核支持）， 用于配置系统支持的native服务，服务具体配置参考 **[服务管理](subsys-boot-init-service.md)**。
- jobs， 配置等待执行命令集合，jobs具体参考 **[jobs管理](subsys-boot-init-jobs.md)**。
- import（linux内核支持），import是导入cfg文件，目的是减少cfg大小，分离不同的功能。
### 约束与限制
仅支持小型系统和标准系统。
## 开发指导
### 场景介绍
init进程启动时，首先完成系统初始化工作，然后开始解析配置文件。系统在解析配置文件时，会将配置文件分成三类：
1. init.cfg默认配置文件，由init系统定义，优先解析。
2. /system/etc/init/*.cfg各子系统定义的配置文件。
3. /vendor/etc/init/*.cfg厂商定义的配置文件。
当需要添加配置文件时，用户可以根据需要定义自己的配置文件，并拷贝到相应的目录下。
### 开发步骤
1. 定义配置文件。
```
{
"import" : [ ],
"jobs" : [ ],
"services" : [ ]
}
```
2. 根据具体的系统拷贝配置到相应的目录。
标准系统下：
```
ohos_prebuilt_etc("misc.cfg") {
source = "//base/startup/init_lite/services/etc/misc.cfg"
relative_install_dir = "init"
part_name = "init"
}
```
小型系统下：
```
copy("init_configs") {
sources = [ "init_liteos_a_3516dv300.cfg" ]
outputs = [ "$root_out_dir/config/init.cfg" ]
}
```
### 开发实例
下述为cfg文件编写模板。
```
{
"import" : [
"/etc/example1.cfg",
"/etc/example2.cfg"
],
"jobs" : [{
"name" : "jobName1",
"cmds" : [
"start serviceName",
"mkdir dir1"
]
}, {
"name" : "jobName2",
"cmds" : [
"chmod 0755 dir1",
"chown root root dir1"
]
}
],
"services" : [{
"name" : "serviceName",
"path" : ["/system/bin/serviceName"]
}
]
}
```
1. cfg文件是严格按照JSON格式编写的，当添加服务或命令未生效时，可以优先排查添加内容的格式是否正确。
2. 对于import解析，在解析完成一个import中的cfg文件路径时，会立即解析该cfg文件。
3. example1.cfg 需要导入的cfg文件。
4. serviceName：service名称， 用户自定义。
5. /system/bin/serviceName: 当前服务的可执行文件全路径和参数， 数组形式。
6. jobName1：job名称， 用户自定义。
zh-cn/device-dev/subsystems/subsys-boot-init-jobs.md 0 → 100644
浏览文件 @ d6de7eb7
此差异已折叠。
zh-cn/device-dev/subsystems/subsys-boot-init-plugin.md 0 → 100644
浏览文件 @ d6de7eb7
# 插件
## 概述
### 基本概念
- begetctl介绍
具体参考[begetctl命令](#table14737791480)。
- bootchart 插件
bootchart是一个用于linux启动过程性能分析的开源工具软件，在系统中自动收集CPU占用率、磁盘吞吐率、进程等信息，并以图形方式显示分析结果，可用作指导优化系统启动过程。begetctl命令参考：[begetctl命令](#table14737791480)。
### 约束与限制
bootchart 只支持标准系统， begetctl 支持小型系统和标准系统。
## 开发指导
### 参数说明
**表1** begetctl 命令说明<a name="table14737791480"></a>
| 命令 | 命令格式和示例 | 说明 |
| :---------- | :---------- |:--------|
| init group test [stage] | init group test | stage参见ServiceStatus。 |
| param ls [-r] [name] | 显示系统参数，例如：<br>查看usb系统参数：begetctl param ls persist.sys.usb | 无 |
| param get [name] | 获取系统参数信息，例如：<br>begetctl param get 或 param get | 无 |
| param set name value| 设置系统参数，例如：<br>begetctl param set ohos.servicectrl.display 1 或 param set ohos.servicectrl.display 1| 无 |
| param wait name [value] [timeout] | 等待系统参数，例如：<br>begetctl param wait persist.sys.usb.config hdc 或 param wait persist.sys.usb.config hdc | timeout默认值：30 |
| param dump [verbose] | dump 系统参数信息，例如：<br>begetctl param dump 或 param dump| 无 |
| param shell [name] | 进入Parameter shell，例如：<br>begetctl param shell 或 param shell| 无 |
| timer_stop servicename | 停止服务计时器，例如：<br>begetctl timer_stop appspawn | servicename长度不超过96字符 |
| timer_start servicename timeout | 启动服务计时器，例如：<br>begetctl timer_start appspawn | servicename长度不超过96；timeout默认值：10s |
| start_service servicename | 启动服务，例如：<br>begetctl start_service appspawn 或 start_service appspawn | 无 |
| stop_service servicename | 停止服务，例如：<br>begetctl stop_service appspawn 或 stop_service appspawn | 无 |
| service_control start servicename | 启动服务，例如：<br>begetctl service_control start appspawn 或 service_control start appspawn | 无 |
| service_control stop servicename | 停止服务，例如：<br>begetctl service_control stop appspawn 或 service_control stop appspawn | 无 |
| misc_daemon --write_logo xxx.rgb | 写入开机logo，例如：<br>begetctl misc_daemon --write_logo logo.rgb 或 misc_daemon --write_logo logo.rgb| rgb文件最大不超过1024*2038，仅支持hi3516dv300 |
| reboot | 重启系统，例如：<br>begetctl reboot 或 reboot|无 |
| reboot shutdown | 关闭系统，例如：<br>begetctl reboot shutdown 或 reboot shutdown |无 |
| reboot suspend | 暂停系统，例如：<br>begetctl reboot suspend 或 reboot suspend | 无 |
| reboot updater | 重新启动并进入updater，例如：<br>begetctl reboot updater 或 reboot updater | 无 |
| reboot updater[:options] | 重新启动并进入updater，例如：<br>begetctl reboot updater 或 reboot updater | 无 |
| reboot flashd | 重新启动并进入flashd，例如：<br>begetctl reboot flashd 或 reboot flashd | 无 |
| reboot flashd[:options] | 重新启动并进入flashd，例如：<br>begetctl reboot flashd 或 reboot flashd | 无 |
| reboot charging | 重新启动并进入charging，例如：<br>begetctl reboot charging 或 reboot charging| 无 |
| reboot loader | 重新启动并进入烧写模式，例如：<br>begetctl reboot loader 或 reboot loader | 无 |
| bootchart stop | 停止图形分析，例如：<br>begetctl bootchart stop | 仅支持rk3568|
| bootchart start | 开始图形分析，例如：<br>begetctl bootchart start | 无 |
| bootchart disable | 图形分析不使能，例如：<br>begetctl bootchart disable | 无 |
| bootchart enable | 图形分析使能，例如：<br>begetctl bootchart enable | 无 |
| sandbox -s service_name | 服务进沙盒，例如 <br>sandbox -s foundation | 无 |
| sandbox -p process_name | 进程进沙盒，例如 <br>sandbox -p /bin/sh | 无 |
| sandbox -n sandbox_name | 进入配置的system或者chipset沙盒，<br>sandbox -n system | 无 |
| sandbox -h | sandbox command help | 无 |
## 开发指导
### 接口说明
**表1** 接口介绍<a name="table14737791479"></a>
| 函数 | 函数解释 |
| ---------- | ---------- |
| void PluginExecCmdByName(const char *name, const char *cmdContent) | 通过名称启动插件。 |
| void PluginExecCmdByCmdIndex(int index, const char *cmdContent) | 通过标志启动插件。 |
| int PluginExecCmd(const char *name, int argc, const char **argv) | 命令启动插件。 |
| int AddCmdExecutor(const char *cmdName, CmdExecutor execCmd) | 添加安装插件命令。 |
### 开发步骤
新增一个插件， 以bootchart为例：
1. 安装so文件， 定义单独文件，实现下面函数。
```c
static int bootchartEarlyHook(int stage, int prio, void *cookie)
{
char enable[4] = {}; // 4 enable size
uint32_t size = sizeof(enable);
SystemReadParam("persist.init.bootchart.enabled", enable, &size);
if (strcmp(enable, "1") != 0) {
PLUGIN_LOGI("bootchart disabled.");
return 0;
}
InitModuleMgrInstall("libbootchart");
PLUGIN_LOGI("bootchart enabled.");
return 0;
}
MODULE_CONSTRUCTOR(void)
{
// Depends on parameter service
InitAddPostPersistParamLoadHook(0, bootchartEarlyHook);
}
```
2. 编译成静态库libbootchart_static，并加入static_modules组。
```
group("static_modules") {
if (!defined(ohos_lite)) {
deps = [ ":libbootchart_static" ]
}
}
```
3. 初始化bootchart插件， 可以安装插件命令。
```c
static int BootchartInit(void)
{
if (g_executorId == -1) {
g_executorId = AddCmdExecutor("bootchart", DoBootchartCmd);
PLUGIN_LOGI("BootchartInit executorId %d", g_executorId);
}
return 0;
}
MODULE_CONSTRUCTOR(void)
{
PLUGIN_LOGI("DoBootchartStart now ...");
BootchartInit();
}
```
4. 退出bootchart插件。
```c
MODULE_DESTRUCTOR(void)
{
PLUGIN_LOGI("DoBootchartStop now ...");
DoBootchartStop();
BootchartExit();
}
```
5. 执行bootchart命令。
```c
static int DoBootchartCmd(int id, const char *name, int argc, const char **argv)
{
PLUGIN_LOGI("DoBootchartCmd argc %d %s", argc, name);
...
return 0;
}
```
### 开发实例
预制条件：
1. 准备bootchart测试环境：linux操作系统下安装python及pycairo pip install pycairo
2. 在linux解压bootchart-master.tar
tar -zxvf bootchart-master.tar
执行步骤：
1. 启动系统。
2. 执行命令行：begetctl bootchart enable
3. 重启系统。
4. 执行命令行：begetctl bootchart stop
5. 执行命令行：begetctl bootchart disable
6. 在/data/bootchart目录下导出如下文件并存放在bootchart文件夹：<br>
header<br>
proc_diskstats.log<br>
proc_ps.log<br>
proc_stat.log<br>
7. 使用tar -zcvf bootchart.tgz * 命令进行打包（只支持linux版本）并将该打包文件拷贝到linux：bootchart-master目录下。
8. 在bootchart-master目录下运行命令：
```
python3 pybootchartgui.py -f pdf bootchart.tgz
```
预期结果：
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在bootchart-master目录下生成bootchart.pdf。
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init-sandbox.md 0 → 100644
浏览文件 @ d6de7eb7
# 沙盒管理
## 概述
### 功能简介
支持系统组件及芯片组件进程沙盒运行。
### 基本概念
在init里面创建系统组件沙盒和芯片组件沙盒，native服务根据功能进入system沙盒或者chipset沙盒。在system-sandbox.json、chipset-sandbox.json等配置文件中设置沙盒组件中mount bind 的目录或文件，实现沙盒组件通过mount属性进行隔离。同时，提供了一种沙盒调试工具，当需要在沙盒内验证或者进行沙盒相关开发时，方便对需求进行调试、验证、完善。begetctl沙盒命令参考: **[begetctl命令说明](subsys-boot-init-plugin.md#参数说明)**。
### 约束与限制
仅标准系统下使用。
## 开发指导
### 参数说明
**表1** 沙盒配置文件字段解释
| JSON前缀 | 解释 |
| ---------- | ---------- |
| sandbox-root | 沙盒的根目录 |
| mount-bind-paths | mount一个目录 |
| mount-bind-files | mount一个文件 |
| src-path | 需要mount的目录/文件路径 |
| sandbox-path | 沙盒里面需要挂载至的目录/文件 |
| sandbox-flags | mount的挂载标志位, 缺省"bind rec"标志位 |
| target-name | 需要link的目录 |
| link-name | 沙盒内link后的目录 |
**表2** 沙盒配置文件解释
| 沙盒配置文件 | 解释 |
| -------- | -------- |
| chipset-sandbox64.json | 64位系统的芯片沙盒配置文件 |
| chipset-sandbox.json | 32位系统的芯片沙盒配置文件 |
| system-sandbox64.json | 64位系统的系统沙盒配置文件 |
| system-sandbox.json | 32位系统的系统沙盒配置文件 |
### 接口说明
**沙盒的逻辑存储结构：**
```c++
// 主要函数
// name is "system" or "chipset"
bool InitSandboxWithName(const char *name); // 解析JSON至结构体
typedef struct {
mountlist_t *mounts; // 待 mount 的目录
mountlist_t *fileMounts; // 待 mount 的文件
linklist_t *links; // 待 link 的目录
char *rootPath; // 沙盒的根路径 -> /mnt/sandbox/system|vendor|xxx
char name[MAX_BUFFER_LEN]; // 沙盒名称，system沙盒、chipset沙盒等
bool isCreated; // 沙盒创建标志
int ns; // namespace
} sandbox_t;
```
### 开发步骤
1. 沙盒的创建方式
- 创建system或者chipset沙盒，配置对应的system-sandbox.json或者chipset-sandbox.json文件，JSON文件配置参考: [沙盒JSON文件配置](#sandbox)
- 默认情况下，服务的sandbox功能是打开的，如果不想让某个特定的服务不进入沙盒，在cfg中配置sandbox ： 0。当在cfg配置sandbox ： 1，服务依进入沙盒。
```
"sandbox" : 1
```
2. 修改沙盒JSON文件配置
- 查看系统组件沙盒配置文件、芯片组件沙盒配置文件，进入/system/etc/sandbox/ 目录下，cat system-sandbox.json ，cat chipset-sandbox.json; 直接修改对应沙盒配置文件， 重新启动。
对于64位系统，cat system-sandbox64.json ，cat chipset-sandbox64.json。
- 代码路径下：base/startup/init_lite/interfaces/innerkits/sandbox 修改对应沙盒配置文件。
### 开发实例
沙盒JSON文件配置<a name = "sandbox"></a>
```json
{
"sandbox-root" : "/mnt/sandbox/system",
"mount-bind-paths" : [{
"src-path" : "/system/lib/ndk",
"sandbox-path" : "/system/lib/ndk",
"sandbox-flags" : [ "bind", "rec", "private" ]
}],
"mount-bind-files" : [{
"src-path" : "/system/lib/ld-musl-aarch64.so.1",
"sandbox-path" : "/system/lib/ld-musl-aarch64.so.1",
"sandbox-flags" : [ "bind", "rec", "private" ]
}],
"symbol-links" : [{
"target-name" : "/vendor/lib",
"link-name" : "/lib"
}]
}
```
## 常见问题
### 沙盒没有创建成功
**现象描述**
dmesg或者hilog日志中出现 Sandbox %s has not been created.
**原因分析**
沙盒没有创建成功，主要原因是mount与link时出现错误，根据mount与link的主要函数的日志，排查具体问题。
**解决方法**
1. 检查JSON文件是否配置正确。
2. 创建的沙盒是否受支持。
\ No newline at end of file
zh-cn/device-dev/subsystems/subsys-boot-init-service.md 0 → 100644
浏览文件 @ d6de7eb7
此差异已折叠。
zh-cn/device-dev/subsystems/subsys-boot-init-sysparam.md 0 → 100644
浏览文件 @ d6de7eb7
# 系统参数
## 概述
### 功能简介
OHOS系统参数为各系统服务提供简单易用的键值对访问接口，使得各个系统服务可以通过各自的系统参数来进行业务功能的配置。
### 基本概念
图1 系统参数操作原语
![系统参数操作原语](figures/系统参数操作原语.png)
**表1** 系统参数操作原语说明
| 功能 | 说明 |
| -------- | -------- |
| get | 获取系统参数的值 |
| set | 设置系统参数的值 |
| wait | 同步等待系统参数的值变更 |
| watch | 异步观察系统参数的值变更 |
#### 系统参数定义
- 系统参数命名格式
系统参数名称采用点分格式，由多段组成，每一段可以由字母、数字、下划线组成，总长度不超过96字节；系统参数名称分为两类：
**表2** 系统参数名称
| 类别 | 名称 | 示例 | 说明 |
| -------- | -------- | -------- | -------- |
| 参数名称 | Parameter Name | const.product.**name** | 完整的系统参数名称，末尾不是"."。 |
| 参数目录 | Parameter Directory | const.product **.** | 以"."结尾，标识相同前缀的所有系统参数集合。 |
- 系统参数类型
系统参数一共分为三大类：
**表3** 系统参数分类
| 类别 | 前缀 | 说明 |
| -------- | -------- | -------- |
| 常量 | const. | 常量参数，一旦赋值后续不会再变更；值最大长度为4096字节（包括结束符）。 |
| 可写 | 其它 | 可写参数，重启后丢失，值最大长度96字节（包括结束符）。|
| 可持久化 | persist. | 可写并可持久化保存参数，重启后不会丢失，值最大长度96字节（包括结束符）。|
每个系统参数名称总体格式如下：
```
[ const | persist ].$sub_system.$desc
```
$sub_system为子系统或模块的名称。
$desc为子系统或模块下参数的描述字符，可以为点分格式进行分级描述。
#### 系统参数定义规则
每个子系统定义各自模块的系统参数，包括系统参数名称、默认值以及系统参数的权限访问信息。
- 系统参数值定义文件
- 系统参数值定义文件后缀名为".para" ，其格式示例如下：
```shell
# This is comment
const.product.name=OHOS-PRODUCT
const.os.version.api=26
const.telephony.enable=false|true
const.test.withblank=My Value
const.test.withcomment=MyValue # This should be ommitted
const.test.multiline="This is a multiline parameter.
Line2 value.
Last line."
```
- 系统参数必须通过完整的系统参数命令来赋值，赋值方式分为三大类：
**表4** 系统参数赋值方式
| 类别 | 示例 | 说明 |
| -------- | -------- | -------- |
| 字符串 | const.product.name=OHOS-PRODUCT | 多行字符串需要通过引号扩起来。 |
| 数字 | const.os.version.api=26 | 数字不需要。|
| 布尔 | const.telephony.enable=false | 布尔型的可以为0,1,false,true。|
- 系统参数DAC访问控制定义文件
当前系统参数的访问权限控制通过自主访问控制（Discretionary Access Control）方式管理，访问权限定义文件后缀名为".para.dac" ，示例如下：
```java
const.product.="root:root:660"
```
如上所示，可以通过参数路径为相同前缀的所有系统参数定义一类访问权限信息；DAC信息通过":"分三段来描述，分别为参数的user，group以及UGO规则信息。
UGO规则信息每一位的定义如下：
**图2** UGO规则信息
![UGO规则信息](figures/系统参数DAC.png)
- 默认参数加载
系统参数的加载顺序如下：
**表5** 系统参数加载顺序
| 类别 | 路径 | 说明 |
| -------- | -------- | -------- |
| 内核参数 | /proc/cmdline | 将内核参数中的部分值转化成系统参数，并保存。内核参数中.xxx=valXXX类型的参数都转换成ohos.boot.xxx=valXXX系统参数。 |
| OS系统参数 | /system/etc/param/ohos_const/*.para | OS固定系统参数值参数优先加载。 |
| vendor参数 | /vendor/etc/param/*.para | 厂商定义的系统参数次优先级加载。 |
| system参数 | /system/etc/param/*.para | 加载各子系统定义的参数参数。如果系统参数已经存在，则忽略掉。 |
| persist参数 | /data/parameters/ | 如果持久化参数存在，则最后加载持久化系统参数。持久化系统参数会覆盖加载的默认系统参数。 |
### 约束与限制
仅限小型系统、标准系统下使用。
## 开发指导
### 场景介绍
设定特定的系统参数
### 接口说明
- Shell命令接口
通过shell命令中可直接操作系统参数（只在标准系统提供）。系统参数shell命令如下表所示：
**表6** 系统参数shell命令说明
| 功能 | 说明 |
| -------- | -------- |
| param get [**key**] | 获取指定key名称的系统参数值；如果不指定任何name，则返回所有系统参数值。 |
| param set **key value** | 设置指定key名称的参数值为value。 |
| param wait **key** **value** | 同步等待指定key名称的系统参数值与value匹配。value可支持模糊匹配，如"*"表示任何值，"val\*"表示只匹配前三个val字符。 |
| param watch | 异步观察系统参数的值变更。|
- syspara系统接口
在Coding中可以调用下列函数接口，获取对应的系统参数值（系统参数接口返回的为const字符串，不支持free操作）。
**表7** 系统属性接口说明
| 接口名 | 描述 |
| -------- | -------- |
| int&nbsp;GetParameter(const&nbsp;char\*&nbsp;key,&nbsp;const&nbsp;char\*&nbsp;def,&nbsp;char\*&nbsp;value,&nbsp;unsigned&nbsp;int&nbsp;len) | 获取系统参数。 |
| int&nbsp;SetParameter(const&nbsp;char\*&nbsp;key,&nbsp;const&nbsp;char\*&nbsp;value) | 设置/更新系统参数。 |
| const&nbsp;char\*&nbsp;GetDeviceType(void) | 返回当前设备类型。 |
| const&nbsp;char\*&nbsp;GetManufacture(void) | 返回当前设备生产厂家信息。 |
| const&nbsp;char\*&nbsp;GetBrand(void) | 返回当前设备品牌信息。 |
| const&nbsp;char\*&nbsp;GetMarketName(void) | 返回当前设备传播名。 |
| const&nbsp;char\*&nbsp;GetProductSeries(void) | 返回当前设备产品系列名。 |
| const&nbsp;char\*&nbsp;GetProductModel(void) | 返回当前设备认证型号。 |
| const&nbsp;char\*&nbsp;GetSoftwareModel(void) | 返回当前设备内部软件子型号。 |
| const&nbsp;char\*&nbsp;GetHardwareModel(void) | 返回当前设备硬件版本号。 |
| const&nbsp;char\*&nbsp;GetHardwareProfile(void) | 返回当前设备硬件profile。 |
| const&nbsp;char\*&nbsp;GetSerial(void) | 返回当前设备序列号（SN号）。 |
| const&nbsp;char\*&nbsp;GetOSFullName(void) | 返回操作系统名。 |
| const&nbsp;char\*&nbsp;GetDisplayVersion(void) | 返回当前设备用户可见的软件版本号。 |
| const&nbsp;char\*&nbsp;GetBootloaderVersion(void) | 返回当前设备Bootloader版本号。 |
| const&nbsp;char\*&nbsp;GetSecurityPatchTag(void) | 返回安全补丁标签。 |
| const&nbsp;char\*&nbsp;GetAbiList(void) | 返回当前设备支持的指令集（Abi）列表。 |
| int&nbsp;GetSdkApiVersion(void) | 返回与当前系统软件匹配的SDK&nbsp;API&nbsp;版本号。 |
| int&nbsp;GetFirstApiVersion(void) | 返回系统软件首版本SDK&nbsp;API&nbsp;版本号。 |
| const&nbsp;char\*&nbsp;GetIncrementalVersion(void) | 返回差异版本号。 |
| const&nbsp;char\*&nbsp;GetVersionId(void) | 返回版本id。 |
| const&nbsp;char\*&nbsp;GetBuildType(void) | 返回构建类型。 |
| const&nbsp;char\*&nbsp;GetBuildUser(void) | 返回构建账户用户名。 |
| const&nbsp;char\*&nbsp;GetBuildHost(void) | 返回构建主机名。 |
| const&nbsp;char\*&nbsp;GetBuildTime(void) | 返回构建时间。 |
| const&nbsp;char\*&nbsp;GetBuildRootHash(void) | 返回当前版本hash。 |
| const&nbsp;char\*&nbsp;GetOsReleaseType(void) | 返回系统发布类型。 |
| int&nbsp;GetDevUdid(char&nbsp;\*udid,&nbsp;int&nbsp;size) | 获取设备udid。 |
| const char *AclGetSerial(void); | 返回当前设备序列号（SN号）（带访问权限检查）。 |
| int AclGetDevUdid(char *udid, int size); | 获取设备udid（带访问权限检查）。 |
### 开发步骤
1. 系统参数定义
通过定义子系统或者产品的.para和.para.dac文件，实现默认系统参数的定义和权限控制。
​ 在标准系统上通过ohos_prebuilt_para模版安装配置文件到到/etc/param/目录下，GN脚本示例如下：
```go
import("//base/startup/init_lite/services/etc/param/param_fixer.gni")
ohos_prebuilt_para("ohos.para") {
source = "//base/startup/init_lite/services/etc/ohos.para"
part_name = "init"
module_install_dir = "etc/param"
}
ohos_prebuilt_para("ohos.para.dac") {
source = "//base/startup/init_lite/services/etc/ohos.para.dac"
part_name = "init"
module_install_dir = "etc/param"
}
```
在小系统上，通过copy命令，把对应的系统参数定义文件拷贝到system/etc/param目录下
```go
copy("ohos.para") {
sources = [ "//base/startup/init_lite/services/etc/param/ohos.para" ]
outputs = [ "$root_out_dir/system/etc/param/ohos.para" ]
}
copy("ohos.para.dac") {
sources = [ "//base/startup/init_lite/services/etc/param/ohos.para.dac" ]
outputs = [ "$root_out_dir/system/etc/param/ohos.para.dac" ]
}
```
在mini系统上，通过action把所有定义的默认系统参数转化成头文件，并编译到系统中
```go
action("lite_const_param_to") {
script = "//base/startup/init_lite/scripts/param_cfg_to_code.py"
args = [
"--source",
rebase_path(
"//base/startup/init_lite/services/etc_lite/param/ohos_const/ohospara"),
"--dest_dir",
rebase_path("$root_out_dir/gen/init_lite/"),
"--priority",
"0",
]
outputs = [ "$target_gen_dir/${target_name}_param_cfg_to_code.log" ]
}
```
2. 系统参数使用实例
```
// set && get
char key1[] = "rw.sys.version";
char value1[] = "10.1.0";
int ret = SetParameter(key1, value1);
char valueGet1[128] = {0};
ret = GetParameter(key1, "version=10.1.0", valueGet1, 128);
// get sysparm
char* value1 = GetDeviceType();
printf("Product type =%s\n", value1);
char* value2 = GetManufacture();
printf("Manufacture =%s\n", value2);
char* value3 = GetBrand();
printf("GetBrand =%s\n", value3);
char* value4 = GetMarketName();
printf("MarketName =%s\n", value4);
char* value5 = GetProductSeries();
printf("ProductSeries =%s\n", value5);
char* value6 = GetProductModel();
printf("ProductModel =%s\n", value6);
char* value7 = GetSoftwareModel();
printf("SoftwareModel =%s\n", value7);
char* value8 = GetHardwareModel();
printf("HardwareModel =%s\n", value8);
char* value9 = GetHardwareProfile();
printf("Software profile =%s\n", value9);
char* value10 = GetSerial();
printf("Serial =%s\n", value10);
char* value11 = GetOSFullName();
printf("OS name =%s\n", value11);
char* value12 = GetDisplayVersion();
printf("Display version =%s\n", value12);
char* value13 = GetBootloaderVersion();
printf("bootloader version =%s\n", value13);
char* value14 = GetSecurityPatchTag();
printf("secure patch level =%s\n", value14);
char* value15 = GetAbiList();
printf("abi list =%s\n", value15);
int value16 = GetFirstApiVersion();
printf("first api level =%d\n", value16);
char* value17 = GetIncrementalVersion();
printf("Incremental version = %s\n", value17);
char* value18 = GetVersionId();
printf("formal id =%s\n", value18);
char* value19 = GetBuildType();
printf("build type =%s\n", value19);
char* value20 = GetBuildUser();
printf("build user =%s\n", value20);
char* value21 = GetBuildHost();
printf("Build host = %s\n", value21);
char* value22 = GetBuildTime();
printf("build time =%s\n", value22);
char* value23 = GetBuildRootHash();
printf("build root later..., %s\n", value23);
char* value24 = GetOsReleaseType();
printf("OS release type =%s\n", value24);
char* value25 = GetOsReleaseType();
printf("OS release type =%s\n", value25);
char value26[65] = {0};
GetDevUdid(value26, 65);
printf("device udid =%s\n", value26);
```
\ No newline at end of file
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或