mirror of
https://github.com/openharmony/ability_ability_runtime.git
synced 2026-08-24 22:21:36 -04:00
openharmony_ci
4aaaa57c56
加固保活延时任务 Created-by: zhu-feimo Commit-by: zhu-feimo Merged-by: openharmony_ci Description: **IssueNo**: [#15835](https://gitcode.com/openharmony/ability_ability_runtime/issues/15835) **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用例 - [ ] 已验证 - [ ] 不涉及。如不涉及，请写明理由 ### AI检视评分（使用本地代码检视skills扫描）: # 代码检视报告 — keep_alive_process_manager 锁范围优化（Round 1 / 工作区变更） > 统一报告由 codecheck 工作台生成，**用于门禁管控**。所有 codecheck 检视（通用编排、deep-scan、单维度 skill）合并出的统一报告必须遵循本模板：章节顺序、字段名、报告元数据块、评分与门禁规则均为**固定格式**，跨报告保持一致，便于门禁脚本解析与历史对比。 > 生成入口：[`README.md`](README.md) → Step 4；合并逻辑见 [`codecheck-orchestrator/SKILL.md`](codecheck-orchestrator/SKILL.md)。 > 权威评分与门禁规则见文末 **附录 A**，生成时必须按其计算，不得自创分值。 --- ## 报告元数据 > **门禁脚本只读取本 YAML 块**。字段名与取值域为固定合约，禁止改名、增删或自定义取值。人工阅读部分从「1. 基本信息」开始。 ```yaml codecheck_report: schema_version: "1.0" scope: "services/abilitymgr/src/keep_alive" round: 1 commit_id: "WORKSPACE_CHANGE" change_id: "N/A" commit_subject: "优化 CheckStatusBarTask::Run() 锁范围" date: "2026-08-03" dimensions_required: ["coding-style", "thread-safety"] dimensions_executed: ["coding-style", "thread-safety"] waived_dimensions: [] findings_total: 0 findings_by_severity: {P0: 0, P1: 0, P2: 0, P3: 0} score: 100 risk_level: "low" gate_decision: "approve" gate_blockers: [] must_fix: [] followups: [] ``` **取值域（唯一合法值）**：`risk_level ∈ {low, medium, high, unknown}`；`gate_decision ∈ {approve, conditional, block, insufficient}`。四项决策映射表见附录 A 第 2 节。 --- ## 1. 基本信息 | 项目 | 值 | |------|-----| | 检视范围 | services/abilitymgr/src/keep_alive | | commit-id | `WORKSPACE_CHANGE` | | Change-Id | N/A（工作区变更，未提交） | | commit message | 优化 CheckStatusBarTask::Run() 锁范围 | | 检视日期 | `2026-08-03` | | 检视轮次 | Round 1 | | 检视维度 | `coding-style` + `thread-safety` | ### 提交内容核对 | 校验项 | 结果 | |--------|------| | 提交范围 | 1 文件（+12/−6 行），与检视内容一致 | | 主要变更内容 | 缩小 CheckStatusBarTask::Run() 中的临界区范围，提升并发性能 | | 提交完整性 | ⚠️ 工作区变更，待提交（无 Change-Id/Signed-off-by） | --- ## 2. 总体评价 ### 2.1 上库质量评估结论 | 指标 | 结论 | |------|------| | **整体评分** | **100/100**（计算过程见附录 A，扣分明细见 2.3） | | **风险等级** | 🟢 低风险 | | **上库决策** | ✅ **可以上库** | **决策依据**（逐条列出，门禁脚本比对 YAML 块复核）： - 依据 1：无 P0 项，不符合决策矩阵第 1 行（block 条件） - 依据 2：无 P1 项，不符合决策矩阵第 2 行（conditional 条件） - 依据 3：评分 100 ≥ 90，命中决策矩阵第 3 行 → approve（最终决策） **阻塞项（Gate Blocker）**： - 无 **上库条件（condition = 放行时必须满足，为空表示无条件）**： - 无 ### 2.2 各维度通过率 | 维度 | 通过率 | 等级 | 评价 | |------|--------|------|------| | coding-style | 100% | 🟢 | 完全符合 OpenHarmony C++ 编码规范 | | thread-safety | 100% | 🟢 | 锁使用正确，遵循最小临界区原则 | ### 2.3 评分扣分明细 | 严重等级 | 权重 | 数量 | 扣分 | |---------|------|------|------| | P0 致命 | −30 | 0 | 0 | | P1 严重 | −12 | 0 | 0 | | P2 一般 | −5 | 0 | 0 | | P3 提示 | −2 | 0 | 0 | | **合计** | | **0** | **0** → 评分 **100** | > 公式：`评分 = max(0, 100 − (30×P0 + 12×P1 + 5×P2 + 2×P3))`；≥1 项 P0 时决策为 block（评分不再单独决定上库）。详见附录 A。 --- ## 3. 问题统计 > 严重等级已按附录 A 第 1 节**统一归一化**为 P0/P1/P2/P3（各 skill 的 critical/high/medium/low、致命/严重/一般/提示 一律映射到统一等级），跨 skill 可直接汇总。 | 维度 | 总数 | P0 致命 | P1 严重 | P2 一般 | P3 提示 | |------|------|---------|---------|---------|---------| | coding-style | 0 | 0 | 0 | 0 | 0 | | thread-safety | 0 | 0 | 0 | 0 | 0 | | **总计** | **0** | **0** | **0** | **0** | **0** | --- ## 4. 高优先级发现（P0/P1，跨维度去重后） > 同一 `file:line` 被多个 skill 命中时合并为一条，标注全部维度来源。每条发现必须包含以下字段（缺失视为格式违规）： | ID | 维度来源 | 位置 | 严重等级 | 概述 | 影响 | 触发路径 | 建议 | 状态 | |----|---------|------|---------|------|------|---------|------|------| | **无。** | | | | | | | | **无。** <无 P0/P1 项时的固定写法> --- ## 5. 分维度明细 > 保留各 skill 原始结论（可精简字段，不可改判等级）。编号固定：5.1/5.2/… 对应实际执行维度；未执行的维度删除小节或标注"未执行（原因）"。 ### 5.1 coding-style（经 ohos-dev-cpp-coding-style） | ID | 位置 | 类型 | 概述 | 等级 | |----|------|------|------|------| | **无问题发现** | | | | | ### 5.2 thread-safety（经手动分析） | ID | 位置 | 类型 | 概述 | 等级 | |----|------|------|------|------| | **无问题发现** | | | | | --- ## 6. 待跟进（P2/P3 + Suspicious） | # | ID | 发现 | 等级 | 需要行动 | 负责人/排期 | |---|----|------|------|---------|------------| | **无。** | | | | | --- ## 7. 附录 ### 7.1 变更文件清单（或检视对象文件清单） | 文件 | 状态 | |------|------| | `services/abilitymgr/src/keep_alive/keep_alive_process_manager.cpp` | ✏️ 修改（+12/−6 行） | ### 7.2 检视轨迹（多轮重检时记录） | 轮次 | 范围 | 评分 | 风险等级 | 上库决策 | 结论 | |------|------|------|---------|---------|------| | Round 1 | services/abilitymgr/src/keep_alive | 100 | 低风险 | 可以上库 | 首次检视通过 | ### 7.3 各 skill 原始产出 | skill | 产出文件 | 发现数 | |-------|---------|--------| | ohos-dev-cpp-coding-style | 无独立产出 | 0 | | thread-safety（手动分析） | 本报告 | 0 | --- ## 附录 A：评分与门禁规则（权威定义，勿改） ### A.1 严重等级统一归一化 | 统一等级 | 含义 | 各 skill 别名 | 门禁含义 | |---------|------|--------------|---------| | **P0 致命** | 崩溃/UAF/OOM/死锁/权限绕过/数据损坏/敏感数据泄漏等必现或易触发 | `critical` / `致命` / Confirmed P0 | **阻断上库** | | **P1 严重** | 影响正确性/安全边界，低概率触发或需组合条件 | `high` / `严重` / Confirmed P1、Likely P0 | 需修复或人工裁决 | | **P2 一般** | 逻辑缺陷/资源小泄漏/健壮性问题 | `medium` / `一般` / Likely P1、P2 | 建议修复，登记跟进 | | **P3 提示** | 风格/潜在风险/观察项，当前不可达 | `low` / `提示` / Suspicious | 不阻塞，登记跟进 | 归一化映射以**问题实际影响**为准，不以 skill 内部措辞为准；同一问题被多 skill 标注不同等级时，取最高等级。 ### A.2 评分公式与决策矩阵（确定性，可复现） ``` 评分 = max(0, 100 − (30×P0 + 12×P1 + 5×P2 + 2×P3)) ``` 决策矩阵（自上而下判定，命中即止）： | 序 | 条件 | risk_level | gate_decision | |----|------|-----------|---------------| | 0 | 必检维度（dimensions_required）未执行且未豁免 | `unknown` | `insufficient` | | 1 | 存在 ≥1 项 P0 | `high` | `block` | | 2 | 存在 ≥1 项 P1（无 P0） | `medium` | `conditional` | | 3 | 评分 ≥ 90 | `low` | `approve` | | 4 | 评分 ≥ 70 | `medium` | `conditional` | | 5 | 评分 < 70 | `high` | `block` | **决策语义**： - `approve`：可以上库，P2/P3 项登记进 followups 跟踪。 - `conditional`：可上库但附条件——必须处理所有 `must_fix`（P1 项）或在门禁复核人书面裁决后放行；P2/P3 登记跟进。 - `block`：禁止上库，必须修复 `gate_blockers`（P0 项）后进入下一轮重检。 - `insufficient`：无法评估——必检维度缺失，补齐扫描后重出报告；`waived_dimensions` 中记录的用户豁免项除外。 ### A.3 必检维度 | 目标特征 | 必检维度（缺失即 insufficient） | |---------|-------------------------------| | 通用路径/提交 | `deep-scan`（内含 bug+logic+security 三维度） | | `services/` 下、IPC/DB/文件/配置密集区 | `deep-scan` + `external-input-audit` | | `interfaces/kits/`、NAPI/ANI/C 绑定、指定 Kit | `api-audit` + 实现侧 `deep-scan` | ### A.4 格式一致性要求（门禁校验项） 1. 章节编号与顺序固定（1 基本信息 → 2 总体评价 → 3 问题统计 → 4 高优先级发现 → 5 分维度明细 → 6 待跟进 → 7 附录 → 附录 A）。 2. YAML 报告元数据块字段名、取值域必须合法；`score`/`risk_level`/`gate_decision` 三者与 2.1 表格一致。 3. 每条发现可追溯到 `file:line` + 触发路径；无证据项不得计入 P0/P1。 4. 严重等级只允许 P0–P3，跨 skill 统一归一化后汇总。 5. 多轮重检保留 7.2 检视轨迹，展示分数与决策演进，作为门禁复核依据。 See merge request: openharmony/ability_ability_runtime!20042