Cancellation via timeout in LaunchTracker not needed to support trampolining

[jstaahl]

Currently, a launch is considered in-progress until there are 500+ ms between an executed runnable posted from a lifecycle callback and the next lifecycle callback (or we receive our first frame). It seems this timeout-based approach for what is considered a launch still-in-progress is used to support the case of trampoline activities. Outside of the context of trampoline activities, this timeout doesn't really come into play. That's because if you post a runnable during an activity lifecycle event, it will not get executed until after onResume. In the context of trampolining activities, I think a good way to distill this down to what this actually accomplishes is to consider the path to the first frame after onResume as unbroken as long as the distance between the last lifecycle callback of one activity to the first lifecycle callback of the next is less than 500ms. However, I don't believe we need a timeout-based approach like this to support trampoline activities.

I believe that a more deterministic approach is to allow a launch measurement to continue indefinitely (until the first frame is rendered following onResume), unless the app ever goes from 1+ started activities to 0 started activities. In my testing, under all trampoline configurations, I am unable to get a transition from 1+ started activities to 0 started activities through the trampoline. Through the trampoline, we only ever go from 0 to 1+ started activities, and always remain at 1+ started activities.

[pyricau]

Sorry for the delayed response :)

Currently, a launch is considered in-progress until there are 500+ ms between an executed runnable posted from a lifecycle callback and the next lifecycle callback (or we receive our first frame).

That's not what the 500 ms threshold is for.

A launch is considered in-progress until an activity gets resumed and renders a frame. However, when that happens, if the app was invisible for less than 500 ms, then the launch is not reported (but it's also not kept as in progress).

If using trampoline activities properly (trampolining from Activity.onCreate(), the delay will not be hit, that's not what it's for. Trampoline activities will keep trampolining without being resumed / drawing a frame, and the launch will properly end on the first frame of the first (final) resumed activity.

If using trampoline activities incorrect (trampolining from or after Activity.onResume() ) then the launch will end with that trampoline activity.

The 500 ms delay covers a case where the transition between 2 activities (including trampolining activities) involves a gap in visibility. That's not normal behavior but some poorly coded app run into that (e.g. the Target app seems to disappear for a brief moment when going to the cart). The 500 ms delay ensures those cases aren't counted as launches.

[pyricau]

I'm closing but feel free to let me know if I missed something.

[pyricau]

I just realized there's another 500 ms check that cancels a launch in LaunchTracker if we get no lifecycle update for 500 ms.

pushLaunchInProgressDeadline() has the side effect of canceling the launch if the last update was more than 500 ms from the last post from lifecycle change. Turns out, that's the one you were mentioning here.