Skip to main content

Platform limitations

Background location is controlled by the operating system, not by any library. These are the rules that apply to every background location solution on Android and iOS, and exactly how Background Location Pro behaves under each. Knowing them up front saves you from surprises in production.

Android​

Android force-stop​

If the user taps Force stop in Settings > Apps, Android puts the app in a "stopped" state:

  • All services, alarms and scheduled jobs are cancelled.
  • The app receives no broadcasts, including boot completed, until the user opens it again.

Behavior: tracking stops and cannot restart on its own. Pending points stay on the device. When the user next opens the app, tracking resumes if it was still desired, and the queue uploads.

No library can work around this. It is a deliberate Android safeguard. Swiping the app away from recents is not a force-stop, and tracking continues in that case.

Foreground notification is mandatory​

Continuous background location on Android 8 and newer requires a foreground service, which shows a persistent notification. On Android 13 and newer, if the user denies notification permission, the service can still run but the notification is hidden. Some vendor ROMs then treat the app as a background app and kill it sooner.

Starting from the background​

Android 12 and newer do not allow a location foreground service to start while the app is in the background. Call startTracking() from the foreground, for example after a button press. Recovery after a reboot or kill is handled by the package and is unaffected.

Background location permission​

  • Android 11 and newer only grant Allow all the time from the Settings page, not from an in-app prompt.
  • Users can downgrade to Only while using the app at any time. Tracking then stops with [permission_denied].
  • Android may auto-reset permissions for apps unused for months.

Vendor battery managers​

Xiaomi, Huawei, Honor, OnePlus, Oppo, Vivo and some Samsung builds add their own background killers on top of Android. The package uses every standard mechanism to survive, but some ROMs require the user to whitelist the app manually (autostart, no battery restrictions). Use requestIgnoreBatteryOptimizations() and link to dontkillmyapp.com.

Reboot​

After a reboot, tracking resumes automatically while it is desired, including before the first unlock on supported devices. Exception: an app that was force-stopped before the reboot stays stopped until it is opened.

Exact alarms​

On Android 14 and newer, exact alarm permission is off by default for most apps. Without it, recovery still works but may be delayed. Check exactAlarmsAllowed and use openExactAlarmSettings().

iOS​

Always permission is required for real background tracking​

AuthorizationBackground behavior
alwaysContinues in the background, relaunches after the app is killed, resumes after reboot.
whenInUseContinues briefly after backgrounding, with the blue status bar indicator. Not relaunched after kill.

iOS may grant Always provisionally and later show the user a reminder that offers to downgrade it. Read authorization regularly.

Relaunch after the app is killed​

When an app with Always permission is terminated, iOS relaunches it in the background when the device moves significantly, typically a few hundred meters. That means:

  • A stationary device is not relaunched until it moves. This is normal and saves battery.
  • After relaunch, precise tracking resumes within seconds.

User swipe-kill​

If the user swipes the app away, iOS stops continuous updates. Background Location Pro is relaunched on the next significant movement, as described above. Some points between the swipe and the relaunch may be coarser or missing, depending on how far the device travelled.

Reboot​

After a reboot, iOS relaunches the app on significant movement, but only after the user unlocks the device once. Until then, protected data is not accessible, and location apps are not relaunched.

Background App Refresh and Low Power Mode​

  • With Background App Refresh disabled, the watchdog's periodic background task does not run. Location-based relaunch still works.
  • Low Power Mode makes iOS defer background work more aggressively.

Both are exposed through exactAlarmsAllowed and batteryUnrestricted in getStatus().

Precise Location​

Users can turn off Precise Location per app. Points are then accurate only to a few kilometers. Check preciseLocation.

Background scheduling is best effort​

iOS decides when background tasks run based on usage patterns, battery and network. Uploads while the app is in the background are handed to the system, which may batch or delay them. Points are never lost. They stay pending until acknowledged.

Both platforms​

  • Battery: continuous GPS costs battery on any device. Use adaptive_low_power for all-day tracking.
  • Indoor accuracy: GPS accuracy degrades indoors and in dense cities. Use LocationEvent.accuracy to filter.
  • Store review: both stores require a clear user-facing reason for background location, a prominent disclosure and accurate privacy declarations.
  • JavaScript is not guaranteed to run in the background. Tracking and syncing happen natively, so do not rely on JS listeners for delivery. Use your backend as the source of truth.