[Help Wanted]: Some devices reporting Location error {"errorCode":408,"message":""}

[Keickd]

Required Reading

• Confirmed

Plugin Version

5.0.5

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

Redmi A9, Motorola G05/G06

Device operating-systems(s)

Android 10, 11, 15

What do you require assistance about?

We are not sure why this is happening, but some devices are reporting this issue. These devices send a position update every 45 minutes (the heartbeatInterval is set to 2700 seconds). For some of them, the updates alternate between success and failure, while others consistently fail with the same timeout error.

Could there be any misconfiguration causing this behavior?

These devices operate continuously, 24/7.

[Optional] Plugin Code and/or Config

@Singleton()
class LocationService implements VitalsService<LocationReport> {
  final LoggerService _logger;
  final ConfigService _configService;

  final _locationSubject = BehaviorSubject<LocationReport>();

  LocationService(this._logger, this._configService);

  @factoryMethod
  static Future<LocationService> setup(
    LoggerService logger,
    ConfigService configService,
  ) async {
    final service = LocationService(logger, configService);
    await service._init();
    return service;
  }

  Future<void> _init() async {
    final config = bg.Config(
      reset: true,
      foregroundService: true,
      geolocation: const bg.GeoConfig(
        desiredAccuracy: bg.DesiredAccuracy.high,
        disableLocationAuthorizationAlert: true,
      ),
      app: bg.AppConfig(
        heartbeatInterval: _configService
            .getInt(
              'location',
              'auto_update_seconds',
            )
            .toDouble(),
        stopOnTerminate: true,
        startOnBoot: false,
        enableHeadless: false,
        notification: bg.Notification(
          title: 'Maximiliana',
          text: 'El seguimiento de la ubicación está activo',
          smallIcon: 'mipmap/ic_notification',
        ),
      ),
      isMoving: true,
    );

    final state = await bg.BackgroundGeolocation.ready(config);

    bg.BackgroundGeolocation.onLocation(_onLocation, _onLocationError);
    bg.BackgroundGeolocation.onHeartbeat(_onHeartbeat);

    if (!state.enabled) {
      await bg.BackgroundGeolocation.start();
    }

    _logger.info(
      'LocationService',
      'Background geolocation configured',
      debugPayload: {
        'desiredAccuracy': config.geolocation?.desiredAccuracy?.name,
        'heartbeatInterval': config.app?.heartbeatInterval,
        'stopOnTerminate': config.app?.stopOnTerminate,
        'startOnBoot': config.app?.startOnBoot,
        'enableHeadless': config.app?.enableHeadless,
        'disableLocationAuthorizationAlert':
            config.geolocation?.disableLocationAuthorizationAlert,
      },
    );
  }

  void _onHeartbeat(bg.HeartbeatEvent event) {
    bg.BackgroundGeolocation.getCurrentPosition(
      timeout: 60,
    ).then(_onLocation).catchError((Object error) {
      _logger.warning(
        'LocationService',
        'Heartbeat location fetch failed',
        debugPayload: {'error': error.toString()},
      );
    });
  }

  void _onLocationError(bg.LocationError error) {
    _logger.error(
      'LocationService',
      'Location error',
      debugPayload: {'errorCode': error.code, 'message': error.message},
    );
  }

  void _onLocation(bg.Location location) {
    _locationSubject.add(
      (
        latitude: location.coords.latitude,
        longitude: location.coords.longitude,
      ),
    );
  }

  @override
  Stream<LocationReport> get stream => _locationSubject.stream;

  @override
  Map<String, dynamic> serializeInformation(LocationReport report) {
    return {
      'latitude': report.latitude,
      'longitude': report.longitude,
    };
  }

  @override
  String get publishPath => '/location';
}

[Optional] Relevant log output

Location error  {"errorCode":408,"message":""}

[christocracy]

A couple years ago, Android introduced strict new limits on when a device can request location in the background. You're likely experiencing those limits.

