openharmony北向开发基础之OpenHarmony签名机制详解

OpenHarmony 签名机制详解

一、签名文件概述

OpenHarmony 的签名体系基于 PKI（公钥基础设施），核心文件包括：

文件类型	扩展名	说明
密钥库文件	`.p12` / `.jks`	存储签名密钥对（私钥+证书链），PKCS#12 格式
应用签名证书	`.pem`	X.509 证书链，标识应用开发者身份
Profile 签名证书	`.pem`	用于签名 ProvisionProfile 的证书
Profile 文件	`.p7b`	签名后的应用权限描述文件（ProvisionProfile）
根 CA 证书	`.cer`	信任锚点，系统预置

知识点延伸 ：.p12 和 .jks 都是密钥库格式。.p12 是 PKCS#12 标准（跨平台），.jks 是 Java 专有格式。OpenHarmony 统一使用 .p12，密钥算法为 ECC（NIST-P-256），签名算法为 SHA256withECDSA。

二、签名文件在编译镜像中的位置

当执行 ./build.sh --product-name <your_product> 编译时，系统使用的签名文件位于：

复制代码

developtools/hapsigner/dist/
├── OpenHarmony.p12                     # 默认密钥库（含密钥对）
├── OpenHarmonyApplication.pem          # 默认应用签名证书
├── OpenHarmonyProfileRelease.pem       # Release Profile 签名证书
├── OpenHarmonyProfileDebug.pem         # Debug Profile 签名证书
├── UnsgnedReleasedProfileTemplate.json # Release Profile 模板（未签名）
├── UnsgnedDebugProfileTemplate.json    # Debug Profile 模板（未签名）
└── hap-sign-tool.jar                   # 签名工具

编译系统在 build/ohos_var.gni 中定义了默认签名参数：

gni 复制代码

hapsigner = "//developtools/hapsigner/dist/hap-sign-tool.jar"
default_key_alias = "OpenHarmony Application Release"
default_signature_algorithm = "SHA256withECDSA"
default_hap_private_key_path = "123456"   # 实际是 keyPwd（密钥密码）
default_keystore_password = "123456"
default_keystore_path = "//developtools/hapsigner/dist/OpenHarmony.p12"
default_hap_certificate_file = "//developtools/hapsigner/dist/OpenHarmonyApplication.pem"

注意：default_hap_private_key_path 变量名有误导性，它实际存储的是密钥密码（keyPwd），而非密钥文件路径。这是 OpenHarmony 构建系统的一个命名缺陷。

三、签名的作用

签名在 OpenHarmony 中承担以下核心职责：

完整性校验 --- 确保应用包（HAP/HSP）未被篡改
身份标识 --- 标识应用来源（开发者/厂商/系统）
权限授予 --- Profile 中声明的 APL 等级和权限依赖签名验证
代码签名 --- 运行时校验代码段合法性，防止恶意注入
安装校验 --- 包管理服务在安装时验证签名有效性

四、四种开发场景的签名使用方式

场景 1：操作系统级开发（系统镜像编译）

适用情况 ：编译整个 OpenHarmony 系统镜像，如 ./build.sh --product-name <your_product>

使用的签名文件 ：developtools/hapsigner/dist/OpenHarmony.p12（系统内置）

工作流程：

复制代码

源码中的 HAP 模块（ohos_hap GN 模板）
    → GN 调用 hapbuilder.py 或 app_sign.py
    → 使用 OpenHarmony.p12 中的密钥对 HAP 签名
    → 传入预签名的 Profile（.p7b）作为 --profileFile
    → --profileSigned=1（Profile 已提前签名，不是现场签名）
    → 签名后的 HAP 打入系统镜像

特点：

使用 OpenHarmony 官方预置密钥，所有源码编译的系统应用共用
Profile 中 app-distribution-type 为 os_integration（系统集成）
可声明 system_basic / system_core 级别 APL
密码均为默认 123456（开发阶段，量产应替换）

知识点 ：--profileSigned=1 表示传入的 Profile 是已经用 Profile 签名证书签过的 .p7b 文件，签名工具不会再对其签名，只是将其嵌入 HAP 包。如果传入 0，则表示 Profile 是未签名的 JSON，工具会用密钥库对其签名后嵌入。

场景 2：系统级预装应用（厂商预装 HAP）

