Menu
查询 UI 线程阻塞模式知识库。当你对某个方法的阻塞性质无法肯定时使用。 两步交互： 1. action=list → 获取知识库目录，了解有哪些已知阻塞模式 2. action=get → 获取指定模式的完整描述（特征、典型 API、检测启发式、StrictMode 可否检测） 先 list 浏览目录，再根据当前分析场景选择最相关的条目 get。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
从指定方法出发，返回该方法的完整 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 共享使用。
| 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 中注明。"] |
