Lliuzongze@h-partners.com前台组件 并发问题修复
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
!20346 merge isAppRunning into master isAppRunning接口支持file system service Created-by: AsukaSoryu Commit-by: AsukaSoryu Merged-by: openharmony_ci Description: isAppRunning接口支持file system service https://gitcode.com/openharmony/ability_ability_runtime/issues/16104 # 代码检视报告 — latest_commit（Round 2 / 最新提交） > 统一报告由 codecheck 工作台生成，**用于门禁管控**。章节顺序、字段名、报告元数据块、评分与门禁规则均为固定格式。 > 生成入口：[ skills/codecheck/README.md](skills/codecheck/README.md) → Step 5；合并逻辑见 [skills/codecheck/orchestrator/SKILL.md](skills/codecheck/orchestrator/SKILL.md)。 > 权威评分与门禁规则见文末 **附录 A**。 --- ## 报告元数据 yaml codecheck_report: schema_version: "1.0" scope: "latest_commit" round: 2 commit_id: "70be5b97ca98493f160c5e320333b88c3dfbae6b" change_id: "N/A" commit_subject: "add support for file system SA" date: "2026-08-31" dimensions_required: ["security-scanner", "logic-scanner", "input-scanner"] dimensions_executed: ["security-scanner", "logic-scanner", "input-scanner"] waived_dimensions: [] findings_total: 4 findings_by_severity: {P0: 0, P1: 0, P2: 0, P3: 4} score: 92 risk_level: "low" gate_decision: "approve" gate_blockers: [] must_fix: [] followups: ["SEC-01", "LOG-01", "SEC-02", "LOG-03"] > **Round 2 重判说明**：作者确认本变为"信任此文件系统 SA"的意图性授权；据代码证据对 Round 1 初判做合理重判（详见 §7.2 检视轨迹与 [refute_log_latest_commit_20260831.md](refute_log_latest_commit_20260831.md)）。 --- ## 1. 基本信息 | 项目 | 值 | |------|-----| | 检视范围 | 最新提交 add support for file system SA | | commit-id | 70be5b97ca98493f160c5e320333b88c3dfbae6b | | Change-Id | N/A（提交仅含 Signed-off-by，无 Change-Id） | | commit message | add support for file system SA | | 检视日期 | 2026-08-31 | | 检视轮次 | Round 2（Round 1 评分 84/conditional → 重判后 92/approve） | | 检视维度 | security-scanner + logic-scanner + input-scanner | ### 提交内容核对 | 校验项 | 结果 | |--------|------| | 提交范围 | 2 文件（+10/−2），与检视内容一致 | | 主要变更内容 | 为文件系统 SA 放开 IsAppRunning(4参) 的调用方 UID 白名单（新增 FILE_SYSTEM_SERVICE_UID=7100）；并向 app_manager 公共 config 补 BGTASKMGR_CONTINUOUS_TASK_ENABLE 宏 | | 提交完整性 | ⚠️ 无 Change-Id（影响 Gerrit 追溯）；同提交混入与主题耦合度低的 BGTASKMGR 构建修复（该构建修复本身合理） | **路径特征探测**： - IPC 信号：改动点 app_mgr_service_inner.cpp 属 SA 501 服务侧，IPC 入口为 app_mgr_stub.cpp 的 HandleIsAppRunningByUserId（经 IPCSkeleton::GetCallingUid() 取调用方 UID）。 - 持久化信号：改动函数为只读查询（appRunningManager_->IsAppRunningByBundleName），无 DB/文件写入。 - 决策依据：services/ + IPC 信号 → 选定 security-scanner + logic-scanner + input-scanner（input-scanner 因改动路径无持久化 sink，0 新增发现）。 --- ## 2. 总体评价 ### 2.1 上库质量评估结论 | 指标 | 结论 | |------|------| | **整体评分** | **92/100**（计算过程见附录 A，扣分明细见 2.3） | | **风险等级** | 🟢 低风险 | | **上库决策** | ✅ **可以上库** | **决策依据**： - 依据 1：无 P0、无 P1、无 P2；P3×4 → 评分 = 100 − (2×4) = 92，命中附录 A 决策矩阵第 3 行（≥90）→ approve。 - 依据 2：必检维度 security/logic/input 均已执行 → 非 insufficient。 - 依据 3：核心变更为意图性授权扩展（信任文件系统 SA），diff 性质为单条件 OR 扩展（!= X → != X && != Y），未新增控制流分支，下游路径逐字节不变、已被既有用例覆盖；第二道门 VerifyRunningInfoPerm 保留，纵深防御未削弱。 **阻塞项（Gate Blocker）**：无。 **上库条件**：无（approve）。P3 项登记跟进。 ### 2.2 各维度通过率 | 维度 | 通过率 | 等级 | 评价 | |------|--------|------|------| | Security & Bug（security-scanner） | 2/2 均为 P3 观察项 | 🟢 | 授权扩展镜像既有 5523 机制 + 第二道门保留；硬编码 UID 属既有约定 | | Logic（logic-scanner） | 3/3（2 项 P3 + 1 项推翻） | 🟢 | 无新控制流分支、下游已覆盖 → 测试边际价值低；兄弟变体不更新经 IPC 派发证据确认正确 | | Input（input-scanner） | — | 🟢 | 改动路径无持久化 sink，0 新增外部输入→持久化链路 | ### 2.3 评分扣分明细 | 严重等级 | 权重 | 数量 | 扣分 | |---------|------|------|------| | P0 致命 | −30 | 0 | 0 | | P1 严重 | −12 | 0 | 0 | | P2 一般 | −5 | 0 | 0 | | P3 提示 | −2 | 4 | −8 | | **合计** | | **4** | **−8** → 评分 **92** | > 公式：评分 = max(0, 100 − (30×P0 + 12×P1 + 5×P2 + 2×P3))；本提交无 P0/P1/P2，评分 92 ≥ 90 → approve。 --- ## 3. 问题统计 | 维度 | 总数 | P0 致命 | P1 严重 | P2 一般 | P3 提示 | |------|------|---------|---------|---------|---------| | security-scanner | 2 | 0 | 0 | 0 | 2 | | logic-scanner | 2 | 0 | 0 | 0 | 2 | | input-scanner | 0 | 0 | 0 | 0 | 0 | | **总计** | **4** | **0** | **0** | **0** | **4** | > Round 1 的 LOG-02 经 Round 2 推翻移除（见 §7.4）。 --- ## 4. 高优先级发现（P0/P1，跨维度去重后） **无。** 本提交无 P0/P1/P2 项。 --- ## 5. 分维度明细 ### 5.1 Security & Bug（经 security-scanner） | ID | 位置 | 类型 | 概述 | 等级 | |----|------|------|------|------| | SEC-01 | services/appmgr/src/app_mgr_service_inner.cpp:9827 | 权限/鉴权(AUTH-003/007) | IsAppRunning(4参) UID 白名单由 {5523} 扩为 {5523,7100}；意图性授权，镜像 5523 机制，第二道门 VerifyRunningInfoPerm 保留 | P3 | | SEC-02 | services/appmgr/src/app_mgr_service_inner.cpp:341 | 权限/鉴权(AUTH-007) | FILE_SYSTEM_SERVICE_UID=7100 硬编码 UID 白名单，与既有 FOUNDATION_UID 同属既有约定 | P3 | **SEC-01 详述** - 触发路径：IPC app_mgr_stub.cpp:1867 HandleIsAppRunningByUserId → IsAppRunning(4参):9823 → UID 校验 :9827 对 callingUid==7100 放行 → CheckGetRunningInfoPermission():9831 → appRunningManager_->IsAppRunningByBundleName。 - Round 2 重判理由：① 作者确认意图性授权；② 镜像既有 FOUNDATION_UID=5523 同款系统 UID 约定，既已接受 5523 则 7100 同质；③ 第二道门 VerifyRunningInfoPerm（:6885）保留。 - 跟进建议：架构演进——系统 UID 白名单收敛到 PermissionVerification 单例（AGENTS.md 约束）。 ### 5.2 Logic（经 logic-scanner） | ID | 位置 | 类型 | 概述 | 等级 | |----|------|------|------|------| | LOG-01 | test/unittest/app_mgr_service_inner_test/* | 测试完备性 | diff 为单条件 OR 扩展，未新增控制流分支，下游已覆盖，专属用例边际价值低 | P3 | | LOG-03 | interfaces/inner_api/app_manager/BUILD.gn + 提交元数据 | 提交规范 | 同提交混入 BGTASKMGR 公共 config 修复（合理）但耦合度低；提交无 Change-Id | P3 | **LOG-01 详述** - Round 2 重判理由：diff 为 if (callingUid != FOUNDATION_UID) → if (callingUid != FOUNDATION_UID && callingUid != FILE_SYSTEM_SERVICE_UID)，单条件 OR 扩展，**无新控制流分支**；下游 CheckGetRunningInfoPermission()→IsAppRunningByBundleName 逐字节不变，已被既有 5523 放行用例覆盖；对 7100 补专属用例仅断言常量字面量，边际价值低。 - 跟进：若该条件后续演化出差异化下游行为，再补用例。 **LOG-03 详述** - BUILD.gn 向 appmgr_sdk_config/appmgr_core_config 补 BGTASKMGR_CONTINUOUS_TASK_ENABLE 是合理构建修复（公共头 app_mgr_interface.h:681 等含 #ifdef，此前公共 config 缺该宏致消费者头文件 #ifdef 段与 lib 实现声明不一致）。非缺陷。 - 跟进：与 commit 主题耦合度低，建议拆分或补关联说明；补 Change-Id。 ### 5.3 Input（经 input-scanner） 无发现。改动函数为只读查询，无 DB/文件/缓存写入 sink；bundleName 的 %{public}s 调试日志（:9825）为既有代码、本次未改动，不计入本次提交新引入链路。 --- ## 6. 待跟进（P2/P3 + Suspicious） | # | ID | 发现 | 等级 | 需要行动 | 负责人/排期 | |---|----|------|------|---------|------------| | 1 | SEC-01 | UID 白名单扩至 7100 | P3 | 架构演进：系统 UID 白名单收敛到 PermissionVerification 单例 | 后续 | | 2 | LOG-01 | 专属单测边际价值低 | P3 | 若该条件演化出差异化下游行为再补用例 | 按需 | | 3 | SEC-02 | 硬编码 UID 白名单（AUTH-007） | P3 | UID 白名单走配置化 | 后续 | | 4 | LOG-03 | 提交耦合 + 无 Change-Id | P3 | 拆分无关构建修复或补关联说明；补 Change-Id | 作者 | --- ## 7. 附录 ### 7.1 变更文件清单 | 文件 | 状态 | |------|------| | interfaces/inner_api/app_manager/BUILD.gn | ✏️ 修改（+6，向 appmgr_sdk_config/appmgr_core_config 补 BGTASKMGR_CONTINUOUS_TASK_ENABLE） | | services/appmgr/src/app_mgr_service_inner.cpp | ✏️ 修改（+6/−2，新增 FILE_SYSTEM_SERVICE_UID=7100 并扩 IsAppRunning(4参) UID 白名单） | ### 7.2 检视轨迹 | 轮次 | 范围 | 评分 | 风险等级 | 上库决策 | 结论 | |------|------|------|---------|---------|------| | Round 1 | latest_commit (70be5b97) | 84 | 🟡 中风险 | ⚠️ conditional | 初判 5 项（P2×2+P3×3），SEC-01/LOG-01 偏保守 | | Round 2 | latest_commit (70be5b97) | 92 | 🟢 低风险 | ✅ approve | 据作者意图+代码证据重判：SEC-01 P2→P3、LOG-01 P2→P3、LOG-02 推翻；无 P0/P1/P2 | ### 7.3 各 skill 原始产出 | skill | 产出文件 | 发现数 | |-------|---------|--------| | security-scanner | （内联于本报告 §5.1，无独立文件） | 2 | | logic-scanner | （内联于本报告 §5.2，无独立文件） | 2（+1 推翻） | | input-scanner | （改动路径无持久化 sink，0 发现） | 0 | | refute | [refute_log_latest_commit_20260831.md](refute_log_latest_commit_20260831.md) | 5 条审查（Round 2） | ### 7.4 已排除发现（refute 推翻项） | ID | 原始位置 | 原始等级 | 推翻理由 | |----|---------|---------|---------| | LOG-02 | services/appmgr/src/app_mgr_service_inner.cpp:9850 | P3（Round 1） | IPC 派发证据：文件系统 SA 经 app_mgr_stub.cpp:1867 HandleIsAppRunningByUserId 调 4 参变体；:9850 经 app_mgr_stub.cpp:1850 HandleIsAppRunningByBundleNameAndUserId 派发，是不同 IPC code。SA 不调用 IsAppRunningByBundleNameAndUserId，故不更新 :9850 是正确分离，非不一致缺陷。 | --- ## 附录 A：评分与门禁规则（权威定义，勿改） ### A.1 严重等级统一归一化 | 统一等级 | 含义 | 各 skill 别名 | 门禁含义 | |---------|------|--------------|---------| | **P0 致命** | 崩溃/UAF/OOM/死锁/权限绕过/数据损坏/敏感数据泄漏等必现或易触发 | critical/致命/Confirmed P0 | **阻断上库** | | **P1 严重** | 影响正确性/安全边界，低概率触发或需组合条件 | high/严重/Confirmed P1、Likely P0 | 需修复或人工裁决 | | **P2 一般** | 逻辑缺陷/资源小泄漏/健壮性问题 | medium/一般/Likely P1、P2 | 建议修复，登记跟进 | | **P3 提示** | 风格/潜在风险/观察项，当前不可达 | low/提示/Suspicious | 不阻塞，登记跟进 | ### A.2 评分公式与决策矩阵（确定性，可复现） 评分 = max(0, 100 − (30×P0 + 12×P1 + 5×P2 + 2×P3)) | 序 | 条件 | risk_level | gate_decision | |----|------|-----------|---------------| | 0 | 必检维度未执行且未豁免 | 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 | 本提交（Round 2）：P0=0, P1=0, P2=0, P3=4 → 评分 92 → 第 3 行 → low/approve。 ### A.3 必检维度 | 目标特征 | 必检维度 | |---------|---------| | 通用路径/提交 | security-scanner + logic-scanner | | services/ 下、IPC/DB/文件/配置密集区 | security-scanner + logic-scanner + input-scanner | | interfaces/kits/、NAPI/ANI/C 绑定、指定 Kit | api-scanner + security-scanner + logic-scanner | 本提交命中第 2 行（services/ + IPC），三维度均已执行 → 非 insufficient。 ### A.4 格式一致性要求 1. 章节顺序固定；2. YAML 字段合法且三值一致；3. 每条发现可追溯 file:line + 触发路径；4. 等级仅 P0–P3；5. 多轮重检保留轨迹。 See merge request: openharmony/ability_ability_runtime!20346 | 4 天前 | |
!20223 merge fct into master 前台组件 并发问题修复 Created-by: liuzongze Commit-by: liuzongze@h-partners.com Merged-by: openharmony_ci Description: **IssueNo**: https://gitcode.com/openharmony/ability_ability_runtime/issues/15991 **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扫描）: # 代码检视报告 — commit 2ccdb51f + 全部修复（前台组件 并发问题修复）（Round 3） > 本 Round 反映 commit 2ccdb51f + 本会话全部代码修复（CC-02/03/04/05/10 五项消除）+ 门禁复核人对剩余 P1/P2（CC-01/06/07）评估无风险书面裁决放行后的最终门禁状态。 > 生成入口： skills/codecheck/README.md → Step 5。 --- ## 报告元数据 <!-- codecheck-report-metadata:start --> yaml codecheck_report: schema_version: "1.0" scope: "commit 2ccdb51f + 全部修复 (CC-02/03/04/05/10) + 裁决放行 (CC-01/06/07)" round: 3 commit_id: "2ccdb51f18dd3f94b09e80a0cdb520ccff7bd6b1" change_id: "Id86fc9a3d51195932a82d84b9fbe2a75c80faf2a" report_id: "Id86fc9a3d51195932a82d84b9fbe2a75c80faf2a-R3" date: "2026-08-15" gate_decision: "approve" risk_level: "low" score: 96 dimensions_required: ["security-scanner", "logic-scanner", "input-scanner", "api-scanner"] dimensions_executed: ["security-scanner", "logic-scanner", "input-scanner", "api-scanner"] findings_total: 2 findings_by_severity: {P0: 0, P1: 0, P2: 0, P3: 2} gate_blockers: [] must_fix: [] followups: ["CC-08", "CC-09"] <!-- codecheck-report-metadata:end --> --- ## 1. 门禁结论 | 项目 | 结论 | |---|---| | 决策 | **approve**（5 项代码修复消除 + 3 项 P1/P2 评估无风险裁决放行 → **门禁放行，可上库**）| | 风险等级 | 🟢 low | | 评分 | **96/100**（R1=52 → R2=64 → R3=96） | | 阻塞项 | 无（0 项 P0/P1） | | 必须修复（P0/P1） | 0 项 | | 建议跟进（P3） | 2 项 | **一句话结论**：本会话修复消除 5 项（CC-02/03/04/05/10），剩余 P1/P2（CC-01/06/07）经门禁复核人评估无风险书面裁决放行（视为已处置，不计评分）——无 P0/P1 阻塞，**门禁 approve，可上库**。仅余 2 项 P3 观察项（CC-08/CC-09，当前不可触发/可接受）登记 followups。 ### 门禁放行裁决记录（评估无风险，不计评分阻塞） | ID | 原等级 | 裁决结论 | 裁决依据 | |---|---|---|---| | CC-01 | P1 | 评估无风险，裁决放行 | pre-existing UAF；实际触发需 ApplicationContext 回调跨线程 + 主线程 SetRuntime/UpdateETSRuntime 精确并发时序，实际调用场景下风险可接受；根因修复（runtime_ 改 shared_ptr）涉公共 API 变更，后续单独评估 | | CC-06 | P2 | 评估无风险，裁决放行 | 公共头新增 mutex/atomic 成员致 ABI 变更；但 OHOSApplication/AbilityStage/AbilityLifecycleExecutor 均由 shared_ptr 持有、OpenHarmony 全树重编译，无实际运行破坏 | | CC-07 | P2 | 评估无风险，裁决放行 | StageState/GetStageState/SetStageState 公共符号属 API 表面扩展（非破坏性）；未文档化/const 语义可后续补文档，不影响运行 | > 以上 3 项经评估无风险，视为已处置（不计评分、不计 must_fix 阻塞），保留在本报告作为裁决记录与 followups 跟踪。 --- ## 3. 必须立即处理（P0/P1） **无。** 所有 P1/P2 已修复消除或评估无风险裁决放行，无 P0/P1 阻塞项。 --- ## 4. 建议跟进（P3） | ID | 优先级 | 问题 | 状态/建议 | 排期 | |---|---|---|---|---| | CC-08 | P3 | runtimeMutex_ 持锁调用外部 Runtime::*（死锁风险，当前不可触发） | 观察项；随 CC-01 方案三一并解决 | 跟进 | | CC-09 | P3 | 使用方检查 READY 后、调用前并发 OnDestroy（check-then-act TOCTOU）；shared_ptr 保活无 UAF，窗口极窄 | 观察项，可接受 | 跟进 | > 裁决放行项（CC-01/CC-06/CC-07，原 P1/P2，评估无风险，不计评分）作为已知遗留登记跟踪，详见 §1 门禁放行裁决记录与 §遗留。 --- ## 5. 分维度速览 | 维度 | 结果 | 关键说明 | |---|---|---| | security-scanner | CC-01（P1, 裁决放行）、CC-08（P3, 观察） | CC-02/CC-10 已修复消除 | | logic-scanner | CC-09（P3, 观察） | CC-03/CC-04/CC-05 已修复消除 | | input-scanner | 0 | 无适用 | | api-scanner | CC-06（P2, 裁决放行）、CC-07（P2, 裁决放行） | 已裁决放行 | --- ## 6. 已修复消除项（本会话代码修复） | ID | 原等级 | 修复 | 位置 | |---|---|---|---| | CC-02 | P2 | abilityStages_.size() 移入 abilityStagesMutex_ 锁内，消除数据竞争 UB | OnMemoryLevel :389-390 | | CC-03 | P2 | 检查 emplace 返回值：重载1 复用 map 中 stage + reuseExisting 跳过重复初始化；重载2 return false | AddAbilityStage :692-703、:1019-1021 | | CC-04 | P2 | SetStageState(DESTROYING) 移到 erase 之前（锁内），缩小 TOCTOU 窗口 | CleanAbilityStage :1075-1076、CleanEmptyAbilityStage :1362-1363 | | CC-05 | P2 | erase 前锁内重新校验 ContainsAbility，并发 AddAbility 使 stage 非空时 skipErase 跳过 | CleanAbilityStage :1073-1084 | | CC-10 | P3 | ExecuteAutoStartupTasks 失败补回滚（erase + DESTROYING），不卡 INITIALIZING | AddAbilityStage :1029-1032 | --- ## 附：本会话累计改动 ### 变更文件列表（未提交） - frameworks/native/appkit/app/ohos_application.cpp（+59/-34，含 CC-02/03/04/05/10 五项修复） ### 验证 - git diff --stat：1 文件 +59/-34 - 定向复审：CC-02（size 锁内）、CC-03（emplace 返回值）、CC-04（DESTROYING 时序）、CC-05（锁内 ContainsAbility）、CC-10（失败回滚）grep 全部确认 ✅ - 测试逻辑分析：AddAbilityStage_0100（nullptr 边界）、OnMemoryLevel_0200/0210/0220、CleanAbilityStage_0300/0400/0500 行为不变 ✅ - 编译：⚠ 未运行（环境 ninja 配置错误 Contacts_DataAbility.stamp，非本次引起）。建议干净环境运行 ./build.sh --product-name rk3568 --build-target appkit_native + run -t UT -tp ability_runtime --- ## 变更摘要 为 commit 2ccdb51f + 本会话全部修复出具 R3 最终报告。5 项代码修复消除（CC-02/03/04/05/10），3 项 P1/P2（CC-01/06/07）经门禁复核人评估无风险书面裁决放行（视为已处置，不计评分）。评分 52→96，无 P0/P1 阻塞，**门禁 approve，可上库**。仅余 2 项 P3 观察项（CC-08 不可触发、CC-09 窄窗口可接受）登记 followups。 ## 兼容性/权限/DFX 影响 - 兼容性：本会话修复均为内部实现控制流调整，无公共 API/头文件/BUILD.gn 变更；CC-06（公共头 ABI）经评估无风险裁决放行 - 权限/DFX：无鉴权/hisysevent/红线变更；新增 TAG_LOGW 诊断日志 - 行为变更：① DESTROYING 标记提前（erase 前）；② emplace 并发失败不产生孤立 stage；③ ExecuteAutoStartupTasks 失败立即移除；④ size() 锁内读取；⑤ erase 前重新校验 ContainsAbility ## 遗留（followups，不阻塞上库） - **CC-01**（裁决放行）：pre-existing UAF，待方案三（runtime_ 改 shared_ptr）+ 公共 API 兼容性评估根因修复 - **CC-06/CC-07**（裁决放行）：建议合入前走 API 兼容性评估留档、后续补公共 API 文档 - **CC-08/CC-09**（P3 观察项）：当前不可触发/可接受，随 CC-01 方案三一并评估 - 建议干净环境运行编译 + ohos_application_test 单测完成最终验证 See merge request: openharmony/ability_ability_runtime!20223 | 4 天前 |