适用情况：厂商开发的系统应用，以预编译 HAP 形式放入 vendor 目录

使用的签名文件 ：厂商自己的 .p12 或使用系统源码中的 OpenHarmony.p12

工作流程：

复制代码

厂商开发 HAP（DevEco 或命令行）
    → 使用厂商私有 .p12 签名
    → Profile 中 app-distribution-type 设为 "os_integration"
    → 将签名后的 HAP 放入 vendor/<vendor_name>/xxx/app/ 目录
    → 编译系统将其打入镜像（不重新签名）

特点：

如果 HAP 已签名，编译系统直接打包，不会重签
如果 HAP 未签名（源码编译），编译系统使用默认 OpenHarmony.p12 签名
厂商可定制自己的根 CA 并预置到系统信任链

场景 3：DevEco Studio 开发的系统应用

适用情况：使用 DevEco Studio IDE 开发系统级应用，需要安装到真机调试或发布

使用的签名文件：DevEco 自动生成的调试签名或厂商提供的发布签名

工作流程：

调试阶段（自动签名）：

复制代码

DevEco Studio
    → 自动生成调试用 .p12 密钥库
    → 向华为 AppGallery Connect 申请调试 Profile（.p7b）
    → 使用调试证书签名 HAP
    → 安装到设备调试

发布阶段（手动签名）：

复制代码

开发者
    → 在 AppGallery Connect 申请发布证书
    → 下载发布用 Profile（.p7b）
    → 在 DevEco 中配置签名信息
    → 使用发布证书签名 HAP
    → 提交应用市场审核

特点：

调试签名自动生成，有效期短，仅限调试设备
发布签名需向华为/厂商 CA 申请
Profile 中 app-distribution-type 通常为 app_gallery
APL 等级受 Profile 约束（普通开发者最高 normal，申请 system_basic 需厂商审批）

场景 4：普通三方应用

适用情况：第三方开发者开发的普通应用

使用的签名文件：开发者自己申请的证书 + 从应用市场获取的 Profile

工作流程：

复制代码

开发者
    → 在 AppGallery Connect 创建应用
    → 生成密钥库 .p12（本地保管）
    → 生成 CSR 上传到 AGC，获取签名证书
    → 下载 Profile（.p7b）
    → DevEco 中配置签名
    → 签名打包 HAP
    → 发布到应用市场

特点：

.p12 由开发者本地生成并保管
证书和 Profile 由华为/厂商 CA 颁发
APL 等级为 normal，无法使用系统级权限
app-distribution-type 为 app_gallery

五、什么时候用哪种签名文件

场景	使用的 .p12	使用的 Profile	典型命令/操作
编译整个系统镜像	`OpenHarmony.p12`（源码内置）	预签名的 `.p7b`（由 autosign 工具生成）	`./build.sh --product-name xxx`
厂商预装 HAP（已签名）	厂商私有 .p12	厂商签发的 .p7b	直接放入 vendor 目录
厂商预装 HAP（源码编译）	`OpenHarmony.p12`	编译系统使用预生成的 .p7b	GN 模板中的 `ohos_hap` 目标
DevEco 调试	IDE 自动生成的 .p12	AGC 申请的调试 Profile	DevEco → Run
DevEco 发布（系统应用）	开发者/厂商 .p12	厂商签发的 Release Profile	DevEco → Build → Release
三方应用发布	开发者 .p12	AGC 签发的 Release Profile	DevEco → Build → Release

六、签名文件的生成方式

6.1 系统编译默认签名文件（OpenHarmony.p12）

这个文件不是每次编译动态生成的 ，而是预置在源码仓库 developtools/hapsigner/dist/ 中。所有基于 OpenHarmony 源码编译的系统应用共用同一套签名。

生成方法（如需重新生成）：

bash 复制代码

cd developtools/hapsigner/autosign
python3 autosign.py autosign.config

autosign 工具会按照配置顺序执行：

generate-keypair --- 生成密钥对
generate-ca --- 生成根 CA 和中间 CA
generate-app-cert --- 生成应用签名证书
generate-profile-cert --- 生成 Profile 签名证书
sign-profile --- 对 Profile JSON 模板签名生成 .p7b
sign-app --- 对 HAP 签名（可选）

产出：

