1

The SE Android app (v1.0.85 beta) crashes if I dismiss the inbox notification from web. It also fails the automatic notification dismissal on the Android.

Steps to reproduce:

  1. Receive a notification (e.g. comment on your post, comment reply, chat ping, etc).
  2. Dismiss the notification from the web (i.e. by opening and closing the inbox)
  3. The app suddenly crashes (even when it's not active), showing a standard crash dialog to report/close.

Other notes:

  • Dismissing the Android notification doesn't affect this issue; the app still crashes.
  • When the app crashes, the Android notification isn't dismissed (either the cause/side-effect of this bug).

In case it's relevant, this is on Nexus 5 running Android 6.0.1 Marshmallow.

LogCat

04-04 08:56:30.776: I/GCM(2043): GCM message com.stackexchange.marvin 0:1459731391706656%553e5aedf9fd7ecd
04-04 08:56:31.094: E/AndroidRuntime(16021): Process: com.stackexchange.marvin, PID: 16021
04-04 08:56:31.094: E/AndroidRuntime(16021):    at com.stackexchange.marvin.core.inbox.GlobalInbox.setUnreadCount(GlobalInbox.java:35)
04-04 08:56:31.094: E/AndroidRuntime(16021):    at com.stackexchange.marvin.GCMIntentService.handleMessage(GCMIntentService.java:92)
04-04 08:56:31.094: E/AndroidRuntime(16021):    at com.stackexchange.marvin.GCMIntentService.onHandleIntent(GCMIntentService.java:66)
04-04 08:56:45.872: I/ActivityManager(815): Waited long enough for: ServiceRecord{c0bff52 u0 com.stackexchange.marvin/.GCMIntentService}
04-04 08:57:12.228: I/ActivityManager(815): Process com.stackexchange.marvin (pid 16021) has died
04-04 08:57:12.229: W/ActivityManager(815): Scheduling restart of crashed service com.stackexchange.marvin/.GCMIntentService in 1000ms
2
  • Can you confirm this has been fixed? Since there was never any 1.0.86 version, I'm not sure. Commented Oct 10, 2016 at 17:43
  • @ShadowWizard somehow, it's already fixed... Commented Oct 10, 2016 at 18:52

1 Answer 1

2

This will be fixed in 1.0.86.

When the unread count is cleared, the app gets the message via an intent service (not the main queue). It then resets the inbox count and uses otto to pass the message to the running activity (if any). I knew otto would only call subscribers from the main queue, but I didn't realize it did this by crashing when posting a message from a background queue. Now the inbox will be updated in a handler on the main looper. We were already doing this for new notifications.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .