Some of the Android startup histograms are empty, absent or broken.

For instance, the Startup.FirstCommitNavigationTime* is the most important end-to-end startup speed histogram on Android and it is currently broken.
@pasko recreated a history of this metric: https://docs.google.com/document/d/1PZa_x7FT7Uz1SBh1sGPKUo7gcU5spZGuxNm7XjuEa_I/edit

Following steps could make the Starup.FirstCommitNavigationTime* histogram better:
* Record the histogram only after the first commit. Currently it's recorded for all navigations what can be proved by the abnormally high histogram count and by too large values.
* Measure the time starting from the process creation instead of ForegroundStartTime. Currently we are losing all the datapoints for starting the activity without the native library loaded. That's a lot of important data missed.
* Discard cases when the application was run in background (offliner, AMP background tab, etc.) See http://crbug.com/711708 as an example of unexpected order of events causing a crash.
* Discard cases when a user action interrupts the startup sequence. It may shift the histogram to smaller values because users will likely interrupt the startup if it takes too long. It may be useful to create a separate histogram with "Uninterrupted" suffix instead of the discarding.

Other paths of Android startup speed metrics development:
* Make sure that we cover all user stories on Android such as:
  * Start with an intent
  * Start from the app launcher
  * Open Chrome from PWA shortcut
  * CustomTabs with warmup()
  * WebView startup
* Add startup histograms for First{,Contentful,Meaningful}PaintTime.
* Make Android startup metrics consistent with desktop. Startup metrics used on desktop platforms are tracked by chrome-speed-releasing@ and Chirp heartbeat metrics (so there's visibility and process if it regresses). In particular, we could implement some subset of Startup.FirstWebContents.* on Android.
 

Some of the Android startup histograms are empty, absent or broken.

For instance, the Startup.FirstCommitNavigationTime* is the most important end-to-end startup speed histogram on Android and it is currently broken.
@pasko recreated a history of this metric: https://docs.google.com/document/d/1PZa_x7FT7Uz1SBh1sGPKUo7gcU5spZGuxNm7XjuEa_I/edit

Following steps could make the Starup.FirstCommitNavigationTime* histogram better:
* Record the histogram only after the first commit. Currently it's recorded for all navigations what can be proved by the abnormally high histogram count and by too large values.
* Measure the time starting from the process creation instead of ForegroundStartTime. Currently we don't cover the important part of the startup latency because the ForegroundStartTime is measured after the native library is loaded. That's a lot of important data missed.
* Discard cases when the application was run in background (offliner, AMP background tab, etc.) See  http://crbug.com/711708  as an example of unexpected order of events causing a crash.
* Discard cases when a user action interrupts the startup sequence. It may shift the histogram to smaller values because users will likely interrupt the startup if it takes too long. It may be useful to create a separate histogram with "Uninterrupted" suffix instead of the discarding.

Other paths of Android startup speed metrics development:
* Make sure that we cover all user stories on Android such as:
  * Start with an intent
  * Start from the app launcher
  * Open Chrome from PWA shortcut
  * CustomTabs with warmup()
  * WebView startup
* Add startup histograms for First{,Contentful,Meaningful}PaintTime.
* Make Android startup metrics consistent with desktop. Startup metrics used on desktop platforms are tracked by chrome-speed-releasing@ and Chirp heartbeat metrics (so there's visibility and process if it regresses). In particular, we could implement some subset of Startup.FirstWebContents.* on Android.
 

Some of the Android startup histograms are empty, absent or broken.

For instance, the Startup.FirstCommitNavigationTime* is the most important end-to-end startup speed histogram on Android and it is currently broken.
@pasko recreated a history of this metric: https://goo.gl/NyvX39

Following steps could make the Starup.FirstCommitNavigationTime* histogram better:
* Record the histogram only after the first commit. Currently it's recorded for all navigations what can be proved by the abnormally high histogram count and by too large values.
* Measure the time starting from the process creation instead of ForegroundStartTime. Currently we are losing all the datapoints for starting the activity without the native library loaded. That's a lot of important data missed.
* Discard cases when the application was run in background (offliner, AMP background tab, etc.) See  http://crbug.com/711708  as an example of unexpected order of events causing a crash.
* Discard cases when a user action interrupts the startup sequence. It may shift the histogram to smaller values because users will likely interrupt the startup if it takes too long. It may be useful to create a separate histogram with "Uninterrupted" suffix instead of the discarding.

Other paths of Android startup speed metrics development:
* Make sure that we cover all user stories on Android such as:
  * Start with an intent
  * Start from the app launcher
  * Open Chrome from PWA shortcut
  * CustomTabs with warmup()
  * WebView startup
* Add startup histograms for First{,Contentful,Meaningful}PaintTime.
* Make Android startup metrics consistent with desktop. Startup metrics used on desktop platforms are tracked by chrome-speed-releasing@ and Chirp heartbeat metrics (so there's visibility and process if it regresses). In particular, we could implement some subset of Startup.FirstWebContents.* on Android.
 

Some of the Android startup histograms are empty, absent or broken.

For instance, the Startup.FirstCommitNavigationTime* is the most important end-to-end startup speed histogram on Android and it is currently broken.
@pasko recreated a history of this metric: https://goo.gl/NyvX39

Following steps could make the Starup.FirstCommitNavigationTime* histogram better:
* Record the histogram only after the first commit. Currently it's recorded for all navigations what can be proved by the abnormally high histogram count and by too large values.
* Measure the time starting from the process creation instead of ForegroundStartTime. Currently we don't cover the important part of the startup latency because the ForegroundStartTime is measured after the native library is loaded. That's a lot of important data missed.
* Discard cases when the application was run in background (offliner, AMP background tab, etc.) See   http://crbug.com/711708   as an example of unexpected order of events causing a crash.
* Discard cases when a user action interrupts the startup sequence. It may shift the histogram to smaller values because users will likely interrupt the startup if it takes too long. It may be useful to create a separate histogram with "Uninterrupted" suffix instead of the discarding.

Other paths of Android startup speed metrics development:
* Make sure that we cover all user stories on Android such as:
  * Start with an intent
  * Start from the app launcher
  * Open Chrome from PWA shortcut
  * CustomTabs with warmup()
  * WebView startup
* Add startup histograms for First{,Contentful,Meaningful}PaintTime.
* Make Android startup metrics consistent with desktop. Startup metrics used on desktop platforms are tracked by chrome-speed-releasing@ and Chirp heartbeat metrics (so there's visibility and process if it regresses). In particular, we could implement some subset of Startup.FirstWebContents.* on Android.