Suggested “Full Tracking but Battery-Friendly” profile

Think of this as your “FullTracking_LowRouteDetail” template for start().

These are starting values – you can tweak later by field-testing different templates.

Core movement / accuracy

Activity / motion & lifecycle

Things to avoid if you care about battery

• Heartbeat: don’t run heartbeatInterval every 1–2 minutes. If you must use heartbeat for daily device status, keep it to 15–30 minutes or even schedule it for specific times only.

• preventSuspend: true unless you really need ultra-fast stationary-exit on iOS; it keeps the app much more active. Transistor Software

• Very small distanceFilter (e.g. 5–10 m) + DESIRED_ACCURACY_HIGH: that’s when you get “Google Maps level” tracking and big battery cost.

3. How to use start() without storing travel routes

There are two layers of data to think about:

1. On the device (inside the SDK)
   The plugin always keeps some locations in its own SQLite DB until they’re synced or purged. That’s fine – it’s local to the phone. You can control retention with things like maxDaysToPersist. npmjs.com

2. On your backend (your ClickTime portal)
   This is where you care about not storing routes.

Option A – Easiest: don’t use the plugin’s HTTP sync at all

Do not set:

• url

• autoSync

• batchSync

• etc.

Instead:

• Listen for geofence events and send only clock data:

BackgroundGeolocation.onGeofence(geoEvent => {
  const { identifier, action, location } = geoEvent;
  // identifier = job site ID; action = "ENTER" or "EXIT"
  // location is available if you want it for *this* event only.

  // 1) Decide if this should clock the employee in or out.
  // 2) Call your own API: /clock with employeeId, jobSiteId, action, timestamp.
  //    You DON'T send every intermediate location – just this event.
});

• You can ignore the continuous onLocation events completely if all you care about is geofence enter / exit.

Result:

• Phone may internally record locations for tracking & geofencing logic, but

• your server never sees the route – only clock-in / clock-out events.

If you’re worried about internal DB growth, periodically:

• use a low maxDaysToPersist (e.g. 1–3 days), or

• call BackgroundGeolocation.destroyLocations() at a safe time (e.g. once your daily payroll export is done).

Geofence events (onGeofence with ENTER / EXIT) are not driven by locationUpdateInterval. They’re driven by:

• The OS geofencing API + Transistorsoft’s geofencing logic.

Conceptually:

• Geofences are “watched” at the OS level.

• When the device crosses a geofence boundary:

  • The OS / SDK generates a geofence event immediately (subject to normal GPS timing/drift).

  • The plugin calls your onGeofence callback.

  • That entry/exit is independent of the scheduled “tracking updates” from locationUpdateInterval.

So:

• Setting locationUpdateInterval = 3 minutes

  • May reduce how often you receive regular tracking locations (onLocation),

  • But does not intentionally wait 3 minutes to deliver a geofence ENTER or EXIT.