gaqscape.blogg.se

In Android Vitals - Diving into cold start waters 🥶, I explored what happens on app startup and concluded: The corresponding frame should be visible on the display within 16 ms. The second stacktrace shows that the end timestamp is captured when the window of that activity is done drawing.The first stacktrace shows that the start timestamp is captured when system_process receives an Intent to start an activity.When I start my app, I hit a breakpoint for ActivityMetricsLogger.notifyActivityLaunching():Īnd another breakpoint for TransitionInfoSnapshot.notifyWindowsDrawn(): Using a rooted device, I can connect a debugger to system_process: I'm using an API 29 device, and it turns out that API 29 measured startup time with SystemClock.uptimeMillis(), and API 30 measures it with SystemClock.elapsedRealtimeNanos(). Side note: this screenshot shows SystemClock.uptimeMillis() while the code I shared aboved showed SystemClock.elapsedRealtimeNanos().

I can put a breakpoint like I would in my app: Thanks Vincent for the idea! Lucky for us, Android Studio is set up to find sources for the Android version the app is compiled against: I have never tried to debug system_process, but there's no reason we can't.

I was telling a friend I hit a dead end looking at the Android sources, and he asked me:ĭuh. We now know where the start and end timestamps are captured, but unfortunately ActivityMetricsLogger.notifyActivityLaunching() and ActivityRecord.updateReportedVisibilityLocked() have many call sites, so it's hard to dig further within the AOSP source. Enter fullscreen mode Exit fullscreen mode