Did we have an issue during the M60 rollout on Android?

Crash reports also show a notable spike:

https://uma.googleplex.com/p/chrome/stability_continuous?sid=ac25efea45e20073511c85e5b6b5636c

That spike in the UMA graph is almost certainly a GMSCore rollout, we're seeing it across the board.  That said I don't think it explains "Chrome won't start" feedback, only isolated "force quit" reports.  Robert, Abhishek - are we seeing "won't start", "force quit", or both?

Issue 749903 is also tracking crash spikes in JP, but that's for renderer only - we should note this in case our signals are being crossed.

I'm interested in the fact that most negative feedback is on KK or lower....

+yfriedman@, ranj@ to see if they can find any trends in data.

We see both. 2 out of 23 reports mentioned "force quite" and the rest only mentioned "won't start".
https://listnr.corp.google.com/report/69829284074
https://listnr.corp.google.com/report/70421663014

Doesn't this graph suggest there's no spike in feedback of thsi sort: https://listnr.corp.google.com/product/282/issue/a11:69647b14:930545?dateRange=30 ?

Sampling those I also at least 3 of them where chrome is open in the image (include one which is a super old version of chrome - pre-material design).

Here's a better link for actualyl looking at them:
https://listnr.corp.google.com/product/282/issue/a11:69647b14:930545?collapseIssueChart=true&dateRange=30&versions=60.0.3112.97

there do appear to be higher than expected Japanese but the trendline I mentioend above is still valid

Page loads also look fine for Japan: https://uma.googleplex.com/p/chrome/timeline_v2?sid=73b5f7a9b817bb301172f56b43f469f2

(happy to hear if there's a better way to look at that query too)

I think it might be good to filter by play store comments only as link below since users are not able to open Chrome to send feedback from overflow menu.
https://listnr.corp.google.com/product/282/issue/a11:69647b14:930545?collapseIssueChart=true&dateRange=30&sources=8590027391&versions=60.0.3112.97

There's literally 0 actionable data in those reports though :/
As I said in #7 - in aggregate at least, it doesn't seem like Japanese users are broken

Are you able to respond to the comments and get more feedback from those users about what they're experiencing? Without more info, as far as I can see aggregate stats look fine

Yes, our team in Tokyo has been responding to those users. Is there specific question/information we should get from users?  

And I can edit the query to show the same thing for 59: 
https://listnr.corp.google.com/product/282/issue/a11:69647b14:930545?collapseIssueChart=true&dateRange=30&sources=8590027391&versions=59.0.3071.125

I don't really have anything specific at this point :/

Do we typically ask them to clear data/uninstall updates/re-apply them and see if that helps?

Could confirm:
- when did it start
- do they load chrome and see sad tab vs chrome doesn't even start
- what device are they one
- send a bugreport after it fails to start. but note this can contain pii so they shouldn't post it to public forms - do we have a channel to get this info?

Following crash has spiked starting Aug 10
Crash : https://listnr.corp.google.com/product/282/crash/1000000000009988910?dateRange=30

Top Devices
GT-I9060I	4,105	4.5%
GT-I9301I	3,054	3.3%
SM-T113	        3,035	3.3%
GT-I9300	2,070	2.3%
SM-G7102	2,006	2.2%

Locales
en_US	18,368	14.9%
ja_JP	10,587	8.6%
pt_BR	10,037	8.1%
ar_AE	8,826	7.2%
en_GB	8,063	6.5%

Stack Trace
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.chrome/org.chromium.chrome.browser.document.ChromeLauncherActivity}: java.lang.NullPointerException
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2279)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2332)
	at android.app.ActivityThread.access$800(ActivityThread.java:184)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1280)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:136)
	at android.app.ActivityThread.main(ActivityThread.java:5281)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:515)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:607)
	at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
	at org.chromium.chrome.browser.firstrun.ToSAckedReceiver.checkAnyUserHasSeenToS$51662RJ4E9NMIP1FCDNMST35DPQ2UGRFDPQ6AU3K7CKLK___0(ToSAckedReceiver.java:19)
	at org.chromium.chrome.browser.firstrun.FirstRunFlowSequencer.checkIfFirstRunIsNecessary(FirstRunFlowSequencer.java:14)
	at org.chromium.chrome.browser.firstrun.FirstRunFlowSequencer.launch(FirstRunFlowSequencer.java:41)
	at org.chromium.chrome.browser.document.ChromeLauncherActivity.onCreate(ChromeLauncherActivity.java:94)
	at android.app.Activity.performCreate(Activity.java:5285)
	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2243)
	... 11 more

