Menü
查询 UI 线程阻塞模式知识库。当你对某个方法的阻塞性质无法肯定时使用。 两步交互： 1. action=list → 获取知识库目录，了解有哪些已知阻塞模式 2. action=get → 获取指定模式的完整描述（特征、典型 API、检测启发式、StrictMode 可否检测） 先 list 浏览目录，再根据当前分析场景选择最相关的条目 get。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
从指定方法出发，返回该方法的完整 body 摘要（≤600字符）及其所有 direct callee 的签名和风险标签（I/O / DATABASE / NETWORK / THREADING / SYNCHRONIZATION / HANDLER）。 对可疑的 callee 再次发起 EXPAND 可获取其 body 及下一层 callee 信息， 逐层按需深入，避免一次性拉取过多无关代码。 已展开过 body 的方法会被自动跳过（记忆化），无需手动追踪。 是 ReAct 探索阶段调用最频繁的工具，四级决策（CONCLUDE/EXPLORE/EXPAND/MOCK）的核心依据来源。 【前置依赖】必须在同一 Agent 会话中先调用 SootStaticAnalyzer，才能使用本工具。 SootStaticAnalyzer 在运行时将分析结果同时写入内存索引（供本工具使用）和磁盘文件： - <agent目录>/skill1_output/ui_entry_points.json — UI 入口列表（method_signature 字段即为 method 参数的来源） - <agent目录>/skill1_output/call_graph.json — 全量调用图（可用于确认签名格式） 若未先调用 SootStaticAnalyzer，本工具将直接返回错误。
基于切片准则（目标语句关键词 + 关注变量），对方法的源码做后向静态切片， 提取所有可能影响该变量在目标语句处取值的相关语句。 算法：文本近似 PDG 遍历，包含数据依赖（def-use 链）和控制依赖（if/while/for 分支）。 将 LLM 需要分析的上下文从数百行压缩到 5-15 条语句，大幅降低推理噪声， 精确回答"哪个变量构造了这条 SQL"或"这个阻塞调用是否总会被执行"等因果问题。 【前置依赖】必须在同一 Agent 会话中先调用 SootStaticAnalyzer，再调用 CallChainExpander 定位可疑方法后，才调用本工具。本工具依赖 SootStaticAnalyzer 写入内存的索引（get_index()）， 若索引未初始化将直接返回错误。
在 Android 模拟器或真机上运行由 TestCaseGenerator 生成的测试用例， 收集动态执行证据，为 Reflection 阶段提供"地面真相（ground truth）"。 执行流程：编译-修复-重跑闭环（最多 3 轮）→ adb logcat -c 清空缓冲 → Gradle connectedAndroidTest 编译并运行 → adb logcat -d 抓取日志 → 解析 StrictMode 违规和 DroidUnblocker timing tag。 是整个系统中唯一进行动态分析的工具，是将误报率控制在 3% 以内的关键保障。
根据 ReAct 探索阶段给出的根因结论，生成一个可执行的 Android Instrumented Test（Kotlin）。 内部由三个子模块协作完成： (1) DependencyInliner 递归内联目标方法的项目内依赖，直到所有调用均落在 SDK 边界； (2) CallerContextCollector 从调用图反向找到所有调用者，提取从方法入口到调用点的 完整前置语句序列（还原真实调用状态，而非仅提取参数表达式）； (3) TestBodyAssembler 将内联代码与调用场景交给 LLM，翻译为 Kotlin 测试体。 生成的测试在主线程上直接调用目标方法，挂载 StrictMode 检测主线程 I/O / 数据库违规， 并通过 DroidUnblocker timing tag 记录 wall-clock 执行耗时，供 SandboxExecutor 解析。
遍历 Android 项目源码目录，使用 AST（tree-sitter）解析 Java/Kotlin 源文件及 XML 配置， 构建项目级函数调用图（FCG）并识别所有 UI 线程入口函数。 分析流水线共六步：扫描文件 → AST 解析 → 构建类层次（CHA）→ 解析回调注册 → 构建调用图 → 检测 UI 入口。结果写入 output_dir/ui_entry_points.json 和 output_dir/call_graph.json， 供 CallChainExpander 和 ProgramSlicer 共享使用。
Basierend auf der SOC-Berufsklassifikation
| name | KnowledgeQuery |
| description | 查询 UI 线程阻塞模式知识库。当你对某个方法的阻塞性质无法肯定时使用。 两步交互： 1. action=list → 获取知识库目录，了解有哪些已知阻塞模式 2. action=get → 获取指定模式的完整描述（特征、典型 API、检测启发式、StrictMode 可否检测） 先 list 浏览目录，再根据当前分析场景选择最相关的条目 get。 |
| parameters | {"type":"object","properties":{"action":{"type":"string","enum":["list","get"],"description":"list=获取目录，get=获取具体条目"},"id":{"type":"string","description":"条目 ID，action=get 时必填，如 CPU_INTENSIVE"}},"required":["action"]} |
| returns | action=list: { "entries": [{"id": "...", "summary": "..."},...] } action=get: 完整条目（description, typical_apis, detection_keywords, severity, strictmode_detectable） |
| usage_hints | ["当对方法的阻塞性质无法肯定时调用，不必每次分析都查询。","先 list 获取目录，再根据当前代码特征选择最匹配的条目 get。","strictmode_detectable=false 的模式在沙箱阶段只能靠 elapsed > 300ms 判定，CONCLUDE 时需在 root_cause 中注明。"] |
