android 获取应用分身启动开发

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 内核补丁，补丁链接如下。

6.3 Access Token 调测知识

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

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