magicSignature - [Android Java Exception] java.lang.RuntimeException at android.app.ActivityThread.performLaunchActivity(ActivityThread.java)

hrmm, the line numbers are garbage, but the stack seems like a plausible early crash. will try and look

Looking at https://codereview.chromium.org/2833673003 since it seems to be a fairly large chagne to FRE and new in m60
+Ted since Dan is gone :(

 Issue 752145  may be related as that stack is also seen there and matches symptoms other users have described via Play Store ("Chrome crashes when I click links from other apps").

May not be the same but better safe than sorry.  Escalating this as a stable blocker given our current Play Store ratings, which also means it's a P-0.

Assigning to yfriedman@ disposition as he sees fit (including delegating to others if necessary).

I have this once again via CCT flow on a Samsung S3 GT-I9300/JZO54K, changed device language to Japanese.
I opened AGSA for the first time after updating to M60 and changing device language to JP.

FATAL EXCEPTION: main
08-15 12:50:09.730 E/AndroidRuntime( 4071): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.chrome/org.chromium.chrome.browser.document.ChromeLauncherActivity}: java.lang.NullPointerException
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2100)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2125)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.ActivityThread.access$600(ActivityThread.java:140)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1227)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.os.Handler.dispatchMessage(Handler.java:99)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.os.Looper.loop(Looper.java:137)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.ActivityThread.main(ActivityThread.java:4898)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at java.lang.reflect.Method.invokeNative(Native Method)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at java.lang.reflect.Method.invoke(Method.java:511)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1006)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:773)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at dalvik.system.NativeStart.main(Native Method)
08-15 12:50:09.730 E/AndroidRuntime( 4071): Caused by: java.lang.NullPointerException
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at org.chromium.chrome.browser.firstrun.ToSAckedReceiver.checkAnyUserHasSeenToS$51662RJ4E9NMIP1FCDNMST35DPQ2UGRFDPQ6AU3K7CKLK___0(ToSAckedReceiver.java:19)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at org.chromium.chrome.browser.firstrun.FirstRunFlowSequencer.checkIfFirstRunIsNecessary(FirstRunFlowSequencer.java:14)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at org.chromium.chrome.browser.firstrun.FirstRunFlowSequencer.launch(FirstRunFlowSequencer.java:41)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at org.chromium.chrome.browser.document.ChromeLauncherActivity.onCreate(ChromeLauncherActivity.java:94)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.Activity.performCreate(Activity.java:5206)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1083)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2064)
08-15 12:50:09.730 E/AndroidRuntime( 4071): 	... 11 more

Logs @ http://go/chrome-androidlogs1/7/755484 

I have hit this crash just twice so far. Its not consistent.

will look soon - in meeting / have to disappear for external committment in soon but can check back later. Ted can you or someone in mtv play with the device where we can repro

 I really don't understand how to make sense of
" 	at org.chromium.chrome.browser.firstrun.ToSAckedReceiver.checkAnyUserHasSeenToS$51662RJ4E9NMIP1FCDNMST35DPQ2UGRFDPQ6AU3K7CKLK___0(ToSAckedReceiver.java:19)"

I thought "$foo" would imply "foo" is an inner class but haven't seen it with a serial number and the line number is referring to an import statement

@amineer, have any of these reports come from later versions of Android?  Do you have the ability to check that?  That code "can't" run on anything L+ so it would be good to see if this was the bug you're seeing from across the board.

I guess I could have read the first comment :-/.  Only < KK, so that makes sense.

Ok...I have a theory that I'm trying to validate, but to me this looks like this will crash for anyone pre-L that goes through Android device setup where Chrome's ToS is listed.

We'd get pinged that the ToS has been seen, which means we'll skip FRE on non-MAIN intents (i.e. Custom Tabs).

The gotcha is that first run used to only run after native was initialized and now that is no longer the case.  So now we haven't run ProcessInitializationHandler#handlePreNativeInitialization by the time we ask TosAckedReceiver.  The easy fix would be to call that during startup.