If a device is sitting idle (not moving) and you're requesting location in the background, Android can and will refuse those request.

Android makes exceptions for a couple of cases, which this SDK takes full advantage of:

• when a motion api event is received.
• a Geofencing event (ie the GeoConfig.stationaryRadius).

See Android docs.

Turning on location-services in the background requires a foreground service (which this SDK always does).

The API docs clearly show Android's intent: "we don't want you constantly requesting location in the background while a device is sitting stationary but if the device is detected to be moving, we'll allow that".

[Keickd]

Hi, thank you for your response.

I’ve reviewed the documentation, but I still have a few questions.

I also checked the GeoConfig documentation:
https://docs.transistorsoft.com/flutter/GeoConfig/

However, I’m not sure I fully understand the stationaryRadius parameter. Does this mean that if the value is set below 200 meters, it won’t work properly? If so, wouldn’t 200 meters be too large for many use cases?

Regarding stopOnStationary, my understanding is that the GPS stops when the device is stationary, and then automatically resumes tracking once movement is detected. Is that correct? And does the device need to move beyond the stationary radius (e.g., 200 meters) before tracking resumes?

In our case, we manage hundreds of devices running in kiosk mode, and they remain stationary most of the time. Given this scenario, what configuration would you recommend?

Thank you in advance for your help.

[christocracy]

However, I’m not sure I fully understand the stationaryRadius parameter. Does this mean that if the value is set below 200 meters, it won’t work properly? If so, wouldn’t 200 meters be too large for many use cases?

No, the OS effectively enforces a minimum of 200 when you try to set it to anything less. Setting it to 10 has the same effect as 200.

Regarding stopOnStationary, my understanding is that the GPS stops when the device is stationary, and then automatically resumes tracking once movement is detected. Is that correct? And does the device need to move beyond the stationary radius (e.g., 200 meters) before tracking resumes?

stopOnStationary is **not ** what you want. it means, literally, "call .stop() the next time the plugin enters the stationary state", meaning toggle the plugin's ON/OFF switch OFF -- No tracking ever until you call .start() again.

If you want to keep location-services ON for a longer period after the device has determined it's stationary, see API docs stopTimeout.

[Keickd]

Hi, thank you again for your help.

So, stationary radius doesn't fit our case.

In our scenario, we need to retrieve the device’s real-time location while it is moving. However, when the device becomes stationary, we require a fallback mechanism to periodically obtain its location (for example, every 45 minutes), even if it remains completely stationary.

We currently have around 600 devices deployed, and about 120 of them are reporting this error. Most devices experience long stationary periods (especially overnight) and they don't have the error, which make us doubt about the real cause of the problem.

Additionally, the error distribution is uneven:
Some devices report the error only once. Others report it very frequently (e.g., over 100 LocationError events in a single week).

The affected devices include models such as Motorola G05/G06 and Redmi 9A.

Any guidance or best practices for handling this kind of use case would be greatly appreciated.

Thank you in advance.

[christocracy]

See https://dontkillmyapp.com

[pitazzo]

Hi @christocracy , I'm the tech lead on @Keickd 's project. Let me add some context that might help narrow this down.

Our setup is not a typical consumer app:

• These are company-owned devices running our app as device owner in kiosk mode. Android does not restrict or kill it like a regular background app. Battery optimizations are disabled, and the app holds a foreground service at all times.
• Before migrating to this plugin, we used the vanilla geolocator package with a simple timer-based approach and had zero timeout issues across an even bigger fleet, same OEMs (Redmi 9A, Moto G05/G06).

So the problem is not OEM battery management or Android killing our process: that's ruled out.

What we need is straightforward:

1. Receive a location update whenever the device moves.
2. Receive as well a location update every ~45 minutes even if the device is completely stationary.

Our question is simple what is the correct plugin configuration for this use case? We suspect our current config (posted above) has something wrong, but the docs don't make it obvious what the right combination of parameters is for a permanently-running, privileged app.

Thanks in advance.