Issue with Android metrics when OS kills activity #9
Description
Hi!
We've discovered another issue where we're seeing unrealistic high numbers for Android (we're talking multiple minutes).
If I understand the lifecycle mechanics of Android correctly, I believe there will be cases where the app is pushed to the background and the Android OS will clean up the Activity context while the Application context is still available. When the app is later returned to the foreground, the Activity context (which will execute any JavaScript calling the API for getting startup time data) gets re-created. Since the Application context was still available, the new calculation will be based on the old timestamp generated when the Application context was created.
This means that the concept of startup time is a bit more complex in the Android domain compared to on iOS. One need to distinguish between "hot" case (Application context is already available, Activity gets created) and "cold" case (Application context needs to be created, Activity gets created). The "unified" way to treat startup time between platforms would be to only care about the "cold" case.
One way of resolving this could be to only calculate and resolve the value once from the native side. Subsequent calls would then either return the same value or reject the call (allowing conditional reporting on the JavaScript side of things).