Stack:
08-16 00:05:15.728 11666 11666 E AndroidRuntime: java.lang.AssertionError: AccountManagerFacade is not initialized!
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at org.chromium.components.signin.AccountManagerFacade.get(AccountManagerFacade.java:125)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at org.chromium.chrome.browser.firstrun.ToSAckedReceiver.checkAnyUserHasSeenToS(ToSAckedReceiver.java:61)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at org.chromium.chrome.browser.firstrun.FirstRunFlowSequencer.checkIfFirstRunIsNecessary(FirstRunFlowSequencer.java:278)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at org.chromium.chrome.browser.firstrun.FirstRunFlowSequencer.launch(FirstRunFlowSequencer.java:363)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at org.chromium.chrome.browser.document.ChromeLauncherActivity.doOnCreate(ChromeLauncherActivity.java:196)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at org.chromium.chrome.browser.document.ChromeLauncherActivity.onCreate(ChromeLauncherActivity.java:120)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.app.Activity.performCreate(Activity.java:6975)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1213)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2770)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2892)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.app.ActivityThread.-wrap11(Unknown Source:0)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1593)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:105)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:164)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:6541)
08-16 00:05:15.728 11666 11666 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method

The code in M60 that crashes is here:
https://chromium.googlesource.com/chromium/src/+/95d6e720c235f105aa3182e2a1b2f826cfaa483f/chrome/android/java/src/org/chromium/chrome/browser/firstrun/ToSAckedReceiver.java

Even though the line numbers make no sense, it seems like it's crashing with a NullPointerException in: checkAnyUserHasSeenToS(Context).

That method doesn't do a lot, and typically checks for null for most things. There are a couple of things that are not null-checked though:
- ContextUtils.getAppSharedPreferences() - Requires call to ContextUtils.initApplicationContext(), which happens super early in ChromeApplication#attachBaseContext(...).
- AccountManagerHelper.get() - Potentially unsafe.
- accountHelper.getGoogleAccountNames() (safe, because a new ArrayList() is created and returned).

When looking at AccountManagerHelper.get(), that class was changed a bit recently, but a very interesting CL landed for M60:
https://codereview.chromium.org/2836373003

Instead of automatically and lazily creating the AccountManagerHelper, it now requires a call to AccountManagerHelper#initializeAccountManagerHelper(...). See the M60 code:
https://chromium.googlesource.com/chromium/src/+/refs/branch-heads/3112/components/signin/core/browser/android/java/src/org/chromium/components/signin/AccountManagerHelper.java

From what I can tell, the BroadcastReceiver in question (ToSAckedReceiver) does not call AccountManagerHelper#initializeAccountManagerHelper(...), but it probably needs to.

Also, timing wise, it makes sense for this only to hit M60:
From https://chromiumdash.appspot.com/commit/c613e1f102863081348db126d8db74fc11e389fb :
Canary 60.0.3086.0 | Dev 60.0.3087.3 | Beta 60.0.3112.20 | Stable 60.0.3112.78

It could be that adding something like this before the AccountManagerHelper.get() lookup would help:

###
AccountManagerHelper.initializeAccountManagerHelper(context, AppHooks.get().createAccountManagerDelegate());
###


Adding author bsazonov@ to CC.

+bsazonov

Working on a fix

To be completely explicit here:

 - tedchoc@ has noted that, at least as of right now, he's not confident the regression they / nyquist@ discovered would affect a user that upgraded to M60 and then failed to start

 -  Issue 752145  tracks symptoms that are identical to what is being described above (users crashing when tapping a link in a CCT from another app)

So the fix that tedchoc@ is working on may be inapplicable to this bug, and more work may need to be done to investigate why 20+ users are reporting Chrome "won't start."  tedchoc@ will review in more detail once they're done with the fix patch; we may need to continue to allocate resources to solve this bug, if it turns out we have separate problems.

I think we need to audit all usages of AccountManagerHelper.get()/AccountManagerFacade.get() to ensure no other ones are called during startup.  I'll likely have to defer to bsazonov@ to investigate that more.

Thanks for jumping on this quickly and fixing! I get that there's possibly another issue but we're struggling with having much visibility into it. Would be great if we can feedback from users with more details to try and narrow our focus 

