[Bug]: Android SDK does not drops 3s location fixes and locks activity state after stationary period (iOS works as expected)

[soft-dev-akshay]

Required Reading

• Confirmed

SDK Version

4.1.8

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

Google Pixel-5, Google Pixel-7, Google Pixel-9, Samsung

Device operating-systems(s)

12+

Build tooling versions

Android Gradle Plugin Version : 9.2.1, Gradle Version: 9.6.1

What happened?

Core Issues Summary
Inconsistent 3–5 Second Location Delivery on Android:
Our app logic relies on the SDK to emit a location update every 3 to 5 seconds so we can aggregate and persist a record every 10 seconds (~6 records per minute / 60 records per 10 minutes). On Android, the SDK skips intervals and drops location fixes, producing 15–30+ second gaps.

Activity Recognition Freezes in Previous State on Android:
When an Android device halts for longer than 3 minutes, the SDK enters the stationary state. Upon moving again (e.g., riding a bike at 30–40 km/h), the SDK continues emitting stationary/still as the active triggerActivity instead of transitioning. Conversely, when stopping, it stays locked on in_vehicle. The activity state machine remains frozen until we manually re-initialize the SDK (BGGeo.instance.ready).

Works Correctly on iOS:
Using our iOS configuration, iOS transitions activity states and streams locations dynamically as expected. The bug is isolated to the Android SDK implementation.

Questions
How do we completely disable elasticity/filters on Android so location fixes strictly fire every 3 seconds without dropping updates?

Why does the Android Activity Recognition engine freeze in stationary (or transit mode) after 3+ minute stops, requiring a re-initialization call (ready()) to resume state transitions?

iOS — Swift Config / Code

/*iOS is working correctly, pasted for ref. **/
bgGeo.ready { config in
    // Location
    config.geolocation.desiredAccuracy = kCLLocationAccuracyBest
    config.geolocation.distanceFilter = 10
    config.geolocation.pausesLocationUpdatesAutomatically = false
    config.geolocation.filter.useKalman = true
    config.geolocation.filter.kalmanProfile = .default
    
    // Activity
    config.activity.disableStopDetection = false
    config.activity.stopOnStationary = true
    
    // App
    config.app.stopOnTerminate = false
    config.app.startOnBoot = true
    
    // Logging
    config.logger.debug = false
    config.logger.logLevel = .off
}

Android — Kotlin Config / Code

BGGeo.instance.ready {
    // GEOLOCATION CONFIGURATION
    geolocation.desiredAccuracy = DesiredAccuracy.HIGH
    geolocation.distanceFilter = 0f                     /**Not to rely on distance instead get from locationUpdateInterval*/
    geolocation.disableElasticity = true                /**keep get location even fast speed*/
    geolocation.elasticityMultiplier = 0f 
    geolocation.locationUpdateInterval = 3_000
    geolocation.fastestLocationUpdateInterval = 3_000
    geolocation.stopTimeout = 3                     /**can be ignore as stopOnStationary is false*/
    geolocation.stationaryRadius = 25               
    geolocation.locationAuthorizationRequest = LocationAuthorizationRequest.ALWAYS
    geolocation.allowIdenticalLocations = true  
    geolocation.filter.policy = LocationFilterPolicy.Adjust
    geolocation.filter.useKalman = true
    geolocation.filter.kalmanProfile = KalmanProfile.Default

    // ACTIVITY RECOGNITION CONFIGURATION
    activity.activityRecognitionInterval = 3000.0  /**to get trigger activity on every 3 second*/
    activity.stopOnStationary = false  /* lets keep getting even stationary */
    activity.disableMotionActivityUpdates = false
    activity.disableStopDetection = false
    activity.motionTriggerDelay = 0
    activity.minimumActivityRecognitionConfidence = 75
    activity.triggerActivities = "in_vehicle, on_bicycle, running, on_foot, walking"
}

Relevant log output

[christocracy]

config.logger.logLevel = .off

Please provide logs with .verbose.

See api docs "emailLog" to learn how to fetch the SDK log file.

[christocracy]

config.activity.stopOnStationary = true

Are you sure you want to do that on iOS?

That config option means "call the .stop() method when the device next enters the stationary state" (turns the power button of the SDK OFF). No more tracking will occur ever until you call .start() again.

[soft-dev-akshay]

Thank you for reviewing the issue, @christocracy .

I have attached the requested .verbose SDK log txt files along with route visualization images. Also, please note that a valid purchased license key was applied prior to testing.

