You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 occur when the app's Battery Use set to 'Unrestricted.' They even occur with Pixel devices
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 foreground service running. That should significantly reduce the memory footprint.
But what would be the analogous thing to do on the iOS side?
Any suggestions on things to try to either fix or better understand the issue?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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 occur when the app's Battery Use set to 'Unrestricted.' They even occur with Pixel devices
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 foreground service running. That should significantly reduce the memory footprint.
But what would be the analogous thing to do on the iOS side?
Any suggestions on things to try to either fix or better understand the issue?
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions