[NOT ACTIONABLE BUT CONTINUING TO TRACK] IllegalArgumentException: reportSizeConfigurations: ActivityRecord not found for: Token…

[sentry-io]

Sentry Issue: https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/

IllegalArgumentException: reportSizeConfigurations: ActivityRecord not found for: Token{1b34caf ActivityRecord{c108c8e u0 org.wordpress.android/.ui.WPLaunchActivity t-1 f}}
    at android.os.Parcel.readException(Parcel.java:2017)
    at android.os.Parcel.readException(Parcel.java:1959)
    at android.app.IActivityManager$Stub$Proxy.reportSizeConfigurations(IActivityManager.java:9227)
    at android.app.ActivityThread.reportSizeConfigurations(ActivityThread.java:2934)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2877)
...
(8 additional frame(s) were not displayed)

reportSizeConfigurations: ActivityRecord not found for: Token{1b34caf ActivityRecord{c108c8e u0 org.wordpress.android/.ui.WPLaunchActivity t-1 f}}

[designsimply]

90-day impact: ~7 per day
Users affected in the last 90 days: 520
Last seen in: 12.8 (latest official release at the time of this comment)
Limited to: Android 8.1.0
^{https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[designsimply]

Moving to the prioritized list because the number of affected users is high.

[mkevins]

I think this is the same as #5821. I'm going to see if any of the related threads have a solution / workaround.

[mkevins]

@oguzkocer provided a great summary of this issue so far here: #5821 (comment)

Also in that thread, I found this: #5821 (comment), which suggests one possible cause for an ANR that could lead to the underlying issue.

Our app has a few places where this is used: here, here, and here. I'm not sure if it'd be possible to manipulate external storage to try to recreate the conditions that lead to the delay. We have some means to manipulate the device's sd card on the emulator, though I'm not sure that's sufficient for what we'd need to reproduce the issue. It may be worth a try, as using mksdcard should be relatively quick. In any case, it'd be a good way to test other edge cases we may want to have covered.

[designsimply]

90-day impact: ~13 per day
Users affected in the last 90 days: 770
Limited to: Android 8.1.0
^{https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[sentry-io]

Sentry issue: WORDPRESS-ANDROID-11

[sentry-io]

Sentry issue: WORDPRESS-ANDROID-3D

[designsimply]

90-day impact: ~26 per day
Users affected in the last 90 days: 996
Limited to: Android 7.0, 7.1.1, 7.1.2
^{https://sentry.io/share/issue/d0b737eb1217403db2260c0e157df01a/}

90-day impact: ~8 per day
Users affected in the last 90 days: 314
Limited to: Android 8.0.0
^{https://sentry.io/share/issue/e08be7350dfa44c393578494e4352b4c/}

90-day impact: ~18 per day
Users affected in the last 90 days: 856
Limited to: Android 8.1.0
^{https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[designsimply]

90-day impact: ~30 per day
Users affected in the last 90 days: 1000
Limited to: Android 7.0, 7.1.1, 7.1.2
^{https://sentry.io/share/issue/d0b737eb1217403db2260c0e157df01a/}

90-day impact: ~10 per day
Users affected in the last 90 days: 307
Limited to: Android 8.0.0
^{https://sentry.io/share/issue/e08be7350dfa44c393578494e4352b4c/}

90-day impact: ~21 per day
Users affected in the last 90 days: 906
Limited to: Android 8.1.0
^{https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[malinajirka]

These two crashes seem related:
https://sentry.io/share/issue/7e0a041d217948c1b954eb9df175e8b9/
https://sentry.io/share/issue/ec376e794d744adc85bf3a7b2d69b542/

[malinajirka]

I tried to replicate this issue by manually inserting Thread.sleep(30000) into the UploadService. I tried tons of scenarios, but when the app crashed, it would always crash with the following exception.

Caused by: java.lang.SecurityException: Caller no longer running, last stopped +27s256ms because: timed out while starting
        at android.os.Parcel.createException(Parcel.java:2071)
        at android.os.Parcel.readException(Parcel.java:2039)
        at android.os.Parcel.readException(Parcel.java:1987)
        at android.app.job.IJobCallback$Stub$Proxy.dequeueWork(IJobCallback.java:292)
        at android.app.job.JobParameters.dequeueWork(JobParameters.java:248)
        at androidx.core.app.JobIntentService$JobServiceEngineImpl.dequeueWork(JobIntentService.java:315)
        at androidx.core.app.JobIntentService.dequeueWork(JobIntentService.java:640)
        at androidx.core.app.JobIntentService$CommandProcessor.doInBackground(JobIntentService.java:390)
        at androidx.core.app.JobIntentService$CommandProcessor.doInBackground(JobIntentService.java:383)
        at android.os.AsyncTask$3.call(AsyncTask.java:378)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) 
        at java.lang.Thread.run(Thread.java:919) 
     Caused by: android.os.RemoteException: Remote stack trace:
        at com.android.server.job.JobServiceContext.assertCallerLocked(JobServiceContext.java:493)
        at com.android.server.job.JobServiceContext.doDequeueWork(JobServiceContext.java:371)
        at com.android.server.job.JobServiceContext$JobCallback.dequeueWork(JobServiceContext.java:160)
        at android.app.job.IJobCallback$Stub.onTransact(IJobCallback.java:169)
        at android.os.Binder.execTransactInternal(Binder.java:1021)

Which is a bit similar to the one in Sentry, but it's not the same exception.

I scanned through our service and haven't found anything suspicious. It seems Google Engineers are looking into the issue - https://issuetracker.google.com/issues/62427912#comment51 -> I'd suggest moving this out of the priority list/groundskeeping until Google provides their conclusion. We've spent a loooot of time on this issue in the last two years - I don't think it's worth spending anymore time on it, unless we have some new info eg. reproduction steps. cc @designsimply

P.S. I'm following the issue in Google's issue tracker.

[designsimply]

Users affected in the last 90 days: 2232
_{(1, 2, 3)}

[designsimply]

Users affected in the last 90 days: 2222
_{1, 2, 3}

[designsimply]

Users affected in the last 90 days: 2145
_{1, 2, 3}

[designsimply]

Events in the last 90d: 22,000
Users affected in the last 90d: 4,500
_{https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[zwarm]

I investigated this issue, time boxing it, during my groundskeeping rotation. My intention was to reproduce the issue. Sadly, I was unable to replicate it.

Here is what I have done:

• Attempts to recreate crash while focusing on a single app area (Notifications)
  • Backgrounding the app and open from notification tap
  • Backgrounding app while on notification list & reopen from notification taps
  • Update app multiple times (increasing app versions)
  • Fresh installs
  • Different emulators (24+)
  • Multiple other wild guess attempts (deep linking included because I wanted to keep testing app launching)
• Reviewed the crash reports and logs
• I investigated the code areas highlighted from logs and stack traces (services & WPLaunchActivity)
• Searched through Google and slack groups for any new information
• Reviewed the Google issue, which is still open, for updated information. Nothing from Google, but additional reports of crash are still coming in.
• A similar Google Issue indicates that it is a framework issue, that should have been fixed with the 10 release, but doesn’t appear that it was based additional developer reports. Google dev comment12 points to main thread blocking as a possible culprit.
• Poked around in NotificationsUpdateLogic. Nothing suspicious in there, but I did notice that the onResponse and onErrorResponse (Volley listeners) run on the main thread. I don’t suspect this is the cause of the issue, but would be interested in hearing others thoughts about moving the parsing and db work to a background thread.
• My gut says that if we can reliably recreate one of the crashes, then we’d be in a much better position to solve it.

[designsimply]

Events in the last 90d: 26,000
Users affected in the last 90d: 4,500
_{https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[jd-alexander]

So there's a high possibility this issue was fixed and will be released in a future Android release. I got this information from the Google Issue Tracker for Android The Google engineer did not state if there would be any fixes for devices currently facing this issue in the near future.

[designsimply]

Great note! I checked and there were no cases recorded in Sentry for this issue for Android 10 or 11, however, a lot of cases are still happening for devices running Android 9 and below. Not sure yet whether to close this or leave it open to see how it evolves over time.

Events in the last 90d: 32,000
Users affected in the last 90d: 3,600
_{WORDPRESS-ANDROID-2T: https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[designsimply]

Events in the last 90d: 35,000
Users affected in the last 90d: 3,500
_{WORDPRESS-ANDROID-2T: https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[designsimply]

We're still seeing a high number of our app users affected by this crash. Despite the update jd-alexander mentioned here noting that the Google issue at https://issuetracker.google.com/issues/62427912#comment75 says "the issue has been fixed and it will be available in future Android release" and despite the Sentry issue WORDPRESS-ANDROID-2T showing that we haven't seen any crashes reported so far for this issue in Android 11. Because of those things, I am keeping the issue open but lowering the priority. @bummytime I think this one is worth keeping an eye on and that if the number of users affected continues to remain high, we should re-visit the issue again in a few months to decide what to do with it outside of the scope of Groundskeeping or confirm if we are okay to close the issue.

[bummytime]

I think this one is worth keeping an eye on and that if the number of users affected continues to remain high, we should re-visit the issue again in a few months to decide what to do with it outside of the scope of Groundskeeping or confirm if we are okay to close the issue.

Agree @designsimply. Thank you 🙇

[designsimply]

Events in the last 90d: 40,000
Users affected in the last 90d: 3,400
Main culprit: android.os.Parcel in createException
_{WORDPRESS-ANDROID-2T: https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

Steady numbers which are still relatively high. Recommend escalating.

[designsimply]

Events in the last 90d: 42,000
Users affected in the last 90d: 3,400
Main culprit: android.os.Parcel in createException
_{WORDPRESS-ANDROID-2T: https://sentry.io/share/issue/88306a09ef304935983ff86b6ebc515c/}

[designsimply]

Looping back to check on how this crash is doing, I see that there aren't any cases recorded for Android 11 in the WORDPRESS-ANDROID-2T report in the Tags section. @jd-alexander does this mean there's nothing to do app-side and it's okay to close this case? I worry because even though there may be an OS-level fix, the crash still has relatively high numbers to other crashes we're tracking for our app and the instances are trending slightly up even (although 🤔 the number of users affected at 3,400 seems to be holding steady).

[jd-alexander]

Looping back to check on how this crash is doing, I see that there aren't any cases recorded for Android 11 in the WORDPRESS-ANDROID-2T report in the Tags section. @jd-alexander does this mean there's nothing to do app-side and it's okay to close this case? I worry because even though there may be an OS-level fix, the crash still has relatively high numbers to other crashes we're tracking for our app and the instances are trending slightly up even (although 🤔 the number of users affected at 3,400 seems to be holding steady).

@designsimply Unfortunately, there's still not much we can do from the app-side of things, so it's probably best to close this case for now and hope that the OS-level fix will resolve it. I am happy that the number of users affected is holding steady.

[designsimply]

I've discussed this internally and we decided to keep it open for now but add notes/labels to indicate we don't think it's actionable in the sense we cannot fix it from our side. We'll circle back to it in another future triage and see what's what at that point.

^{(internal reference/private channel: p1616519425037100-slack-GDQDH5HP1)}

[stale]

This issue has been marked as stale because:

• It has been inactive for the past year.
• It isn't in a project or a milestone.
• It hasn’t been labeled [Pri] Blocker, [Pri] High, or good first issue.

Please comment with an update if you believe this issue is still valid or if it can be closed. This issue will also be reviewed for validity and priority during regularly scheduled triage sessions.

[derekblank]

Closing as not actionable with no reports beyond Android 12, but we can continue to monitor and reopen if necessary. See also: pcdRpT-4vD-p2#comment-7487