Clarification on iOS Configuration

The iOS configuration was shared strictly as a baseline reference. On iOS, the behavior works as expected.

Thank you for highlighting config.activity.stopOnStationary = true.

Our main issue is specifically occurring on Android.

Core Issues with Android Activity Recognition & Tracking

1. Activity State Freezing During/After Stops:

When a vehicle stops for a short period, the SDK continues emitting in_vehicle as the triggerActivity.
When the SDK eventually detects a stationary / still state and the user resumes movement (e.g., accelerating on a bike), the SDK stays locked in stationary / still for 5 to 10 minutes instead of transitioning back to dynamic motion.

2. Delayed Motion Transitions:

The Android SDK does not update its triggerActivity state dynamically or promptly based on physical sensor changes. It holds onto the last remembered state for extended periods.

3. Inconsistent Update Intervals:

Our application requirement is to receive background updates (location and sensor/triggerActivity data) consistently every 3 to 5 seconds.
We then aggregate these 3–5 second pings in memory and commit a record permanently every 10 seconds (~6 records per minute).
Currently, the Android SDK skips intervals and drops fixes, resulting in sparse data stream gaps (15–30+ seconds apart).

Request & Updated Android Configuration
Could you review our updated Android configuration below and advise on the correct parameters to enforce continuous 3–5 second location and activity events without the state machine getting stuck in stationary?

