android.app.RemoteServiceException crash reports on Play Store

[misaochan]

This crash has 80 reports on the Play Store, and is our highest crash besides #1876 . Unfortunately, I have no idea what is causing it because the stack trace below is all we have. :/

android.app.RemoteServiceException: 
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1867)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loop (Looper.java:164)
  at android.app.ActivityThread.main (ActivityThread.java:6753)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:482)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:807)

[misaochan]

Extra info: This crash only started on 21 Aug, which is when 2.8.2 was rolled out to production. 100% of reports are from v2.8.2. Bad luck that we never saw it in beta I guess.

Android version:
Android 8.1 | 123 | 69.5%
28 | 54 | 30.5%

Devices:
Pixel (sailfish) | 38 | 21.5%
Nokia 6.1 (PL2_sprout) | 21 | 11.9%
OnePlus 6 (OnePlus6) | 17 | 9.6%
Mi A1 (tissot_sprout) | 15 | 8.5%
Others | 86 | 48.6%

[misaochan]

This is really strange, the only 2 PRs for 2.8.2 were 4c476e7 and 11c3772 . I really wonder where the issue lies. Do we want to try removing Traceur and seeing if that works? @neslihanturan @maskaravivek

[neslihanturan]

Removing other commit wouldn't be that easy, because it already solves a visible problem. Fastest solution would be removing Traceur indeed.

[maskaravivek]

Traceur only makes the logs more verbose. Without Traceur these logs would not be decipherable. Can we check the number of active installations for 2.8.1 and 2.8.0. 2.8.2 was released quickly after 2.8.1/2.8.0 so many people might not have used 2.8.0. Also was 2.8.0/2.8.1 ever pushed to prod or was it just pushed to beta channel?

[misaochan]

@maskaravivek Hmm, good point. Unfortunately the Play console does not give me active installs for every version, we can only see the total number of install events for every version.

2.8.1 was released to beta on 19 Aug and prod on 20 Aug, so it is indeed possible that 2.8.1 was not tested substantially. It has 594 install events.

2.8.0 could potentially be the culprit as it was never released to prod. However, it was released to beta on 8 Aug. Could just be bad luck that it never showed up on beta though despite having 600+ beta testers and 2 weeks of availability. :/

That is actually really bad news because it widens the search substantially, and the stack trace itself provides almost no useful information.

[neslihanturan]

Maybe this crash was already there before Traceur too, but after we started to get this log?

[maskaravivek]

I just came across a Reddit thread and it seems that Traceur could cause some crashes in edge scenarios.

Maybe we could revert it for now. The same thread suggests the usage of RxJava2Debug but we can consider using it later.

@dbrant Do you have any suggestions here? Basically we want verbose stacktraces for RxJava exceptions.

[misaochan]

OK, I'll set Traceur to only work in debug perhaps? And then we can reenable later or switch to another one?

[ashishkumar468]

Can someone confirm, if this happening only post Nougat or do we have instances pre oreo as well? (Android has updated the way the services are to be handled starting from oreo) and similar crashes are thrown in such scenarios.

[misaochan]

@ashishkumar0207 Thanks for the insight. 100% of the cases are from Android 8.1 and above, so only Oreo. Is there a way to find out which line of code is triggering this crash? The stack trace is supremely unhelpful. :/

[ashishkumar468]

@misaochan I will try to reproduce it and if Its related to what I am suspecting, I should be able to, will update if something comes up. Meanwhile, it will be great if someone else can also try to reproduce it in oreo devices.