A system trace can tell you when a thread ran, which CPU core it ran on, and which FrameTimeline frame missed its deadline. With Binder/ftrace/sched evidence enabled, it can also reconstruct Binder calls and clues about waiting. But it does not know which frame ID a player is decoding, which scene a game engine is loading, or how long an application task has spent in a queue.

This article answers one question: how do application semantics enter a trace? The system can tell you that the main thread was slow; Track Event tells you which frame was being decoded, which queue was blocked, and which request moved between threads. Combining the two lets you narrow “the main thread was slow by 18 ms” to a candidate texture-upload interval around frame 1082, then continue validating it with RenderThread/HWUI, GPU, and FrameTimeline evidence.

The article follows the practical integration order: decide whether instrumentation is needed and at which layer, define an application-phase dictionary and backend, then build the minimal integration, category controls, combined system capture, and cross-thread flows. Finally, control write volume and define the app-side field tracing protocol.