hmos-appfreeze-analysis

Provide the faultlog file and optional sample stack file, then the Skill runs scripts/freeze/main.py with section flags to extract overview, resources, stacks, and Binder data step by step. It concludes with a structured report naming the root cause module and responsibility domain.

It supports APPFREEZE, THREAD_BLOCK_6S, APP_INPUT_BLOCK, LIFECYCLE_TIMEOUT, and BUSSINESS_THREAD_BLOCK_6S/BUSINESS_THREAD_BLOCK_6S business thread events. Business thread events are analyzed against the event-reported TID rather than the main thread.

No, the analysis scripts use only the Python standard library and built-in modules. You only need a working Python 3 interpreter and the correct paths to the faultlog and sample stack files.

It traces lock holders, Binder peer threads, FFRT workers, and libuv callbacks to the actual implementing module, then assigns responsibility as app, system, mixed, or undetermined. Fix suggestions are restricted to the determined responsibility domain.

System-level anomalies like low memory, CPU load above 85%, or thermal throttling distort DFX stack captures, making thread stacks unreliable. When NOTE contains system low memory and thermal throttling, the Skill terminates with a system overload conclusion.

Yes, dedicated reference guides cover FFRT worker exhaustion, task timeout, queue blocking, and primitive deadlocks, plus libuv event loop stalls, thread pool exhaustion, async callback abuse, and synchronous fs calls on the main thread.