radarlabs / react-native-radar

React Native module for Radar, the leading geofencing and location tracking platform
https://radar.com
Apache License 2.0
170 stars 32 forks source link

android.app.ForegroundServiceDidNotStartInTimeException - Context.startForegroundService() did not then call Service.startForeground() #230

Open Ruttmann opened 1 year ago

Ruttmann commented 1 year ago

We're getting consistent reports of the message above with crashes of the app. Based on crashlytics reports, it happens when we teardown Radar listeners. That's the snippet of code we use for that:

Radar.off('error');
Radar.off('clientLocation');
Radar.stopTracking();

The whole exception message is: android.app.ForegroundServiceDidNotStartInTimeException - Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{f2ad7fb u0 [omitted]/io.radar.sdk.RadarForegroundService}

Currently we use version 3.7.4, but this crash was also happening with version 3.4.1 (we updated the version a few days ago).

React Native version is 0.68.2

Our user base have Android devices that go from Android 8 to 12. This issue only happens on Android 12.

I researched this issue and noticed this seems to be an old bug ignored by Google. See this thread on Android Issue Tracker. Looking at react-native-radar lib, I couldn't find any calls to Context.startForegroundService(), so I'm confused.

We also have this issue thrown by an internal lib developed by our team, but there, I can see some calls to Context.startForegroundService().

Let me know if more info is needed. Thanks!

lmeier commented 1 year ago

Hey @Ruttmann, thanks for reporting! I'm looking into this & will report back next week with what I find.

lmeier commented 1 year ago

@Ruttmann upon first inspection, I'm wondering if there's some conflict between the Radar SDK and your native code for the foreground service. Essentially what I'm suspecting is that you're tracking with a FG service on Android, and then when you call Radar.stopTracking(), we try and end the FG service even though your other internal lib actually needs the FG service to still be running.

The other thing that jumps out, worth of investigation: do you call setForegroundServiceOptions at all? If so, mind sharing the code? This function was new in 3.4.1, and perhaps a misconfigured option dict could be a culprit.