MindscapeHQ / raygun4android

Android crash reporting provider for Raygun
https://raygun.com
MIT License
21 stars 14 forks source link

Raygun RUM process causes RuntimeException #79

Open Matty3Run opened 3 years ago

Matty3Run commented 3 years ago

I added Raygun for my app, following the instructions provided by the official documentation. After roll out to production, I'm receiving numerous crashes in Firebase Crashlytics, caused by the RUM process of Raygun added in the AndroidManifest.

The Stacktrace of the exception is:

Fatal Exception: java.lang.RuntimeException
Using WebView from more than one process at once with the same data directory is not supported. https://crbug.com/558377 : 
Current process com.example.package:rumpostservice (pid 1479), lock owner com.example.package (pid 30096)

Obviously, "com.example.package" is not the real package name of the app.

Can anyone help me with this issue?

TheRealAgentK commented 3 years ago

Hey @Matty3Run, can you provide some additional information how you're using WebView in your app and share some code?

Is it essentially a web-app where the WebView holds all/nearly all of your app? Or do you have individual web views rendering some bits of HTML contents here and there?

There's no obvious way how rumpostservice should be even able to deal with your or any other WebView.

What you could try until I'm able to reproduce this, would be to set a different data directory per process:

https://developer.android.com/reference/android/webkit/WebView.html#setDataDirectorySuffix(java.lang.String)

Matty3Run commented 3 years ago

Thank you for your answer. Unfortunately, I cannot reproduce the crash in my app for now, but i constantly receive crashes on the Firebase console (20 per day, with 10.000 active users).

I already tried to set WebView.setDataDirectorySuffix for devices with Android >= 9.0 in the Application class, unfortunately it didn't worked, because now i receive a IllegalStateException when i try to set the suffix, saying "Can't set data directory suffix: WebView already initialized".

The app is not a web-app, it's a standard app, with only two screens using a WebView, in the "help" section and in the "payment" section. I tried to reproduce the crash opening the WebView fragments, but nothing happened.

Some details about the Raygun implementation in my app:

<service android:name="com.raygun.raygun4android.services.RUMPostService" android:exported="false" android:permission="android.permission.BIND_JOB_SERVICE" android:process=":rumpostservice" />

- Finally, i added the requested meta-data, as stated in the documentation

<meta-data android:name="com.raygun.raygun4android.apikey" android:value="@string/raygun_apikey" />



That's all, i didn't use any other feature of Raygun at the moment.
Tell me if you need some more information, and thanks again for the support.
Matty3Run commented 2 years ago

Hi, are there some news regarding this issue? I still haven't find a solution, so I can't use Raygun in my Android application at the moment.

TheRealAgentK commented 2 years ago

I noticed there's been some additional activity in the Chrominum bug tracker for this recently.

https://crbug.com/558377

Interesting are in particular comments 225 and 226.

225 essentially says: try to not run multiple processes when using WebViews and running into this issue.

So what you could try is to change:

<service android:name="com.raygun.raygun4android.services.RUMPostService"
      android:exported="false"
      android:permission="android.permission.BIND_JOB_SERVICE"
      android:process=":rumpostservice" />

to

<service android:name="com.raygun.raygun4android.services.RUMPostService"
      android:exported="false"
      android:permission="android.permission.BIND_JOB_SERVICE" />

and see if that improves the situation.

Note: In #74 I advised a user against doing this specifically for crash reporting, because having the CR service run in its own process has a lot of benefits due to the app process and the VM potentially being shut down because of a crash. That situation is less of a concern for a RUM Post.

The interesting bit in comment 226 is that people have seen the prevalence of this error dropping massively since June and attribute it to Samsung having fixed some problems in the platform. I don't know what the distribution of Android versions and vendor platforms you've seen when encountering the issue, but that's another thing you could try: Is it still even happening to the level of prevalence you've seen before if you put the RUM provider back in.