Open rjrjr opened 4 years ago
This sounds similar to what @AquaGeek added via square/workflow#1083.
It is. We've actually had something similar for a long time, that generates files that Chrome can open and that it uses for its own tracing (Android used these too) - or they did until recently, apparently. This issue is partially to upgrade that tooling to the latest and greatest, and consider integrating with the OS itself. Although I don't think the OS facilities in Android has exact parity with os_signpost, so not sure that makes sense. Need to try it and see.
Fun fact: our diagnostic APIs have leapfrogged each other a couple times: square/workflow#129, square/workflow#343.
This should not block 1.0. I think the 1.0 blocker should be getting TracingDiagnosticListener out of the main module, and then cleaning up the DiagnosticListener API. Then the tracing/Perfetto stuff can all be done separately. Not sure it even makes sense to have the tracing tools in the main repo, they're all built on that DL API which is public.
This should not block 1.0. I think the 1.0 blocker should be getting TracingDiagnosticListener out of the main module, and then cleaning up the DiagnosticListener API. Then the tracing/Perfetto stuff can all be done separately. Not sure it even makes sense to have the tracing tools in the main repo, they're all built on that DL API which is public.
cc: @dhavalshreyas, and @AquaGeek for visibility into Zach's thoughts on debugging / tracing and 1.0.
Blocker tracked in square/workflow#1177
Quoth @zach-klippenstein: