start AppStart span when installing activity lifecycle instrumentation

[beekhc]

This fixes issue #560 by calling AppStartupTimer#start in ActivityLifecycleInstrumentation#install.

Since start is idempotent, this will still work if a way to pass in a pre-started timer to the instrumentation is added later.

Added tests based on SlowRenderingInstrumentationTest. To verify the changes:

./gradlew :instrumentation:activity:testDebugUnitTest
./gradlew check

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: beekhc / name: Bee Klimt (d7b4015)

[LikeTheSalad]

Nice! Thank you for taking the time 🙏

[beekhc]

I don't have permission to merge this myself. Did you want to wait for a second reviewer, or do you want to merge it yourself?

[breedx-splk]

I am still wondering if we won't be better served long-term by having the timer started even earlier in the lifecycle, like perhaps as early as the agent can....but for now, it seems like starting it at all is an improvement over not starting it. 😬

[LikeTheSalad]

I am still wondering if we won't be better served long-term by having the timer started even earlier in the lifecycle, like perhaps as early as the agent can....but for now, it seems like starting it at all is an improvement over not starting it. 😬

I see what you mean. I think this use case might even require the timer to start before the agent is initialized, to be fully accurate. But yeah for now it's better to have it started rather than getting nothing.

[bidetofevil]

If the goal is to start the span as early as possible, you can always back-date the start time to when we know the process started. In API 24, Android added Process.getStartElapsedRealtime() and on 33, they added Process.getStartRequestedElapsedRealtime(). Both will get you pretty accurate times for when the process started without having to read the proc file's timestamp like we had to do in the old days.

[beekhc]

I would be happy to make a follow-up PR trying that.

One possible downside of this approach is you might get people asking "why does my app take longer to launch in API 24 and later?" when in reality, it's just measuring something different on different versions. But maybe that's an edge case not worth worrying about?

[bidetofevil]

A lot of apps have minSdk set to 24+ now, and the ones that don't likely have very low usage on API < 24. Given this, I think it's OK if we document this appropriately.