OpenHarmony 实战开发——3.1 Release + Linux 原厂内核Launcher起不来问题分析报告

1、关键字

Launcher 无法启动；原厂内核；Access Token ID；

2、问题描述

芯片：rk3566；rk3399

内核版本：Linux 4.19，是 RK 芯片原厂发布的 rk356x 4.19 稳定版内核

OH 版本：OpenHarmony 3.1 Release

问题现象：将 OpenHarmony kernel 修改移植到 rk3566 上，对接 OpenHarmony 3.1 Release 版本，Launcher 起不来，移植停留在开机动画界面。

移植步骤：

1)、导入 rk356x 芯片厂家内核到构建系统中。
2)、收到合入 hdf patch
3)、移植 accesstoken id 驱动
4)、dts 文件适配开发板
5)、defconfig 使用的是 Linux 5.10 rk3568 的 config 文件

3、问题原因

3.1 正常机制

应用能够正常安装

3.1.1 应用安装相关过程

应用安装时会使用分布式数据库 KvStore 更新 metaData，KvStore 会调用阮总先接口获取 LocalDeviceId。

对应代码调用关系：

KvStoreDataService::UpdateMetaData()

–>kv_store，DeviceKvStoreImpl::GetLocalDeviceId()

–> kv_store，KvStoreUtils::GetProviderInstance().GetLocalDevice()

–>SoftBus IPC 接口，SoftBusAdapter::GetLocalDevice()

–>SoftBus IPC 接口，GetLocalNodeDeviceInfo()

–>SoftBus Server，GetLocalNodeDeviceInfo()

3.1.2 软总线 SA 初始化相关过程

SoftBusServer::OnStart() // 软总线 SA 启动函数

foundation\communication\dsoftbus\core\frame\standard\init\src\softbus_server.cpp softbus_server.cpp

----> InitSoftBusServer() // 调用软总线初始化

foundation\communication\dsoftbus\core\frame\common\src\softbus_server_frame.c

----> AuthInit() // 调用认证管理模块初始化

foundation\communication\dsoftbus\core\authentication\src\auth_manager.c auth_manager.c

----> HichainServiceInit() // 调用 Hichain 初始化

foundation\communication\dsoftbus\core\authentication\src\auth_manager.c auth_manager.c

---->GetGmInstance()->regDataChangeListener

// 调用安全子系统设备互信认证部件的接口获取设备群组管理实例，然后注册数据变化 Listener

foundation\communication\dsoftbus\core\authentication\src\auth_manager.c auth_manager.c

---->IpcGmRegDataChangeListener() //即调用中的 IpcGmRegDataChangeListener 函数

base\security\deviceauth\frameworks\src\ipc_sdk.c

---->DoBinderCall()

base\security\deviceauth\frameworks\src\standard\ipc_adapt.cpp

----> ProxyDevAuthData::ActCall

base\security\deviceauth\frameworks\src\standard\ipc_dev_auth_proxy.cpp

----> ProxyDevAuth::DoCallRequest()

base\security\deviceauth\frameworks\src\standard\ipc_dev_auth_proxy.cpp

----> ServiceDevAuth::OnRemoteRequest //IPC 调用到服务端

base\security\deviceauth\frameworks\src\standard\ipc_dev_auth_stub.cpp

----> Security::AccessToken::CheckPermission() //调用 AccessTokenKit 检验调用者权限

base\security\deviceauth\services\frameworks\src\permission_adapter\permission_adapter.cpp

3.2 异常机制

Access Token 补丁没有合入全面，导致软总线 SA 初始化失败，导致服务异常、分布式数据库 GetLocalDevice 失败，进一步导致应用安装失败

4 解决方案

补齐 kernel/fork.c 中关于 Access Token 的修改，补齐后验证应用可以正常起来。

5 定位过程

5.1 应用安装失败的原因

软总线 SA 初始化失败，导致服务异常或者 Crash，导致分布式数据库 GetLocalDevice 失败，进一步导致应用安装失败。

关键异常打印如下：

dsoftbus_standard: [LNN]init softbus failed

SoftBusAdapter::GetLocalDevice: GetLocalNodeDeviceInfo error

KvStoreDataService::UpdateMetaData: failed to get local device id KvStoreDataService::GetSingleKvStore: failed to write meta

BundleMgrService: [distributed_data_storage.cpp(GetKvStore):237] return error

5.2 软总线 SA 初始化失败的原因

因为软总线 SA 的 AccessToken tokenID 不合法，在 Hichain 初始化时 ProxyDevAuth::DoCallRequest 被设备认证服务端校验权限不通过，打印 tokenID is invalid，导致 hichain init failed，进一步导致 softbus framework init failed。

关键异常打印如下：

08-04 09:00:28.085 291 1127 I 00000/[DEVAUTH]: DoCallRequest: ProxyDevAuth, SendRequest…

08-04 09:00:28.085 263 536 I 02f01/AccessTokenKit: [GetTokenType]:GetTokenType called

08-04 09:00:28.085 263 536 E 02f01/AccessTokenKit: [GetTokenType]:tokenID is invalid

