CODEWITHSUNDEEP
androidiosreact-nativegeolocationbackground-process
Brad Stiff
Brad Stiff

Reputation: 79

Why is my React Native app sometimes terminated in the background while tracking location - RN 0.71.6

My location tracking app works perfectly 88% of the time, capable of recording a full day of continuous location data with minimal battery drain.

But about 12% of the time, the app is terminated by the OS while working in the background. There are no obvious patterns regarding when the app gets terminated, but it is usually at least an hour or so into the tracking session.

This happens on both iOS and Android, and the percentages are comparable.

Android

Android uses a custom sticky foreground service with type: location. The app requires the Location: When In Use permission.

Significant App Exit Codes are as follows:

Most of the REASON_OTHER cases have a description like 'Too many empty', 'Empty #34' or 'Empty for too long.' I'm not really sure what this means.

There is no obvious pattern to the terminations. They even occur with Pixel devices, with the app's Battery Use set to 'Unrestricted.'

iOS

iOS uses a custom native module. The location background mode is enabled for the project. The app requires the Location: When In Use permission.

XCode Organizer shows over 90% of the terminations are due to 'System Pressure' which I believe is actually Memory Pressure.

I realize that requesting Location: Always permission and using the Significant Location service could help with restarting the app, but I really don't want to request that permission.

Seems like a memory issue

My instinct tells me the app is holding onto too much memory in the background. The problem is, I don't know of a way to decrease the memory footprint. A Hello World react native app uses about 200MB. My app uses around 300MB.

I am wondering if finishing the main activity on the Android side would effectively shut down the RN portion of the app, leaving just the native service running. That should significantly reduce the memory footprint.

But what would be the analogous thing to do on the iOS side?

Anyone?

Does anyone have any suggestions on things to try to either fix or better understand the issue?

Thank you.

Upvotes: 0

Views: 1631

Answers (1)

Ehtisham Ali Shah
Ehtisham Ali Shah

Reputation: 113

I have previously worked on a RN app with this same issue. OS closing our app was one of the annoying issues. In our particular case, after alot of discussions and testing RN solutions we were unable to fix it completely. So in the end we ended up using native solutions for both Android and iOS. Below I will share how we resolved this issue using native solutions.

For Android: Since newer Android versions have many limitations on getting location in the background, We used WorkManager class with scheduled requests since it was greatly working for our use case instead of a foreground service running 24/7 and AlarmManager as we didn't want to drain our resources e.g. battery,CPU and RAM. This link can be a great start if you want to implement native solution for Android.

For iOS: Unlike Android, iOS has too much limitations and OS can stop our service anytime. We used "Always Authorization" for the app permission and "significant location change" strategy. We were unable to replicate the WorkManager Schedule Requests like in Android, to be executed at a specific time. This link can be a starting point for implementing native solution for iOS.

In case if you need some other data for the location like user data from the RN code, you can get AsyncStorage db instance in native Android and iOS code.

Upvotes: 1

Related Questions