1### Usage Guide 2 3## 简介 4 5h2sa工具，即SERVICE框架生成工具，当开发者为OpenHarmony系统框架开发某些功能时，有时需要将这个功能包装成一个独立的服务进程运行在系统中，为了其它应用进程能够调用此服务，开发人员需要基于系统IPC通信框架编写一套远程接口调用实现。实现Service远程调用接口需要开发人员熟悉IPC通信框架，了解proxy/stub的继承与实现方式，掌握C++类型转为MessageParcel数据包的各种API方法，有一定的学习成本。而Service代码生成工具能够帮助使用者生成框架代码，提升开发效率。用户只需提供一个定义远程方法的.h头文件，工具会自动生成整个Service框架的代码，包含Ability注册、proxy/stub类实现、MessageParcel数据包构造、Service子系统编译及开机自启动相关配置文件。 6 7## 约束 8 9系统：建议Ubuntu 20.04或者Windows 10 10 11依赖版本：VS Code 1.62.0 12 13## 使用方法 14 15#### 命令行 16 171. 安装python库 CppHeaderParser 18 19 ~~~ 20 pip install CppHeaderParser 21 ~~~ 22 232. 安装typescript：在napi_generator/src/cli/h2sa/src目录下执行命令 24 25 ~~~ 26 npm i typescript 27 ~~~ 28 293. 安装stdio：在napi_generator/src/cli/h2sa目录下执行命令 30 31 ~~~ 32 npm i stdio 33 ~~~ 34 354. 在napi_generator/src/cli/h2sa/src/gen目录下执行命令生成service框架代码： 36 37 ~~~ 38 node main.js -f test.h 39 ~~~ 40 41其中,参数详情如下： 42 43-f，定义远程服务的.h文件； 44 45-l，可选参数，日志级别（0-3），默认为1； 46 47-o，可选参数，生成框架代码输入到指定路径下； 48 49-s，可选参数，指定serviceID，默认为19000； 50 51-v，可选参数，指定版本（3.2和4.1，默认版本为3.2） 52 53#### 生成物 54 551. 输出testservice文件夹，其中的文件如下所示： 56 57  58 59 ~~~ 60 ├── BUILD.gn # 整个服务的编译文件，包含2个内容:1)服务端程序动态库编译 2)客户端可执行程序编译 61 ├── bundle.json # 将服务包装成一个OpenHarmoney子系统组件，提供相关信息 62 ├── etc # 服务启动配置目录，如果服务不需要开机自动启动，可以删除此目录。 63 │ ├── BUILD.gn 64 │ └── test_service.cfg # 服务自启动配置文件，编译烧录后会在/ect/init/下生成xxx_service.cfg启动文件 65 ├── include 66 │ ├── test_service.h # 服务端头文件 67 │ ├── test_service_proxy.h # proxy 客户端头文件，为开发人员封装remote请求发送的处理 68 │ └── test_service_stub.h # stub 服务端头文件，为开发人员封装remote请求接收的处理 69 ├── interface 70 │ └── i_test_service.h # 由用户提供的.h文件生成的remote接口文件，stub和proxy都基于此文件实现接口。 71 ├── sa_profile 72 │ ├── 19000.json # 服务配置文件 73 │ └── BUILD.gn 74 └── src 75 ├── i_test_service.cpp # 接口实现文件 76 ├── test_client.cpp # 客户端程序 77 ├── test_service.cpp # 服务端程序 78 ├── test_service_proxy.cpp # 客户端代理实现 79 └── test_service_stub.cpp # 服务端 stub 实现 80 ~~~ 81 82#### 应用和验证 83 841. 将生成的testservice文件夹放在对应版本的源码根目录下 85 862. 修改服务配置文件 87 88 在foundation/systemabilitymgr/samgr/interfaces/innerkits/samgr_proxy/include/system_ability_definition.h增加以下一行： 89 90 ``` 91 TEST_SERVICE_ID = {serviceID}, //保证ID与参数-s的值一致且没有重复，例如：默认值19000 92 ``` 93 943. 修改子系统配置文件 95 96 在build/subsystem_config.json中增加以下内容。 97 98 ``` 99 "testservice": { 100 "path":"testservice", 101 "name": "testservice" 102 } 103 ``` 104 1054. 修改产品配置，如rk3568 106 107 在vendor/hihope/rk3568/config.json中增加以下内容： 108 109 ``` 110 { 111 "subsystem": "testservice", 112 "components": [ 113 { 114 "component": "testservice_part", 115 "features": [] 116 } 117 ] 118 } 119 ``` 120 1215. 修改权限配置 122 123 在相应的产品目录的vendor/hihope/rk3568/security_config/high_privilege_process_list.json中增加以下内容： 124 125 ``` 126 { 127 "name": "testservice", 128 "uid": "system", 129 "gid": ["root", "system"] 130 } 131 ``` 132 1336. selinux权限配置 134 135 vendor/hihope/rk3568/config.json中"build_selinux"属性若为true， 即要配置selinux权限，应修改以下文件；若为false，无需修改 136 137 > 1. testservice/etc/sample_service.cfg 138 > 139 > ``` 140 > "secon" : "u:r:testservice:s0" 141 > ``` 142 > 143 > 2. base/security/selinux_adapter/sepolicy/base/public/service_contexts 144 > 145 > ``` 146 > 9016 u:object_r:sa_testservice:s0 147 > ``` 148 > 149 > 3. base/security/selinux_adapter/sepolicy/base/public/service.te 150 > 151 > ``` 152 > type sa_testservice, sa_service_attr; 153 > ``` 154 > 155 > 4. base/security/selinux_adapter/sepolicy/ohos_policy/startup/init/system/init.te 156 > 157 > ``` 158 > allow init testservice:process { getattr rlimitinh siginh transition }; 159 > ``` 160 > 161 > 5. base/security/selinux/sepolicy/base/public/type.te 162 > 163 > ``` 164 > type testservice, sadomain, domain; 165 > ``` 166 > 167 > 6. /base/security/selinux/sepolicy/base/te目录下增加新service的te文件，新增文件名即为服务名，例如：testservice.te 168 > 169 > ``` 170 > allow testservice init_param:file { map open read }; 171 > allow testservice sa_testservice:samgr_class { add get }; 172 > ``` 173 1747. 编码完成后，执行镜像编译命令 175 176 ~~~ 177 ./build.sh --product-name 产品名 178 179 若编译rk3568开发板，则执行 180 ./build.sh --product-name rk3568 181 ~~~ 182 1838. 烧录镜像 184 1859. 运行验证 186 187 >验证一： shell登录开发板。 查看服务端进程是否已正常启动 188 > 189 >~~~ 190 >ps -ef | grep testservice 191 >system 288 1 0 00:02:13 ? 00:00:00 testservice_sa --- 服务进程已正常运行 192 >~~~ 193 > 194 >验证二：运行客户端 195 > 196 >~~~ 197 >/system/bin/testclient 198 >~~~