OpenHarmony.p12 --- 密钥库（含 app 密钥和 profile 密钥）
rootCA.cer / subCA.cer --- CA 证书
app1.pem --- 应用签名证书
profile1.pem --- Profile 签名证书
app1-profile.p7b --- 签名后的 Profile

6.2 DevEco Studio 自动生成

路径：~/.ohos/config/default/default_xxxx.p12

DevEco 在首次调试运行时自动生成本地调试密钥库，并向 AGC 申请调试证书和 Profile。

6.3 开发者手动生成

bash 复制代码

# 生成密钥库
java -jar hap-sign-tool.jar generate-keypair \
    -keyAlias "myapp-key" \
    -keyAlg "ECC" \
    -keySize "NIST-P-256" \
    -keystoreFile "myapp.p12" \
    -keyPwd "mypassword" \
    -keystorePwd "mypassword"

# 生成 CSR
java -jar hap-sign-tool.jar generate-csr \
    -keyAlias "myapp-key" \
    -signAlg "SHA256withECDSA" \
    -subject "C=CN,O=MyCompany,OU=Dev,CN=MyApp" \
    -keystoreFile "myapp.p12" \
    -outFile "myapp.csr" \
    -keyPwd "mypassword" \
    -keystorePwd "mypassword"

将 CSR 提交给 CA（华为 AGC 或厂商 CA），获取签名证书和 Profile。

七、签名信任链关系

复制代码

┌─────────────────────────────────────────┐
│           Root CA (根证书)                │ ← 预置在系统镜像中
└─────────────┬───────────────────────────┘
              │ 签发
┌─────────────▼───────────────────────────┐
│      Sub CA (中间 CA 证书)               │
└─────────┬───────────────┬───────────────┘
          │ 签发           │ 签发
┌─────────▼─────────┐  ┌──▼──────────────────┐
│ App Cert (应用证书)│  │ Profile Cert         │
│ → 签名 HAP 包      │  │ → 签名 Profile(.p7b) │
└───────────────────┘  └─────────────────────┘

系统验证时分两条链：

HAP 签名验证：HAP 签名 → 应用证书 → 中间 CA → 根 CA
Profile 签名验证：Profile(.p7b) 签名 → Profile 证书 → 中间 CA → 根 CA

两条链必须使用同一个根 CA，否则安装失败。

知识点 ：系统中的可信源管理（TrustedSourceManager）维护了一份可信证书列表。安装时先匹配应用签名证书是否来自可信源，如果来自可信源则走快速路径，否则需要完整验证 Profile。

八、APL（Ability Privilege Level）权限等级详解

8.1 什么是 APL

APL 是 OpenHarmony 的应用权限等级机制，决定了一个应用能申请哪些系统权限。

核心逻辑：Profile 中的 apl 字段 → 决定应用的权限上限

源码定义（base/security/access_token/interfaces/innerkits/accesstoken/include/access_token.h）：

cpp 复制代码

typedef enum TypeATokenAplEnum {
    APL_NORMAL = 1,
    APL_SYSTEM_BASIC = 2,
    APL_SYSTEM_CORE = 3,
} ATokenAplEnum;

APL 等级	枚举值	说明	谁能获得
`normal`	1	普通权限	所有应用
`system_basic`	2	系统基础权限	系统应用 / 厂商预装 / 企业应用
`system_core`	3	系统核心权限	最核心的系统服务

8.2 APL 与签名的关系

厂商用 .p12 构建镜像时确实可以创建 system_basic / system_core 级别的 APL。

具体机制：

APL 等级写在 Profile（.p7b） 内部 JSON 的 bundle-info.apl 字段
Profile 由 hap-sign-tool.jar sign-profile 命令签名生成
签名 Profile 需要 Profile 签名密钥 （存储在 .p12 中）
设备安装时，appverify 模块验证 Profile 的签名链是否可信
系统中预置的根 CA 是由镜像构建者（厂商）控制的

所以：厂商控制了密钥库 + 系统根 CA = 可以签发任意 APL 等级的 Profile。

8.3 权限的两种授予模式（grantMode）

权限不仅按 APL 等级分层，还按授予模式分类：

grantMode	说明	用户体验
`system_grant`	系统自动授予	安装时自动获得，无弹窗
`user_grant`	用户手动授予	运行时弹窗请求用户确认

例如：ohos.permission.CAMERA 是 normal + user_grant，任何应用都能申请，但需要用户点击允许。

8.4 各 APL 等级的典型权限