[sdk_logs_file_1_google_pixel_9.txt](https://github.com/user-attachments/files/31041550/sdk_logs_file_1_google_pixel_9.txt) [sdk_logs_file_1_google_samsung_s23.txt](https://github.com/user-attachments/files/31041551/sdk_logs_file_1_google_samsung_s23.txt) [sdk_logs_file_2_google_pixel_3.txt](https://github.com/user-attachments/files/31041553/sdk_logs_file_2_google_pixel_3.txt) [sdk_logs_file_2_google_pixel_5.txt](https://github.com/user-attachments/files/31041552/sdk_logs_file_2_google_pixel_5.txt)

BGGeo.instance.ready {

//TODO: Update Configuration once all static data validated | sdkConfigData

            // ────────────────────────────────────────────────
            // GEOLOCATION – high accuracy + dense updates
            // ────────────────────────────────────────────────
            geolocation.desiredAccuracy = DesiredAccuracy.HIGH          // GPS required

            // Option A (recommended, closer to iOS behaviour)
            geolocation.distanceFilter = 0f                /** min dist must move hr for new loc, 10 meter*/
            geolocation.disableElasticity = true            /** CRITICAL – stop automatic scaling at high speed **/
            geolocation.elasticityMultiplier = 1.0f


            // Option B (if I want ~every 3 s even when almost stationary)
             geolocation.locationUpdateInterval = 3000L
             geolocation.fastestLocationUpdateInterval = 1000L

            geolocation.stopTimeout = 3                      /** 3 minutes **/
            geolocation.stationaryRadius = 25                /** Min 25 - 1000 meter**/
            geolocation.allowIdenticalLocations = true  /**record all location except previous identical*/
            geolocation.locationAuthorizationRequest = LocationAuthorizationRequest.ALWAYS
            geolocation.deferTime = 0


            /** Filtering – keep raw accurate points, light noise reduction **/
            geolocation.filter.policy = LocationFilterPolicy.PassThrough    /** or LocationFilterPolicy.Adjust **/
            geolocation.filter.useKalman = false                        /** or true + KalmanProfile.Default if you want smoother tracks **/
            //geolocation.filter.kalmanProfile = KalmanProfile.Default
            geolocation.filter.trackingAccuracyThreshold = 0.0
            geolocation.filter.burstWindow = 0.2

            // ────────────────────────────────────────────────
            // ACTIVITY RECOGNITION CONFIGURATION
            // ────────────────────────────────────────────────

            activity.activityRecognitionInterval = 3000.0
            activity.minimumActivityRecognitionConfidence = 60
            activity.triggerActivities = "in_vehicle, on_bicycle, running, on_foot, walking"
            activity.disableStopDetection = false
            activity.stopOnStationary = false /**if true then SDK auto stop, need to start manually**/
            activity.disableMotionActivityUpdates = false
            activity.motionTriggerDelay = 0         /** Reduced slightly for faster moving transitions **/


            // ────────────────────────────────────────────────
            // APP LIFECYCLE – keep alive
            // ────────────────────────────────────────────────

            app.stopOnTerminate = false               /** Keep engine alive when app is swiped away **/
            app.startOnBoot = true                   /** Auto-resume engine on phone reboot **/
            app.enableHeadless = true                /** Allow tracking events to wake up your Headless file **/
            app.headlessJobService = AutoTripHeadlessTask::class.java.name


            // --- FOREGROUND NOTIFICATION CONFIGURATION ---
            app.notification.priority = NotificationPriority.HIGH
            app.notification.title = context.getString(R.string.app_name)
            app.notification.text = context.getString(R.string.initializing)
            app.notification.smallIcon = "mipmap/ic_launcher"
            app.notification.channelId = TxdotConstants.CHANNEL_ID
            app.notification.channelName = TxdotConstants.CHANNEL_NAME
            app.notification.sticky = true
            app.notification.actions = listOf(context.getString(R.string.end_trip))
            app.notification.allowTap = true
            app.notification.tapActivity = "com.txdotmobility.ui.home.dashboard.SideNavigationActivity"

            app.backgroundPermissionRationale = mapOf(
                "title" to context.getString(R.string.back_loc_title),
                "message" to  context.getString(R.string.back_loc_desc),
                "positiveAction" to context.getString(R.string.enable_background_activity),
                "negativeAction" to context.getString(R.string.not_now)
            )


            // ────────────────────────────────────────────────
            // HTTP / PERSISTENCE
            // ────────────────────────────────────────────────

            http.autoSync = true            /** Uploads each recorded location to url immediately after it is recorded.**/
            http.batchSync = false           /** Bundles all queued locations into a single HTTP request.**/
            http.disableAutoSyncOnCellular = false
            persistence.maxDaysToPersist = 3


            // ────────────────────────────────────────────────
            // LOGGING (turn VERBOSE only while debugging)
            // ────────────────────────────────────────────────
            logger.debug = true //BuildConfig.DEBUG
            logger.logLevel = LogLevel.VERBOSE
            logger.logMaxDays = 3
        }

[soft-dev-akshay]

sdk_logs_file_1_google_pixel_9.txt
sdk_logs_file_1_google_samsung_s23.txt
sdk_logs_file_2_google_pixel_3.txt
sdk_logs_file_2_google_pixel_5.txt

[christocracy]

I've analyzed all four log files in detail. Summary of what they actually show:

A note on the files first: sdk_logs_file_1_google_pixel_9.txt is byte-for-byte identical to
the first 23,787 lines of sdk_logs_file_2_google_pixel_3.txt — it's the same log from the same
device, exported twice under two different names, so it can't be analyzed as a second device.
And sdk_logs_file_1_google_samsung_s23.txt contains only 26 seconds of tracking: your app
called .stop() at 08-12 20:36:43.810 (Cleared callbacks → enabledchange), after which the
SDK was disabled. Neither of your claims is even observable in those two files.

That leaves two usable logs — sdk_logs_file_2_google_pixel_3.txt and
sdk_logs_file_2_google_pixel_5.txt, both covering the same ~64-minute session on 08-13.
I'll refer to them as pixel_3 and pixel_5 below.

1. "The SDK skips intervals and drops fixes"

The logs show the opposite. Counting every TrackingService: LocationResult (each one = the OS
delivering a fix to the SDK):

• pixel_3: 1,319 fixes, mean interval 2.72s, 97.4% ≤ 5s apart. Zero gaps in the 15–30s band
  while in the moving state.
• pixel_5: 1,052 fixes, median interval 2.99s, p90 3.02s — essentially perfect 3000ms
  cadence.

Every gap > 10s falls into exactly two categories:

1. Location availability: false — Google's FusedLocationProvider explicitly declaring it
   cannot produce a fix (e.g. the 2-minute outage at 22:36–22:38, where accuracy degraded from
   9m to 300m — indoors/GPS-hostile conditions; both pixel_3 and pixel_5 show it at the same
   wall-clock time, i.e. it was the environment, not the device or the SDK). Delivery resumed
   within ~20ms of availability: true, every time. The SDK cannot record fixes the OS never
   produced.
2. Stationary episodes — after stopTimeout expired while your devices sat parked at
   identical coordinates for minutes (e.g. pixel_5's 619s gap, 23:01→23:12). Location-services
   are switched off in the stationary state by design. Tracking resumed instantly when motion was
   detected (see below).

The filter dropped almost nothing: pixel_5 shows zero rejected fixes; pixel_3 rejected
26 of 1,319 (~2%) — all with 100–300m accuracy or 400m+ position teleports, i.e. garbage that
would have put spikes on your map (all 26 came from pixel_3, which was still running your
original Adjust + Kalman filter config — pixel_5, on your updated PassThrough config,
rejected nothing; see section 3). Overall the SDK persisted 15–20 records/minute — against
your stated requirement of 6/minute.

locationUpdateInterval is a request, not a contract — that's Android's own contract for
LocationRequest, and it's the same for every app on the platform. iOS's CoreLocation behaves
differently (it streams continuously by distanceFilter), which is why the dot density differs
between your two maps. That difference is platform behavior, not data loss — nothing was lost.

2. "Activity recognition freezes"

The SDK subscribes to the Google Play Services Activity Transition API. Google delivers events
only when it decides a transition occurred — the SDK cannot force, poll, or accelerate this
(activityRecognitionInterval applies to the legacy sampling API and does not make Google emit
events every 3s).

pixel_3 shows Google delivered 41 activity events in 64 minutes. Every window where you
observed a "frozen" activity contains zero delivered events — there was literally nothing to
act on. And when an event did arrive, the SDK reacted instantly (pixel_5):

• 23:12:12.279 EXIT:still / ENTER:walking → SDK entered moving state in the same millisecond,
  first fix 268ms later.
• 23:20:43.616 ENTER:in_vehicle → moving state in 10ms.

The "stuck on in_vehicle" is Google's own classifier: in pixel_3 it held in_vehicle while
your device sat parked with velocity 0.00 for 11 minutes (22:39–22:50), and in pixel_5 it
classified your car as on_bicycle for 3 minutes at 30–65 km/h (22:55–22:58). The SDK reports
what Google reports.

Your claim that only ready() unfreezes it is disproven by your own log: in pixel_3 at
23:21:19 the SDK woke itself via stationary-geofence exit — a full minute before your app's
next ready() call at 23:22:25. What your ready() actually does is call changePace(true) —
your app re-runs ready() + getCurrentPosition() + changePace(true) on nearly every foreground
(9 times in the pixel_3 session, and a double-initialization in the samsung log). That forces
isMoving=true; it doesn't "unfreeze" anything.

3. Config notes

Your updated config reconciles with the hydrated values in the samsung log
(fastestLocationUpdateInterval: 1000, minimumActivityRecognitionConfidence: 60,
elasticityMultiplier: 1) — so the config you posted second is what ran. Three observations:

1. Your two test devices were running different configs during the same session. The pixel_5
   log shows your updated filter config (LocationFilterPolicy.PassThrough,
   trackingAccuracyThreshold = 0.0, useKalman = false): zero fixes adjusted or rejected —
   the SDK persisted 100% of what the OS delivered, which means every gap on that device is
   conclusively OS-side. The pixel_3 log shows your original config still active
   (Adjust + Kalman): 116 kinematic-cap adjustments and all 26 rejections in the dataset came
   from that device. Make sure both devices run the same build/config before comparing tracks —
   your two Android maps aren't apples-to-apples with each other, let alone with iOS.

2. stationaryRadius = 25 is clamped at runtime: the stationary geofence in your logs is
   150m (the minimum for reliable geofence triggering on Android). Expect stationary-exit
   detection to require on the order of 150m of travel when activity recognition doesn't fire
   first.

3. With PassThrough + trackingAccuracyThreshold = 0.0 you have already "completely disabled
   the filters" you asked about — as pixel_5 proves. The 100–300m-accuracy fixes and 400m
   teleports that pixel_3's filter was rejecting will now be recorded verbatim, spikes and all.
   That's the trade-off you've chosen; the filter was never the cause of your gaps either way.

Recommendation

Your use-case is: the app explicitly starts a trip, wants a record every N seconds until the app
explicitly ends it. Configure for that instead of fighting stop-detection:

geolocation.distanceFilter = 0f
geolocation.disableElasticity = true
activity.disableStopDetection = true   // no automatic stationary state, ever

// trip start:
BGGeo.instance.changePace(true)
// trip end:
BGGeo.instance.changePace(false)

With disableStopDetection: true the SDK never returns to stationary on its own — motion state is
entirely under your control, which is what your app is already trying to do with its repeated
changePace(true) calls. Your updated config still has disableStopDetection = false. (Note the
battery cost: location-services run continuously between your changePace calls.)

Also: 4.1.8 is several releases behind — current is 4.4.2, with a number of robustness fixes.

If you still believe the SDK dropped a delivered fix or ignored a delivered activity event, point
me at a specific timestamp — I've been through all ~110k lines and there isn't one.