Adding Sync because this is affecting chrome_sync_shell_tests, and Signin because it appears to be in the signin logic.

+gogerald who knows a lot about Android signin.

Assigning to Ganggui to take a look.

Ganggui, please take a look at why these tests are breaking when you have time.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7532546c368710e3b5c8b935151d3e60599ca6e

commit d7532546c368710e3b5c8b935151d3e60599ca6e
Author: boliu <boliu@chromium.org>
Date: Mon Sep 12 18:16:09 2016

Mark all chrome sync tests with @RetryOnFailure

Current theory is all chrome sync tests are flaky due to
 crbug.com/637448 . So mark all of them as requiring retry.

BUG= 619055 ,  637448 

Review-Url: https://codereview.chromium.org/2319863004
Cr-Commit-Position: refs/heads/master@{#417974}

[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/AutofillTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/BookmarksTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/FirstRunTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/GmsCoreSyncListenerTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/OpenTabsTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/SyncCustomizationFragmentTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/SyncTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/TypedUrlsTest.java
[modify] https://crrev.com/d7532546c368710e3b5c8b935151d3e60599ca6e/chrome/android/sync_shell/javatests/src/org/chromium/chrome/browser/sync/ui/PassphraseTypeDialogFragmentTest.java

Could not open the link, which test becomes flaky, all sync tests? I've tested *testPopupsNotBlocked* from above post log more than 10 times without failure.

You can find examples of flake here: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=chrome_sync_shell_test_apk

example: https://build.chromium.org/p/chromium.linux/builders/Android%20Tests/builds/31826/steps/chrome_sync_shell_test_apk%20on%20Android/logs/stdio

Looks like the log links have changed, https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.linux%2FAndroid_Tests__dbg_%2F35709%2F%2B%2Frecipes%2Fsteps%2Fchrome_public_test_apk%2F0%2Fstdout seems like the correct link now.

I think any test in in the Chrome Public instrumentation suite can fail, it looks like it happens during initialization.

I don't think it's related to chrome_sync_shell_tests

Ah I see, anything that inherits from ChromeActivityTestCaseBase then. So chrome_sync_shell_tests as well.

Comment #9, 10: looks the null pointer exception happens in getSharedPreference, but not sign in. 

I manually tested *testEnterPassphraseWhenSyncIsOff* more than 20 times without failure.

This seems to be causing many flakes of the chrome_public_test_apk step on the linux_android_rel_ng tryserver, causing retries and random failures of unrelated CLs:

https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng?numbuilds=200

Examples:

https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/145944
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/145938
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/145928
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng/builds/145905

Random affected CL:
https://codereview.chromium.org/2354713004/

I'm upgrading this to P0 as it's affecting Chromium's commit queue. A fix or workaround is urgently needed.

Ganggui, are you the right owner for this bug?

#13: 3 of the 4 of those -- all of the ones that didn't affect the CL you referenced -- are related to  issue 619055 , not this.

#15: sorry, you're right that a couple of those are not related. However, both of these:

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

have the same stack trace that this bug was filed for:

org.chromium.chrome.browser.instantapps.InstantAppsHandlerTest#testInstantAppsDisabled_incognito (run #1):
java.lang.ExceptionInInitializerError
	at org.chromium.base.ContextUtils.getAppSharedPreferences(ContextUtils.java:96)
	at org.chromium.chrome.browser.instantapps.InstantAppsHandlerTest.setUp(InstantAppsHandlerTest.java:40)
	at org.chromium.base.test.BaseTestResult.run(BaseTestResult.java:129)
	at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
	at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
	at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:554)
	at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1701)
Caused by: java.lang.NullPointerException
	at android.preference.PreferenceManager.getDefaultSharedPreferencesName(PreferenceManager.java:374)
	at android.preference.PreferenceManager.getDefaultSharedPreferences(PreferenceManager.java:369)
	at org.chromium.base.ContextUtils.access$000(ContextUtils.java:2085)
	at org.chromium.base.ContextUtils$Holder.<clinit>(ContextUtils.java:26)
	... 12 more

I didn't go through the rest of the chrome_public_apk failures on that trybot to categorize them.

#15: the first frame is the same, but then it diverges. That's for InstantAppsHandlerTest, while this bug is for ChromeSigninController.

Also, an exception in setUp? :(

Apologies, I didn't look closely enough at the stack trace. I saw the ExceptionInInitializerError in org.chromium.base.ContextUtils.getAppSharedPreferences and thought it was the same thing.

I'll downgrade this back to P1 and file a separate bug.

#18: no worries. They may be similar failures given the top of the stack trace -- seems they all may use a static in ContextUtils before it gets initialized in some scenarios.

Comment #14: As I replied in comment #11 and #9, #10, #17, this is not like a sign in related issue from stack trace. I am probably not the right owner.

I'll look into this as it's a ContextUtils initialization issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/640e90121d42acc469a533ae190e311841189827

commit 640e90121d42acc469a533ae190e311841189827
Author: wnwen <wnwen@chromium.org>
Date: Tue Sep 27 17:46:01 2016

Fix ContextUtils test flakiness.

There was a race condition between Android tests calling
Application#onCreate and TestRunner#runTests which caused flakiness
in some of the UrlManagerTest* and other instrumentation tests.

Initialize the application object earlier so that it is always ready
when tests are run.

BUG= 649224 , 637448 

Review-Url: https://codereview.chromium.org/2363323003
Cr-Commit-Position: refs/heads/master@{#421256}

[modify] https://crrev.com/640e90121d42acc469a533ae190e311841189827/chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java