others have been landing CLs despite flakes, so either you were really unlucky, or your CL actually introduced a flake in these tests. My guess is the latter

You can run the tests locally with an android device attached (bots use nexus 5 running kitkat)

ninja -C out/Default chrome_public_test_apk && ./out/Default/bin/run_chrome_public_test_apk --num_retries=0 -v --release -f PrecacheLauncherTest#testUpdateEnabled_SyncNotReady_ThenDisabled

You can also add --repeat=50 --break-on-failure if you want to loop the test.

Hi Boliu,

Thank you very much for your advice (and commands)!

I tried on a different (simpler CL, https://codereview.chromium.org/2615713003/) and this test passes locally multiple times.

What else could I try?

I forgot to mention, that CL fails on the same test on a trybot.

https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/207634

Sorry for multiple posts (it's late :) ), I have Nexus 6P only, which may explain the difference. I will probably have to wait for this to resolve, because I have no clue how I could influence these tests.

These tests has been pretty green on the main waterfall bot:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=chrome_public_test_apk&tests=PrecacheLauncherTest

> I tried on a different (simpler CL, https://codereview.chromium.org/2615713003/) and this test passes locally multiple times.

You are enabling an ntp feature there. Just because a CL is tiny does not automatically mean it only has a small effect. In this case enabling a feature can of course cause tests that made bad assumptions to break.

I don't know much about ntp either, but all the evidence points to your CL actually causing these test to flake or fail, so you have to either learn how these tests work and why they fail, or you can ask someone more knowledgeable in these tests..

The issue went away by itself.