regarding the trend, you can observe it here: 
https://pulse.corp.google.com/#/feedbackneutron?filterList=%7B%22product_name%22:%5B%22Chrome%20-%20Mobile%22%5D%7D,%7B%22report.location.country_code%22:%5B%22JP%22%5D%7D,%7B%22category_name%22:%5B%22UserFeedback-iOS%22%5D,%22_neg%22:1%7D,%7B%22FLATTENED_ISSUEDEPTH3%22:%5B%22%23issue%3EChrome%3EPerformance%3ECrashing%22%5D%7D,%7B%22product_version_group_1%22:%5B%2259%22,%2260%22%5D%7D&dimensions=product_name,category_name,FLATTENED_ISSUEDEPTH1,FLATTENED_ISSUEDEPTH2,FLATTENED_ISSUEDEPTH3&selected=All,,&level=0&unique=0&printView=false&days=CUSTOM&weeklyAvg=false&fbtab=reports&FeedbackIssuesView~AplosGraph~settings=product_version_group_1,Reports,DAILY,,10,,,,auto,auto,,,FeedbackIssuesGraph,&FeedbackIssuesView~AplosGraph~disabledFilterSets&FeedbackIssuesView~1BreakdownPie~settings=PIE,mobile_model,f&start=%22May%2001,%202017%22&end=%22Aug%2016,%202017%22

Most of these reports are tagged as "Performance>Crash" instead of 'won't start" because users report "force-closing" in actual reports and it is interpreted by tagging system as "crash". 
Most of the reports are about force-closing of the app after start. 

You can see that we get almost no such reports from JP in M59 rollout, and do get a few after M60. Keep in mind that M60 is only at 5% as of today so this effect likely to increase. 

What we can confirm based on reports we already have:
 
- when did it start

A: Highest number of reports so far is on Aug 13th, some users explicitly state it happens after latest update (presumably M60) 

- do they load chrome and see sad tab vs chrome doesn't even start

A: They see error message along the lines of  "Problem has occurred and app has stopped" as soon as they start the app. 

- what device are they on