当前系统定义了 513+ 个权限 （systemGrantPermissions + userGrantPermissions），分布如下：

system_core：124 个
system_basic：332 个
normal：57 个

system_core 典型权限（最高级别，仅系统核心服务可用）

权限名	用途	grantMode
`ohos.permission.CAPTURE_SCREEN`	截屏/录屏	system_grant
`ohos.permission.CAMERA_BACKGROUND`	后台使用相机	system_grant
`ohos.permission.CAMERA_CONTROL`	相机底层控制	system_grant
`ohos.permission.ACCESS_DLP_FILE`	访问 DLP 加密文件	system_grant
`ohos.permission.ACCESS_CERT_MANAGER_INTERNAL`	访问证书管理内部接口	system_grant
`ohos.permission.CONTROL_LOCATION_SWITCH`	控制定位开关	system_grant
`ohos.permission.CONNECT_IME_ABILITY`	连接输入法服务	system_grant
`ohos.permission.ACCESS_IDS`	访问设备标识	system_grant
`ohos.permission.CHANGE_BUNDLE_UNINSTALL_STATE`	控制应用卸载状态	system_grant
`ohos.permission.COLLECT_SECURITY_EVENT`	收集安全事件	system_grant
`ohos.permission.GET_ALL_APP_ACCOUNTS`	获取所有应用账号	system_grant
`ohos.permission.DISABLE_PERMISSION_DIALOG`	禁用权限弹窗	system_grant
`ohos.permission.ACCESS_SCREEN_LOCK_INNER`	锁屏内部接口	system_grant
`ohos.permission.ATTACH_APP_DEBUG`	附加应用调试	system_grant
`ohos.permission.CAST_AUDIO_OUTPUT`	音频投播输出	system_grant

system_basic 典型权限（系统应用可用）

权限名	用途	grantMode
`ohos.permission.ACCESS_DISTRIBUTED_HARDWARE`	访问分布式硬件	system_grant
`ohos.permission.GET_RUNNING_INFO`	获取运行中进程信息	system_grant
`ohos.permission.CLEAN_APPLICATION_DATA`	清除应用数据	system_grant
`ohos.permission.MANAGE_SECURE_SETTINGS`	管理安全设置	system_grant
`ohos.permission.START_ABILIIES_FROM_BACKGROUND`	后台启动 Ability	system_grant
`ohos.permission.ACCESS_BUNDLE_DIR`	访问应用包目录	system_grant
`ohos.permission.ACCESS_CAST_ENGINE_MIRROR`	投屏镜像	system_grant
`ohos.permission.RUNNING_STATE_OBSERVER`	监听运行状态	system_grant
`ohos.permission.ACCESS_DDK_USB`	访问 USB DDK	system_grant
`ohos.permission.ACCESS_LOCAL_BACKUP`	本地备份	system_grant
`ohos.permission.RECEIVE_SMS`	接收短信	user_grant
`ohos.permission.SEND_MESSAGES`	发送短信	user_grant
`ohos.permission.ACCESS_BBOX_DIR`	访问黑匣子目录	system_grant
`ohos.permission.ACCESS_HIVIEWX`	访问 HiView 诊断	system_grant
`ohos.permission.ABILITY_BACKGROUND_COMMUNICATION`	后台通信	system_grant

normal 典型权限（所有应用均可申请）

权限名	用途	grantMode
`ohos.permission.CAMERA`	使用相机	user_grant
`ohos.permission.ACCESS_BLUETOOTH`	蓝牙访问	system_grant
`ohos.permission.DISTRIBUTED_DATASYNC`	分布式数据同步	user_grant
`ohos.permission.APPROXIMATELY_LOCATION`	模糊定位	user_grant
`ohos.permission.ACTIVITY_MOTION`	运动传感器	user_grant
`ohos.permission.ACCELEROMETER`	加速度传感器	system_grant
`ohos.permission.ACCESS_BIOMETRIC`	生物特征识别	system_grant
`ohos.permission.ACCESS_NEARLINK`	星闪通信	system_grant
`ohos.permission.GET_BUNDLE_INFO`	获取包信息	system_grant
`ohos.permission.MICROPHONE`	麦克风	user_grant

知识点 ：system_core 等级的应用可以使用所有三级权限（core + basic + normal）；system_basic 可以使用 basic + normal；normal 只能使用 normal 级别的权限。权限是向下兼容的。

