[Help Wanted]: Background Tracking Suspension on Aggressive OEMs (Vivo, Xiaomi, etc.)

[jashwant-winishtech]

Required Reading

• Confirmed

Plugin Version

5.1.1

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

Vivo Y21 (V2111)

Device operating-systems(s)

Android 12 (Funtouch OS)

React Native / Expo version

0.79.2

What do you require assistance about?

While we are currently testing on a Vivo Y21, we are looking for guidance on solving this issue across the fragmented Android OEM landscape:

1. Universal Workaround: Is there a recommended, device-agnostic workaround to reliably keep the START_STICKY TrackingService alive across all aggressive OEMs (Vivo, Xiaomi, Oppo, OnePlus) when the app is swipe-killed, assuming standard Android battery optimizations are already disabled?
2. UX for Non-Technical Users: Our field users are generally non-technical and struggle to navigate deep into custom OS settings (like Vivo's "Background power consumption management" or Xiaomi's "Auto-Start"). Is there a recommended strategy, intent string, or built-in SDK method we can use to launch them directly into the correct Auto-Start screen for their specific manufacturer to minimize manual steps?
   Currently, our attempt to use BackgroundGeolocation.deviceSettings.showPowerManager() fails on this specific Vivo device with: ℹ️ Failed to find POWER_MANAGER scrreen for device vivo V2111@12.

Expected Behavior

When the app is swiped away (terminated) and the device moves past the distanceFilter, the OS should wake up the TrackingService, boot the Headless Task, and successfully POST the locations to the configured backend via autoSync: true.

Actual Behavior

There are massive gaps in the TSLocationManager

github_issue_report.txt

logs. When the app is swiped away and the phone is disconnected from the development machine (walking outside), no locations are recorded or sent to the backend.

Upon returning and dumping the logcat buffer, there is a total blackout in the logs during the duration of the walk. The logs only resume with [TSConfig print] when the app is manually reopened by the user.

[Optional] Plugin Code and/or Config

{
  reset: false,
  desiredAccuracy: BackgroundGeolocation.DesiredAccuracy.High,
  distanceFilter: 10,
  stationaryRadius: 50,
  stopTimeout: 5,
  stopOnStationary: false,
  pausesLocationUpdatesAutomatically: false,
  locationAuthorizationRequest: "Always",
  showsBackgroundLocationIndicator: true,
  disableElasticity: true,
  elasticityMultiplier: 1,
  startOnBoot: true,
  stopOnTerminate: false,
  enableHeadless: true,
  heartbeatInterval: 120,
  preventSuspend: true,
  http: {
    url: "https://api.leadsforce.app/location",
    method: "POST",
    autoSync: true,
    autoSyncThreshold: 1,
    batchSync: false,
    maxRecordsToPersist: 500,
  },
  persistence: {
    maxDaysToPersist: 3,
    maxRecordsToPersist: 500,
    persistMode: BackgroundGeolocation.PersistMode.Location,
    disableProviderChangeRecord: true,
  }
}

[Optional] Relevant log output

05-11 11:25:47.227 20170 20266 I TSLocationManager:   🔵  Response: 200
05-11 11:25:47.230 20170 20170 D TSLocationManager: [HeadlessEventTx fire] 🛜 💀⚡️ http
05-11 11:25:47.231 20170 20266 D TSLocationManager:   ✅  DESTROY: cfd427bb-0f38-4872-b752-1c32c2e93287
05-11 11:25:47.232 20170 20170 D TSLocationManager: [HeadlessTask onHeadlessEvent] 💀  event: http
05-11 11:25:47.366 20170 20170 D TSLocationManager:   🎾  start [TrackingService  startId: 2, eventCount: 1]

05-11 11:58:00.666  3700  3700 D TSLocationManager: [LifecycleManager c] 
05-11 11:58:09.882  3700  3700 D TSLocationManager: [HeadlessTaskManager onHeadlessJsTaskFinish]

... [ MASSIVE 30-MINUTE SILENCE WHILE USER IS WALKING OUTSIDE ] ...

05-11 12:29:18.269 27933 27986 I TSLocationManager:     "persistMode": 1,
05-11 12:29:18.269 27933 27986 I TSLocationManager:     "timestampFormat": "iso"
05-11 12:29:18.271 27933 27986 I TSLocationManager: [TSConfig print] 
05-11 12:29:18.271 27933 27986 I TSLocationManager: ╔═════════════════════════════════════════════
05-11 12:29:18.271 27933 27986 I TSLocationManager: ║ DEVICE SENSORS
05-11 12:29:18.271 27933 27986 I TSLocationManager: ╠═════════════════════════════════════════════

[christocracy]

see https://dontkillmyapp.com

[jashwant-winishtech]

Thanks for the response.

I am familiar with dontkillmyapp, and we have already implemented OEM-specific settings guidance using BackgroundGeolocation.deviceSettings / power-management flows. On devices where the correct vendor screen is available, this does improve reliability.

However, the challenge we are facing is more practical and product-oriented.

This is a workforce/employee-tracking application where many users are not technically literate enough to navigate multiple OEM-specific battery-management screens manually. The behavior also varies significantly across devices and OS versions—even within the same OEM family (eg. Vivo Android 11 vs 12, Samsung variants, Xiaomi/MIUI differences, etc).

For example:

• some devices require Battery → Unrestricted
• some require Auto Start
• some require High background power consumption
• some require Don't optimize
• and on certain devices the SDK is unable to resolve the OEM settings intent (showPowerManager() fails to find the screen)

In our case, once the appropriate Vivo settings were manually enabled, tracking became stable again, which strongly suggests OEM process restrictions are the root cause.

The difficulty is that this becomes extremely hard to operationalize at scale for non-technical users, especially when settings differ per device and Android version.

I understand this may ultimately be outside SDK control, but I wanted to ask:

1. Are there any additional RNBG configuration recommendations specifically for aggressive OEMs beyond the documented settings?
2. Is there any maintained/internal mapping for newer OEM power-manager intents (particularly Vivo/Funtouch Android 12+)?
3. Have you seen any patterns or best practices from production apps using RNBG for workforce tracking on these devices?

Appreciate the guidance.

[christocracy]

See API docs DeviceSettings:

https://docs.transistorsoft.com/react-native/DeviceSettings/