08-04 09:00:28.085 263 536 E 00000/[DEVAUTH]: CheckPermission: Invalid token type: -1

08-04 09:00:28.085 291 1127 I 00000/[DEVAUTH]: DoCallRequest: SendRequest done, ret -1

08-04 09:00:28.085 291 1127 I 00000/[DEVAUTH]: IpcGmRegDataChangeListener: process done, ret 12289

08-04 09:00:28.085 291 1127 E 015c0/dsoftbus_standard: [AUTH]auth RegDataChangeListener failed

08-04 09:00:28.085 291 1127 E 015c0/dsoftbus_standard: [AUTH]auth hichain init failed

08-04 09:00:28.085 291 1127 E 015c0/dsoftbus_standard: [COMM]softbus auth init failed.

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [AUTH]unregister auth trans callback, module = 1.

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [TRAN]PendigPackManagerDeinit init ok

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [AUTH]unregister auth trans callback, module = 0.

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [TRAN]server trans udp channel deinit success.

08-04 09:00:28.086 291 1127 E 015c0/dsoftbus_standard: [COMM]softbus framework init failed.

5.3 AccessToken TokenID 不合法的原因

跑 access_token_id 的 XTS 用例，发现如下用例不过，子线程的 access token id 信息不对，ftoken 跟父线程一致，实际应该为 0。

推断创建线程时给 token id 初始化的值不对，可能是 kernel/fork.c 中 kernel/fork.c 的 patch 没打上。

让伙伴检查这段代码，确定是上述 kernel/fork.c 中的代码漏合导致。

6 知识分享

6.1 Access Token 介绍

Access Token 是 3.1 release 安全子系统新增的应用权限访问控制功能和权限增强特性，支持应用程序或者其他 SA 查询和校验应用权限、APL(Ability Privilege Level )等信息。

在 OpenHarmony 服务化的应用程序框架中，一切程序都是服务（元能力）。任何元能力间的访问，都需要进行访问权限控制。访问控制的机制通过采用 AT 访问令牌传递和令牌访问控制的策略来实现。

一个 AT 访问令牌由：

设备标识 DevID
应用身份标识 APP ID
子用户 ID
应用分身索引信息
SA 服务 ID( SA 服务名字)
TokenID ，表示权限令牌 ID，跨设备全局唯一。64bit。由以上字段结合场景进行组合生成，以 lib 形式提供生成 TokenID.

Android 的应用访问权限管控手段，是面向实现的设计，比较混乱，包括 Platform 签名、Privilege 特权应用、UID=1000 特权、MDM 权限证书等等，且不能应用于分布式场景。OpenHarmony 的 Access Token 机制，有总体的设计，能够分布式传输。

OpenHarmony 应用程序框架提供的 API，分成 Signature、Privilege 和 Normal 三级。

API 等级/APL 等级	APL 3	APL 2	APL 1
API Level Signature	Y	N	N
API Level Privilege	Y	Y	N
API Level Normal	Y	Y	Y

凡是不能访问的 API，必须通过 AACL（API ACL）机制来实现策略的关联。

6.2 Access Token 内核补丁

在使用三方内核适配 OpenHarmony 系统时，需要打上 Access Token 内核补丁，补丁链接如下。

https://gitee.com/openharmony/kernel_linux_4.19/pulls/4

https://gitee.com/openharmony/kernel_linux_4.19/pulls/5

6.3 Access Token 调测知识

补丁打成功后，会有相应的的字符设备/dev/access_token 用于和用户态交互。

并且在每个进程或线程的 pcb 信息中会有 tokenid 信息，包括自身 tokenid 和首调者 tokenid。

码牛课堂也为了积极培养鸿蒙生态人才，让大家都能学习到鸿蒙开发最新的技术，针对一些在职人员、0基础小白、应届生/计算机专业、鸿蒙爱好者等人群，整理了一套纯血版鸿蒙（HarmonyOS Next）全栈开发技术的学习路线。大家可以进行参考学习：https://qr21.cn/FV7h05

①全方位，更合理的学习路径：
路线图包括ArkTS基础语法、鸿蒙应用APP开发、鸿蒙能力集APP开发、次开发多端部署开发、物联网开发等九大模块，六大实战项目贯穿始终，由浅入深，层层递进，深入理解鸿蒙开发原理！

②多层次，更多的鸿蒙原生应用：
路线图将包含完全基于鸿蒙内核开发的应用，比如一次开发多端部署、自由流转、元服务、端云一体化等，多方位的学习内容让学生能够高效掌握鸿蒙开发，少走弯路，真正理解并应用鸿蒙的核心技术和理念。

③实战化，更贴合企业需求的技术点：
学习路线图中的每一个技术点都能够紧贴企业需求，经过多次真实实践，每一个知识点、每一个项目，都是码牛课堂鸿蒙研发团队精心打磨和深度解析的成果，注重对学生的细致教学，每一步都确保学生能够真正理解和掌握。

为了能让大家更好的学习鸿蒙（HarmonyOS NEXT）开发技术，这边特意整理了《鸿蒙开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05