8.5 APL 与 Profile 中的 acls 字段

Profile 中还有一个 acls（Access Control List）字段：

json 复制代码

{
    "acls": {
        "allowed-acls": [
            "ohos.permission.CAPTURE_SCREEN"
        ]
    }
}

acls 的作用 ：允许低 APL 等级的应用使用高等级权限。例如一个 system_basic 级别的应用，通过在 allowed-acls 中声明 ohos.permission.CAPTURE_SCREEN（system_core 级权限），可以跨级使用该权限。

这需要在签发 Profile 时由 CA 审批授权。

8.6 APL 与签名的对应关系总结

复制代码

┌──────────────────────────────────────────────────────────────────┐
│  镜像编译（厂商/系统）                                             │
│  .p12 → sign-profile → apl=system_core → 全部 513+ 权限         │
├──────────────────────────────────────────────────────────────────┤
│  系统应用（厂商预装）                                              │
│  .p12 → sign-profile → apl=system_basic → 332 + 57 = 389 权限   │
├──────────────────────────────────────────────────────────────────┤
│  三方应用（应用市场分发）                                           │
│  开发者 .p12 + AGC Profile → apl=normal → 仅 57 个权限            │
└──────────────────────────────────────────────────────────────────┘

8.7 通过修改 SDK 模板获取高 APL（开发/调试阶段）

在开发阶段，开发者可以通过修改本地 SDK 中的 Profile 模板获取高权限。这不是"绕过"安全机制，而是 OpenHarmony 为调试开发提供的便利。

方法：

修改本地 SDK 中的 Profile 模板文件：

复制代码

OpenHarmony/Sdk/<version>/toolchains/lib/UnsgnedDebugProfileTemplate.json
OpenHarmony/Sdk/<version>/toolchains/lib/UnsgnedReleasedProfileTemplate.json

将以下字段修改：

json 复制代码

{
    "bundle-info": {
        "apl": "system_core",
        "app-feature": "hos_system_app"
    },
    "acls": {
        "allowed-acls": [
            "ohos.permission.CAPTURE_SCREEN",
            "ohos.permission.xxxx"
        ]
    }
}

为什么可行：

这些模板文件是本地未签名 的 JSON（文件名 Unsgned* = Unsigned）
DevEco 的自动签名流程读取模板 → 用本地密钥签名生成 Profile → 嵌入 HAP
设备端 appverify 模块的校验逻辑：
- 如果 Profile 的签名证书来自可信源（系统预置的证书列表），直接通过
- 如果不来自可信源，才进入严格校验（检查 device-id 等）

实际限制：

从源码 provision_verify.cpp 第 377-383 行来看：

cpp 复制代码

if ((info.type == ProvisionType::DEBUG && !g_isRdDevice)
    || info.distributionType == Security::Verify::AppDistType::INTERNALTESTING) {
    //ret = CheckDeviceID(info);  // ← 当前版本已注释！
    checkTimeType = CHECK_TIME;
}

在当前项目的代码中，device-id 校验已被注释掉（仅做时间校验）。这意味着：

调试类型的 Profile 在任何设备上都能安装，不验证 UDID
仅检查签名时间是否在一年内

各场景是否生效：

设备类型	Debug Profile 能否安装	Release Profile 能否安装
RD 设备（研发机）	可以	需要 `os_integration`/`enterprise` 类型
量产设备（正式固件）	取决于是否关闭了调试安装	仅接受可信源签名
开发板（如 RK3588）	通常可以	通常可以（默认开启调试模式）

关键结论 ：在开发板和调试设备上，修改 SDK 模板是获取系统权限的正常开发手段。在量产设备上，是否生效取决于 appverify 模块是否启用了完整的可信源校验。当前项目的 device-id 校验已注释掉，安全性较弱。

九、app-distribution-type 分发类型详解

Profile 中的 app-distribution-type 字段决定了应用的分发类型，直接影响安装策略：

枚举值	数值	说明	能否安装到非调试设备
`none`	0	未指定（Debug Profile 无此字段）	---
`app_gallery`	1	应用市场分发	需要 Ticket 校验
`enterprise`	2	企业应用	可以
`os_integration`	3	系统集成（厂商预装）	可以
`crowdtesting`	4	众测	可以
`enterprise_normal`	5	企业普通应用	可以
`enterprise_mdm`	6	企业 MDM 管理应用	可以
`internaltesting`	7	内部测试	需要 device-id 校验

