accessibility-trace-analyzer

name

accessibility-trace-analyzer

description

Analyze Android accessibility trace logs and convert them into actionable permission-flow insights, click-step reconstruction, and builder-ready automation rules. Use when a user pastes trace content containing AccessibilityEvent logs, windows snapshots, node trees, permission dialogs, ROM-specific permission flows (Xiaomi/HyperOS, HONOR/MagicOS, ZTE/AOSP, etc.), or asks to identify what was clicked, reconstruct authorization steps, summarize a permission flow, or turn a trace into builder/automation logic.

Accessibility Trace Analyzer

Analyze the pasted trace and produce a compact, implementation-oriented answer.

Output goals

Prefer this structure when it fits:

1. 结论

   • State whether the trace is sufficient.
   • State whether the flow was completed, partially completed, or failed.

2. 页面 / 步骤还原

   • Reconstruct the flow in order.
   • For each step, identify:
     • package
     • page/dialog type
     • key title text
     • key button/radio/switch candidates
     • most likely user/automation click

3. 关键控件

   • List stable selectors first:
     • view id
     • package
     • title text
     • button text
   • Prefer ids over text when ids exist.

4. 自动化规则建议

   • Convert the trace into builder/handler logic.
   • Separate rules by ROM/vendor when appropriate.
   • Keep the rules concise and implementation-ready.

5. 不确定点 / 风险点

   • Clearly mark inferred clicks vs directly observed clicks.
   • Say when a trace is insufficient to determine the exact action.

What to extract

For each important event, look for:

• Event type
• Package name
• Activity/class name
• Window snapshot changes
• Title text / headline text
• Button text
• Radio/checked state
• Whether the app returned to its own page
• Whether foreground/background/storage permission became granted

Reconstruction rules

1. Identify direct clicks vs inferred clicks

Treat these as directly observed:

• TYPE_VIEW_CLICKED
• a checked-state change immediately following a unique clickable item

Treat these as inferred when no direct click exists:

• permission state changed from ✗ to ✓
• dialog disappeared and next page implies a specific choice
• only one action is compatible with the resulting state

Always label inferred actions as inferred.

2. Prefer stable selectors

Priority order:

1. viewIdResourceName
2. package + title text
3. button text
4. class-only heuristics

When writing automation advice, prefer combinations like:

• package + alertTitle id + button text
• package + page title + specific id

3. Distinguish ROM families

Common vendor buckets:

• AOSP / PermissionController / ZTE-like
  • often com.android.permissioncontroller
• Xiaomi / MIUI / HyperOS
  • often com.lbe.security.miui
• HONOR / MagicOS / Huawei-like variants
  • may rely more on settings pages, window transitions, and nonstandard active roots

Do not merge vendor flows unless the trace clearly shows the same UI structure.

4. Detect completion

Consider the flow completed when the trace shows a clear final permission state, for example:

• 前台定位 ✓ ｜ 后台定位 ✓
• return to app with success status text
• permission page shows the desired final checked option

5. Detect weak traces

If the trace has many events but little tree data, say so explicitly. Typical signs:

• repeated TYPE_WINDOWS_CHANGED with no useful tree
• rootInActiveWindow = null
• only app-page events but no system dialog tree

When the trace is weak, recommend recorder improvements instead of overclaiming.

Builder-ready translation style

When the user asks for code/builder logic, produce rules in this form:

• Match
  • package
  • title/id/text
• Action
  • click specific id or text
  • ensure checked state when needed
• Notes
  • fallback or timing caveats

Example shape:

Rule A: foreground location dialog
- Match:
  - packageName == "com.lbe.security.miui"
  - title id == "com.lbe.security.miui:id/alertTitle"
  - title contains "允许“TestGrants”获取位置信息？"
- Action:
  - ensure "precise_location" checked
  - click "仅在使用中允许"

When traces mention recorder quality issues

If the user asks why the trace is incomplete, evaluate whether the recorder should add:

• windows snapshot
• root fallback from service windows
• null-root reason logging
• stronger dumping on TYPE_WINDOWS_CHANGED / TYPE_VIEW_CLICKED

Recommend those only when supported by the observed gaps.

Style

• Be practical.
• Be explicit about what is certain and what is inferred.
• Prefer implementation guidance over theory.
• If the user asks to send the result to another agent, summarize the final rules in a compact builder-oriented format.