All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=905170

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=dbdac0716aaa843c87513557e4b3b79d0aea8cebdc8e880e955809f0c6c793a7


Bot(s) for this bug's original alert(s):

android-nexus5x-perf

system_health.common_mobile - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15f40d87e40000

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/15f40d87e40000

Reland "[Android] Remove most resource names in resources.arsc" by mheikal@chromium.org
https://chromium.googlesource.com/chromium/src/+/d3fd7a3e0505a4ca842d5c74cdfa125a8a381ef5
cpu_time_percentage: 0.1848 → No values

[tools/perf] Disable browse:chrome:* stories by perezju@chromium.org
https://chromium.googlesource.com/chromium/src/+/b1c0b554e0ff982245a77644057aec7581269487
cpu_time_percentage: No values → No values

Revert "Build internal android targets in telemetry_chrome_test." by jbudorick@chromium.org
https://chromium.googlesource.com/chromium/src/+/c7539ef6291836eff22077b38ae55bb62f536b99
cpu_time_percentage: No values → 0.2114

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

I feel that this is pretty late for the bug since my cl (Reland "[Android] Remove most resource names in resources.arsc") landed 14 days ago. Anyways, I believe I am the one who broke the perf tests (causing them to timeout,  issue 900909 ), but that cl has since been reverted, and relanded with a fix so as to not break those kind of tests anymore.

My CL stopped building targets?

The timeline of what happened was:

r604426 "remove resource names" broke the test
r604564 disabled the test (it was causing entire benchmark to fail)
r605451 fix for "remove resource names" issue, test still disabled.
r606139 "build internal android targets" took down entire perf waterfall
r606602 re-enabled the test, but the waterfall was still down.
r607095 revert "build internal android targets" restored waterfall

And while the test was down, something in:
http://test-results.appspot.com/revision_range?start=604426&end=607095&n=1000 (2669 commits)

caused this metric to regress.

+Speed>Bisection in case they can recommend something to bisect over the failed range.