源码定义（base/security/appverify/.../provision_info.h）：

cpp 复制代码

enum AppDistType {
    NONE_TYPE = 0,
    APP_GALLERY = 1,
    ENTERPRISE = 2,
    OS_INTEGRATION = 3,
    CROWDTESTING = 4,
    ENTERPRISE_NORMAL = 5,
    ENTERPRISE_MDM = 6,
    INTERNALTESTING = 7,
};

安装策略（hap_verify_v2.cpp）：

APP_GALLERY：需要通过 Ticket 校验（应用市场控制）
ENTERPRISE / ENTERPRISE_NORMAL / ENTERPRISE_MDM / OS_INTEGRATION / CROWDTESTING：直接允许安装
NONE_TYPE：拒绝
INTERNALTESTING：允许安装但校验时间和 device-id

实用知识 ：如果你想让自己开发的应用不经应用市场直接安装到设备，将 app-distribution-type 设为 enterprise 或 os_integration 是最简单的方式。

十、编译系统签名流程源码分析

实际编译时 HAP 签名的调用链：

复制代码

ohos_hap (build/ohos/app/app.gni)
    → package_app (build/ohos/app/app_internal.gni)
        → hapbuilder.py (build/scripts/hapbuilder.py)
            → sign_hap()
                → app_sign.py (build/scripts/app_sign.py)
                    → java -jar hap-sign-tool.jar sign-app
                        -mode localsign
                        -signAlg SHA256withECDSA
                        -keyAlias "OpenHarmony Application Release"
                        -inFile <unsigned.hap>
                        -outFile <signed.hap>
                        -profileFile <已签名的.p7b>
                        -keystoreFile OpenHarmony.p12
                        -keystorePwd 123456
                        -keyPwd 123456
                        -appCertFile OpenHarmonyApplication.pem
                        -profileSigned 1
                        -inForm zip

关键参数说明：

-profileSigned 1：Profile 已经是签名后的 .p7b，不需要工具重新签名
-inForm zip：HAP 本质是 ZIP 格式
-mode localsign：本地签名模式（相对于远程签名服务）

十一、设备端验签流程

当 HAP 安装到设备时，appverify 模块（base/security/appverify）执行验证：

复制代码

BundleInstaller 触发安装
    → HapVerifyV2::Verify()
        → 1. 解析 HAP 包中的签名块
        → 2. VerifyAppPkcs7()：验证 HAP 的 PKCS#7 签名
        → 3. 获取签名证书 Subject/Issuer
        → 4. TrustedSourceManager::IsTrustedSource()：检查是否可信源
        → 5. 如果是可信源 → 快速通过
        → 6. 如果非可信源 → VerifyProfile()：完整验证 Profile 签名链
        → 7. ParseAndVerify()：解析 Profile JSON 内容
             → 校验 type (debug/release)
             → 校验 bundle-name
             → 校验 apl
             → 校验 app-feature
             → 校验 device-id（如果是 debug 类型且非 RD 设备）
        → 8. VerifyProfileInfo()：匹配应用证书和 Profile 中的证书
        → 9. 安装成功 → 将 APL 等级写入 AccessTokenManager

安全分析 ：步骤 4 是关键。如果应用签名证书的 Issuer 匹配系统预置的可信源列表，就跳过 Profile 的严格校验。这就是为什么用系统预置 CA 签出的证书签名的应用可以无条件安装。

十二、关键结论

编译镜像时 ：使用源码预置的 OpenHarmony.p12，所有系统应用共用，不需要开发者额外操作
厂商定制时 ：可替换为厂商私有 .p12，同时需要将对应根 CA 预置到系统信任列表
DevEco 调试时 ：IDE 自动处理签名；修改 SDK 模板的 apl 字段可获取系统权限
应用发布时 ：必须使用开发者自己的 .p12 + 从 CA 获取的证书和 Profile
APL 本质：写在 Profile JSON 中的一个字符串字段，安全性完全依赖 Profile 签名链的校验强度
当前项目 ：device-id 校验已注释（provision_verify.cpp:379），调试类型应用可在任意设备安装
./build.sh 不改变 git 分支：签名过程完全在编译产物层面，不影响源码仓库状态