mirror of
https://github.com/openharmony/ability_ability_runtime.git
synced 2026-08-24 12:43:16 -04:00
openharmony_ci
6d137cfc21
native application整改 Created-by: liuzongze Commit-by: liuzongze@h-partners.com Merged-by: openharmony_ci Description: **IssueNo**: https://gitcode.com/openharmony/ability_ability_runtime/issues/15589 **Description**: **稳定性自检：** | 自检项 | 自检结果 | | ------------------------------------------------------------ | -------- | | 涉及跨进程调用的相关操作需要抛至主线程或加锁防止并发 | 不涉及 | | 成员变量进行赋值或创建需要排查并发 | 不涉及 | | 谨慎在lambda表达式中使用引用捕获 | 不涉及 | | 谨慎在未经拷贝的情况下使用外部传入的string、C字符串 | 不涉及 | | map\vector\list\set等stl模板类使用时需要排查并发 | 不涉及 | | 谨慎考虑加锁范围 | 不涉及 | | 在IPC通信中谨慎使用同步通信方式 | 不涉及 | | 禁止传递this指针至其他模块或线程（特别是eventhandler任务） | 不涉及 | | 禁止将外部传入的裸指针在内部直接构造智能指针 | 不涉及 | | 禁止多个独立创建的智能指针管理同一地址 | 不涉及 | | 禁止在析构函数中抛异步任务 | 不涉及 | | 禁止js对象在非js线程（例如在IPC线程）创建、使用或销毁 | 不涉及 | | 禁止在对外接口中未经判空直接使用外部传入的指针 | 不涉及 | | 禁止接口返回局部变量引用 | 不涉及 | | 禁止在信号函数中加锁 | 不涉及 | | 禁止在关键流程（SA启动、应用启动等主流程）执行耗时的操作 | 不涉及 | | 禁止将同一个cpp编译在不同的so中 | 不涉及 | **安全编码自检：** | 自检项 | 自检结果 | | -------------------------------------------------------------- | -------- | | 裸指针避免通过隐式转换构造为sptr | 不涉及 | | json对象在取值之前必须先判断类型，避免类型不匹配 | 不涉及 | | 序列化时必须对传入的数组大小进行校验，避免出现超大数组 | 不涉及 | | 避免使用未明确位宽的整型，选择使用int8_t、uint8_t等类型 | 不涉及 | | 外部传入的路径要做规范化校验，对路径中的.、..、../等特殊字符严格校验 | 不涉及 | | 指针变量、表示资源描述符的变量、bool变量必须赋初值 | 不涉及 | | readParcelable获取的对象使用前需要判空 | 不涉及 | | 分配和释放内存的函数需要成对出现 | 不涉及 | | 申请内存后异常退出前需要及时进行内存释放 | 不涉及 | | 内存申请前必须对内存大小进行合法性校验 | 不涉及 | | 内存分配后必须判断是否成功 | 不涉及 | | 禁止使用realloc、alloca函数 | 不涉及 | | 禁止打印文件路径、口令等敏感信息，如有需要，使用private修饰 | 不涉及 | | 禁止打印内存地址 | 不涉及 | | 整数之间运算时必须严格检查，确保不会出现溢出、反转、除0 | 不涉及 | | 禁止对有符号整数进行位操作符运算 | 不涉及 | | 禁止对指针进行逻辑或位运算 | 不涉及 | | 循环次数如果收外部数据控制，需要检验其合法性 | 不涉及 | | 禁止使用内存操作类危险函数，需要使用安全函数 | 不涉及 | | 谨慎使用不可重入函数 | 不涉及 | | 必须检查安全函数的返回值，并进行正确处理 | 不涉及 | | 禁止仅通过TokenType类型判断绕过权限校验 | 不涉及 | **TDD Result**:  **XTS Result**: ### 是否已执行L0用例 - [x] 已验证 - [ ] 不涉及。如不涉及，请写明理由 AI检视评分（使用本地代码检视skills扫描）: # 代码检视报告 — frameworks/native/appkit/app/main_thread.cpp + libappkit_native.map（native application 整改 v2）（Round 2 / 提交 150d3a2） > 统一报告由 codecheck 工作台生成，**用于门禁管控**。所有 codecheck 报告（含 orchestrator 合并出的统一报告、单 scanner 直接产出的统一报告）必须遵循本模板：章节顺序、字段名、报告元数据块、评分与门禁规则均为**固定格式**，跨报告保持一致，便于门禁脚本解析与历史对比。 > 生成入口：[`README.md`](../README.md) → Step 5；合并逻辑见 [`orchestrator/SKILL.md`](../orchestrator/SKILL.md)。 > 权威评分与门禁规则为**通用规则**，不在输出报告中呈现；生成时必须按 [`conventions.md`](../conventions.md) §7（等级归一化）/ §8（必检维度）/ §9（评分与决策矩阵）计算，不得自创分值。 --- ## 报告元数据 > **门禁脚本只读取本 YAML 块**。字段名与取值域为固定合约，禁止改名、增删或自定义取值。人工阅读部分从「1. 门禁结论」开始。 <!-- codecheck-report-metadata:start --> ```yaml codecheck_report: schema_version: "1.0" scope: "frameworks/native/appkit/app/main_thread.cpp + libappkit_native.map (native application 整改 v2)" round: 2 commit_id: "150d3a2d5eb361edb77a291be18e87afe0d94340" change_id: "I76600f388d4aba4877b154a2039f6a849a58732c" report_id: "I76600f388d4aba4877b154a2039f6a849a58732c-R2" date: "2026-08-07" gate_decision: "approve" risk_level: "low" score: 90 dimensions_required: ["security-scanner", "logic-scanner", "input-scanner"] dimensions_executed: ["security-scanner", "logic-scanner", "input-scanner", "test-coverage", "coding-style"] findings_total: 2 findings_by_severity: {P0: 0, P1: 0, P2: 2, P3: 0} gate_blockers: [] must_fix: [] followups: ["F-04", "F-05"] ``` <!-- codecheck-report-metadata:end --> --- ## 1. 门禁结论 | 项目 | 结论 | |---|---| | 决策 | **approve** | | 风险等级 | 🟢 low | | 评分 | **90/100** | | 阻塞项 | 无 | | 必须修复（P0/P1） | 0 项 | | 建议跟进（P2/P3） | 2 项 | **一句话结论**：orchestrator 探测 `frameworks/native/appkit` 通用路径 + IPC/外部输入信号，调度 security+logic+input 三 scanner；Refute 推翻 3 项（F-01/F-03/F-06 经评审确认无风险，见 [`refute_log`](refute_log_main_thread_820578b.md)），剩余 F-04/F-05 两项 P2 登记 followups；评分 `100−(5×2)=90 ≥90` 命中决策矩阵第 3 行 → approve 可上库。 --- ## 2. 扣分原因（仅 gate_decision=block 时呈现；approve/conditional/insufficient 时本节省略） > 本轮 gate_decision=approve，本节省略。扣分明细：共扣 10 分，由 2 个 P2（F-04/F-05）组成；F-01/F-03/F-06 经 Refute 推翻不计扣分。详见第 4 节与 refute_log。 --- ## 3. 必须立即处理（P0/P1） **无。** > F-01（原 P1，白名单→声明式迁移等价性回归风险）经 Refute 第一层触发路径证伪推翻（评审确认 5 个系统应用 metadata 声明已就绪，回归路径不可达），不进入正文；详见 [`refute_log`](refute_log_main_thread_820578b.md)。 --- ## 4. 建议本轮或下一补档处理（P2/P3） | ID | 优先级 | 问题 | 建议行动 | 排期 | |---|---|---|---|---| | F-04 | P2 | 测试用 raw pointer `new MainThread()` 且不 delete（注释称析构会 heap corruption），测试基础设施有 UB/泄漏隐患 | 后续 PR 评估 MainThread 析构崩溃根因（可能 mock 不全导致依赖未释放），改用 fixture 正确管理生命周期或补全 mock | 留空 | | F-05 | P2 | `HandleLaunchApplication` 调用点（`IsNeedLoadLibrary(...) || IsFormRenderService(...)` 短路组合、entryHapModuleInfo.metadata 来源、isSystemApp 传递）无集成测试 | 后续补集成测试：构造 AppLaunchData + mock BundleInfo，验证调用点 `||` 组合与短路语义 | 留空 | --- ## 5. 分维度速览 | 维度 | 结果 | 关键说明 | |---|---|---| | security-scanner | 🟢 通过 | `std::any_of` 遍历 vector 安全（空 vector 返回 false）；entryHapModuleInfo 默认构造 metadata 空→IsNeedLoadLibrary 返回 false；map 导出仅符号表无运行时影响。F-03/F-06 经 Refute 推翻 | | logic-scanner | 🟢 通过 | 调用点 `||` 短路语义正确；isSystemApp 来自 `bundleInfo.applicationInfo.isSystemApp`（系统判定可信）。F-01 经 Refute 推翻（评审确认等价性无风险） | | input-scanner | 🟢 通过 | metadata 为应用可控外部输入（module.json 声明），但加载决策经 `isSystemApp` 双因子收敛，无注入/绕过；IsNeedLoadLibrary 仅返回 bool，不写 DB/文件/缓存，无持久化风险 | | test-coverage | 🟡 关注 | IsNeedLoadLibrary/IsFormRenderService 全分支覆盖（10 个单测，Round 1 的 F-02 已解决）；调用点集成测试缺失（F-05 P2） | | coding-style | 🟡 关注 | 测试 raw pointer+不 delete 隐患（F-04 P2）；无 PAC/红线/reinterpret_cast 致命项 | --- ## 6. 关键发现详情 > P0/P1 必出全量卡片；P2/P3 按需精选或全出。被 Refute 推翻的 F-01/F-03/F-06 不在此呈现，详见 [`refute_log`](refute_log_main_thread_820578b.md)。 ### [F-04] 测试 raw pointer + 不 delete 析构崩溃隐患（P2, scanner=security-scanner） - **位置**：`test/unittest/appkit/main_thread_frist_test/main_thread_frist_test.cpp:50,56` - **触发路径**：`SetUpTestCase` 执行 `sharedThread_ = new (std::nothrow) MainThread()`；`TearDownTestCase` 注释「Do NOT delete sharedThread_ - heap corruption occurs during MainThread destruction」不释放 - **影响**：raw pointer 不释放导致资源泄漏/UB；注释表明 MainThread 析构存在 heap corruption，反映测试 mock 不全或析构依赖未正确释放，后续若误删将触发崩溃 - **证据**：测试代码 line 50 `new (std::nothrow) MainThread()`，line 54-57 `TearDownTestCase` 注释明确不 delete - **建议**：后续 PR 评估 MainThread 析构崩溃根因（mock 不全致依赖未释放），改用 fixture 正确管理生命周期或补全 mock ### [F-05] HandleLaunchApplication 调用点无集成测试（P2, scanner=logic-scanner） - **位置**：`frameworks/native/appkit/app/main_thread.cpp:1749` - **触发路径**：`IsNeedLoadLibrary(entryHapModuleInfo.metadata, isSystemApp) || IsFormRenderService(bundleName)` 的 `||` 短路组合；entryHapModuleInfo.metadata 来源（`bundleInfo.hapModuleInfos` 取 ENTRY 类型，`main_thread.cpp:1710-1732`）；isSystemApp 传递（`bundleInfo.applicationInfo.isSystemApp`，`main_thread.cpp:1698`） - **影响**：被调两函数（IsNeedLoadLibrary/IsFormRenderService）已单测全覆盖，但调用点本身的组合与短路语义、metadata/isSystemApp 来源链无集成测试，重构无端到端回归保护 - **证据**：测试文件 10 个用例均直接测 `IsNeedLoadLibrary`/`IsFormRenderService` 自由函数（`main_thread_frist_test.cpp:568-695`），无 `HandleLaunchApplication` 集成用例 - **建议**：后续补集成测试：构造 AppLaunchData + mock BundleInfo，验证调用点 `||` 组合与短路语义 See merge request: openharmony/ability_ability_runtime!19870
