Uncaught Exception: Context.startForegroundService() did not then call Service.startForeground()

[UnSket]

Your Environment

• Plugin version: 3.0.9
• Platform: Android
• OS version: 8-9
• Device manufacturer / model: Huawei Y6 Prime
• React Native version (react-native -v): 0.59.9
• Plugin config

{
    desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH, // Use GPS, WiFi and Cellular for geolocation
    distanceFilter: 10, // meters to move before update event fires
    fastestLocationUpdateInterval: 1000, // if another app is using location, accept updates every N ms
    locationUpdateInterval: 10000, // actively request location every N ms
    heartbeatInterval: 60, // Send 'heartbeat' events every 60 seconds
    debug: __DEV__, // for debug sounds
    logLevel: __DEV__
      ? BackgroundGeolocation.LOG_LEVEL_VERBOSE
      : BackgroundGeolocation.LOG_LEVEL_DEBUG,
    stopOnTerminate: !enableTracking, // Stop plugin when app is closed and tracking is OFF (e.g. when logged out)
    startOnBoot: enableTracking, // Start on Android boot if tracking is ON
    foregroundService: true, // show in notification bar, keep service alive as much as possible
    notificationTitle: 'Яндекс.Курьер',
    notificationText: 'Использует GPS',
    maxDaysToPersist: 3,
    url: enableTracking
      ? `${backend_url}`
      : null,
    autoSync: true,
    batchSync: true,
    maxBatchSize: 100, // Max locations size in request
    httpRootProperty: 'positions',
    locationTemplate:
      '{ "accuracy": <%= accuracy %>, "latitude":<%= latitude %>, "longitude":<%= longitude %>, "time": "<%= timestamp %>" }',
    enableHeadless: true,
  }

Expected Behavior

Do not see errors like this

Actual Behavior

have a lot of errors with this text. Some examples:
Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{c870e9e u0 com.yandex.courier/com.transistorsoft.locationmanager.service.HeartbeatService}

Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{44a549e u0 com.yandex.courier/com.transistorsoft.locationmanager.service.GeofencingService}

Context.startForegroundService() did not then call Service.startForeground()

Context

the device on which it most often occurs - Huawei Y6 Prime
but have same issue on another devices like samsung, sony, xiaomi...

It is also known that the problem can occur both in the background and foreground

Debug logs

Logs

[649697145496 (1).txt](https://github.com/transistorsoft/react-native-background-geolocation/files/3534158/649697145496.1.txt)

There is logs inside file. You could find error by search '‼️ Uncaught Exception: Context.startForegroundService() did not then call Service.startForeground()'

PASTE_YOUR_LOGS_HERE

[christocracy]

It’s a well know issue reported by many Android developers. See the CHANGELOG for 3.2.0.

Also see this: https://issuetracker.google.com/issues/76112072

No, I don’t know any way around it yet,

[christocracy]

See this comment

1. If you have a foreground service that restarts itself (START_STICKY) and the application is killing in the background by the OS (due to low memory, low battery or other reasons). The process will be recreated again, but you will get the "did not then call Service.startForeground" if your Application.onCreate() hasn't finished within about 4.8 seconds. Your Service onCreate/onStartCommand will be only called after Application.onCreate(), so you have no chance to promote the service into foreground. You must make sure that your Application.onCreate will never take more than 5 seconds to finish.
   How to test: Add a Thread.sleep(5000) into your application.onCreate(), launch the app, put it into background (hit HOME) and kill the process from AS. Now wait for the Service/Process to relaunch and observe crash (100% reproduce rate).
   How to fix: profile your application.onCreate and make sure it's quick (or delay work after onCreate).

2. You can also kill the process while application.onCreate is in execution and it will trigger the same error, but this should not happen during regular use.

[UnSket]

Ok, thank you

[WarrenBuffering]

Is this being actively worked on for a future release? We're seeing the same issue, didn't know if there was a way we could help.

[christocracy]

@andrewtelkamp Yes. Search the CHANGELOG for "Context.startForegroundService".

[christocracy]

After deploying the latest version of the plugin with the SampleApp to Play Store, I'm only seeing this on the React Native version (nothing for Cordova or Flutter versions). The stacktrace always points to com.airbnb.android.react.maps:

It seems to be taking too long to load SharedPreferences:

at android.app.SharedPreferencesImpl.awaitLoadedLocked (SharedPreferencesImpl.java:248)
  at android.app.SharedPreferencesImpl.getBoolean (SharedPreferencesImpl.java:311)
- locked <0x0460ae96> (a java.lang.Object)

[mikehardy]

That's interesting to me - good observation. If SharedPreference loading on boot takes too long this may be a common issue as I'm aware of react-native-permissions 2.0 pre-release using a similar solution to tackle a thorny issue of "what request / response state am I in?" for iOS permissions (not sure if it is used on android code as well) and I'm contemplating a SharedPreference implementation for unique ids in react-native-device-info. I hadn't thought of it as a performance issue, so that's an interesting dimension since unique ids from device info are one the things you'd really want in you location points...

[christocracy]

There's nothing wrong with using SharedPreferences for small amounts of data.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and I will leave this open.

[christocracy]

I'm seeing much more robust performance with latest version 3.3.2. After 1 week, no crashes / ANR for all 3 of versions of the SampleApp (Flutter, React Native, Cordova) with about 500 active users between them.

[gtaylor44]

We are on version 3.9.3 and seeing this issue and nothing in CHANGELOG since 3.3.0 - 2019-10-17

[christocracy]

@gtaylor44 Correct. All the plugin's source-code has been cleaned of faults. Any other instances of this are due to your own code / plugins.

See #976 and enable StrictMode to shine the light on other modules that are blocking the main thread in your app, preventing BackgroundGeolocation from calling Context.startForeground in time.