A: We have information of device for each playstore review (under the fold "Product specific data" - i see no consistency in the devices this is sent from, aside from all being older that KitKat OS. Do we need list of all devices involved? 

- send a bugreport after it fails to start. but note this can contain pii so they shouldn't post it to public forms - do we have a channel to get this info?

Do you mean the Android bug report as opposed to in-app feedback (since that is unavailable) ? 
We can start asking users who posted this reviews to do that (e.g. by providing an email alias)  

Users reports that they have tried common troubleshooting like clearing cash etc which did not help

Devices: perhaps interestingly, most of the devices are Fuji or Sharp, with 2 reports from Sony devices
E.G
FJT21_jp_kdi
FJL22_jp_kdi
F01F
SH-01G
SH04E
SHV31
SH-02G
SO-01F

Yes, I mean an android bugreport. Since in-app feedback isn't available this is the way to get us more actionable informatoin about the crash

Ted, thanks for the fix!

A bit of background for my change: old creation routine for AccountManagerHelper would create SystemAccountManagerDelegate in this case. SystemAccountManagerDelegate can't get account lists on Android M+, so all accounts checks would be broken.

I've reviewed other usages of AccountManagerFacade.get():

1. ForcedSigninProcessor.start is used from ProcessInitializationHandler.handleDeferredStartupTasksInitialization (invoked after native side finishes loading) and SupervisedUserContentProvider (calls handleSynchronousStartup before it https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/superviseduser/SupervisedUserContentProvider.java?l=78&rcl=6bf7d52ad80626d85d1f9b2c55055784ee8ed09e).
2. FirstRunActivity and related classes should be safe because handlePreNativeStartup is invoked from AsyncInitializationActivity.onCreate: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/init/AsyncInitializationActivity.java?l=283&rcl=0e3e1e8933c049595a1b9807b36f5edeee2bc4b2.
3. Settings-related accesses (SyncedAccountPreference, SignInPreference, AccountManagementFragment and SyncCustomizationFragment) should be pretty safe - if I understand correctly, it isn't possible to open settings activity before native side is initialized.
4. InvalidationGcmUpstreamSender fix was already merged into M-60: https://crbug.com/731196.
5. ChromeBackupAgent initializes browser before accessing accounts: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/ChromeBackupAgent.java?l=354&rcl=d17af2013f9588c212c613e84c5dd312d44ef1d1.
6. InvalidationClientService is subclassed by ChromeInvalidationClientService that invokes initializePreNative in onCreate: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/invalidation/ChromeInvalidationClientService.java?l=17&rcl=5019fe1f30c52750571f3c1cced543ca01c16495.
7. FeatureUtils.canAllowSync is called from ForcedSigninProcessor (see 1), FirstRunFlowSequencer and FirstRunSignInProcessor (see 2).
8. ChildAccountService.checkHasChildAccount is invoked from AndroidEduAndChildAccountHelper that is used from ForcedSigninProcessor (see 1) and FirstRunFlowSequencer (see 2).
9. AccountTrackerService calls native methods in places accessing AccountManagerFacade, so we can expect native side to be initialized there.

I'll take a closer look at some of the remaining usages (especially AndroidSyncSettings), but so far it looks like Ted's fix should resolve this issue.

Do we also know what release of android these devices are on?

I see that all reports from that link in #34 were from api 17 or 19 (i.e. KK or earlier) so it does fit with the kitkat & earlier aspect of the current fix but according to Ted & Tommy that doesn't affect main intents :/

I pinged bsazonov@ and they noted:

"""
Oh, yeah, ToSAckedReceiver is called from FirstRunFlowSequencer.checkIfFirstRunIsNecessary: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/firstrun/FirstRunFlowSequencer.java?l=278&rcl=82cd07781b74cde019826c73e9706f9c113902b7
This method is invoked from multiple startup paths: https://cs.chromium.org/search/?q=checkIfFirstRunIsNecessary&m=100&sq=package:chromium&type=cs
"""

So based on that this *can* impact app startup and this one fix should hopefully resolve all our issues.  Anyone feel otherwise?  If not I'll merge the two bugs and we'll roll with Ted's fix in our respin.

Ok - possibly reaching but could it be possible that the launcher on these devices doesn't specify ACTION_MAIN and is instead using ACTION_VIEW? That would cause us to hit the same codepath wouldn't it?

Re: #40, it should be short-circuited though for non-main intents (#41). That's why we didn't think it would affect normal app launch - unless OEMS are doing customizations

Since we think the fix for this will be the same as the fix for  issue 752145 , I'm marking this as a duplicate.  Let's cross our fingers and see what happens.

Similar issue is observed in Chrome v60.0.3112.116
executing service com.android.chrome/org.chromium.chrome.browser.invalidation.
ChromeInvalidationClientService

"main" prio=5 tid=1 Waiting
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x732635e0 self=0xe6f5a000
  | sysTid=9693 nice=-10 cgrp=default sched=0/0 handle=0xea98d4a8
  | state=S schedstat=( 106574290682 80706130029 205925 ) utm=7066 stm=3591 core=0 HZ=100
  | stack=0xff5a0000-0xff5a2000 stackSize=8MB
  | held mutexes=
  at java.lang.Object.wait(Native method)
  - waiting on <0x0ab8f823> (a java.lang.Object)
  at java.lang.Thread.parkFor$(Thread.java:2135)
  - locked <0x0ab8f823> (a java.lang.Object)
  at sun.misc.Unsafe.park(Unsafe.java:358)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:190)
  at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:450)
  at java.util.concurrent.FutureTask.get(FutureTask.java:192)
  at android.os.AsyncTask.get(AsyncTask.java:542)
  at org.chromium.chrome.browser.widget.DateDividedAdapter.getCachedCalendars(DateDividedAdapter.java:166)
  at org.chromium.chrome.browser.widget.DateDividedAdapter.compareDate(DateDividedAdapter.java:154)
  at org.chromium.chrome.browser.widget.DateDividedAdapter.loadItems(DateDividedAdapter.java:16)
  at org.chromium.chrome.browser.download.ui.DownloadHistoryAdapter.filter(DownloadHistoryAdapter.java:174)
  at org.chromium.chrome.browser.download.ui.DownloadManagerUi.enableStorageInfoHeader(DownloadManagerUi.java:179)
  at org.chromium.chrome.browser.download.ui.DownloadManagerUi.<init>(DownloadManagerUi.java:63)
  at org.chromium.chrome.browser.download.DownloadActivity.onCreate(DownloadActivity.java:11)
  at android.app.Activity.performCreate(Activity.java:6975)
  at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1214)
  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2775)
  at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2897)
  at android.app.ActivityThread.-wrap11(ActivityThread.java:-1)
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1598)
  at android.os.Handler.dispatchMessage(Handler.java:105)
  at android.os.Looper.loop(Looper.java:255)
  at android.app.ActivityThread.main(ActivityThread.java:6563)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)

That looks like a different issue.  Did you grab that log as part of an ANR?  Could you file a separate bug for what you're seeing?

Re #44: We really should forbid AsyncTask.get :(
We've been using it to cheat strictmode but it's arguably no better.