Your MDM platform reports device location. What it does not tell you is how much of the shift that location data actually covers.
Android distinguishes between foreground location and background location at the API level. Foreground location APIs deliver updates while the requesting application is the active process on the device screen. The moment the user switches to another application, the MDM app moves to the background and foreground location updates stop. For a field employee who opens the MDM app once at the start of their shift and then works through a delivery app, a warehouse management system, or a customer service application for the rest of the day, the MDM platform’s location data ends shortly after the shift begins.
This is not a configuration gap or a connectivity issue. It is an architectural characteristic of how Android manages location access for applications that are not in the foreground. The distinction between foreground and background location access is enforced at the operating system level through Android’s permission model and process lifecycle management.
The consequence for IT teams managing field device fleets is that the location compliance picture the MDM dashboard presents is accurate for the brief window when the MDM app is actively in use and incomplete for the majority of the working shift. For organisations where device location data underpins workforce compliance, client contractual obligations, or regulatory requirements around where corporate data is being accessed, the gap is operational rather than theoretical.
This blog covers how Android’s location API architecture creates this gap, what foreground-only location tracking produces as a dataset versus what background location tracking produces, and how Akku MDM’s background location tracking capability closes the gap with configurable reporting intervals across the full shift.
Android’s location subsystem is built around two distinct access modes that carry different permission requirements and different OS-enforced behaviours.
An application that holds the ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permission can request location updates while it is the active foreground application. Android delivers these updates at the requested interval as long as the app remains in the foreground. When the user navigates away from the app, the process moves to the background and the OS restricts or suspends the location update stream. Applications that declare a foreground service can maintain location access while backgrounded, but the foreground service notification is visible to the user and the service consumes battery proportionally to the update frequency.
Standard MDM clients that use foreground location access without a persistent foreground service produce location data only during active app use. For device management workflows where administrators periodically open the MDM app to check in, this means location data is available at the moment of each check-in and absent between them. The result is a sparse dataset of point-in-time locations rather than a continuous track of device position throughout the shift.
ACCESS_BACKGROUND_LOCATION is a separate, more restrictive Android permission that allows an application to receive location updates even when it is not in the foreground. Android 10 introduced this as a distinct permission requiring explicit user grant. Android 11 and later further restricted background location access: it cannot be requested at the same time as foreground location. The user must first grant foreground location, then separately grant background access through the system settings, where the option reads explicitly as ‘Allow all the time’ rather than ‘While using the app.’
Applications with background location access can use Android’s WorkManager, AlarmManager, or a persistent background service to request location updates at configurable intervals throughout the device’s operational period, regardless of which application the user has open. The location data produced is a continuous track rather than a sparse set of check-in points. Battery consumption is proportional to the reporting interval and can be managed by configuring a longer interval for non-time-sensitive use cases.
For a field employee running an eight-hour shift, a foreground-only MDM location implementation produces a dataset that looks like this: location recorded at app open at shift start, location recorded at any subsequent manual check-in or app interaction, location recorded at shift end. The hours between those interactions produce no location data.
The dashboard shows the device as compliant because the enrollment state is active and the last known location is within an expected range. What the dashboard does not show is that the last known location is two hours old and the device may have been anywhere in the interim. For organisations managing field employees who handle sensitive physical assets, access restricted customer locations, or operate in environments where real-time device location is a contractual or regulatory requirement, a two-hour-old location data point is not location tracking. It is a check-in log.
The gap matters differently depending on the use case. For healthcare organisations where clinical staff carry devices with access to patient data, a foreground-only location implementation cannot verify that the device remained within the permitted care environment throughout the shift. For ITeS and BPO organisations with client data handling obligations that include location-based access restrictions, a sparse location dataset does not satisfy the continuous compliance requirement. For logistics and field operations where route adherence and location verification are operational requirements, foreground-only tracking produces data too sparse to be operationally useful.
Akku MDM’s background location tracking for Android uses the ACCESS_BACKGROUND_LOCATION permission combined with a configurable periodic location worker. The worker runs at an administrator-defined interval throughout the device’s operational period, independent of which application is active on the device screen. Location updates are reported to the Akku MDM console in real time and stored with device identifier, timestamp, latitude and longitude coordinates, and accuracy radius.
The administrator console displays the continuous location track for each enrolled device, showing position at each reporting interval throughout the shift rather than at manual check-in points. For a device running a thirty-minute reporting interval over an eight-hour shift, the administrator receives sixteen location data points covering the full operational period. For environments requiring tighter tracking, shorter intervals are configurable.
The background location capability integrates with Akku MDM’s existing compliance monitoring and group-based policy framework. Administrators can apply background location tracking as a policy to specific device groups, specific user groups within the organisation, or the full enrolled device fleet. Devices that do not grant the background location permission can be flagged as non-compliant in the Akku MDM compliance dashboard, triggering the existing non-compliance workflow.
The location data produced by background tracking feeds into the same centralised reporting that Akku MDM uses for audit readiness. For compliance exercises requiring evidence that corporate devices remained within permitted locations throughout a defined period, the background location track provides the continuous timestamped dataset that foreground-only check-in logs cannot.
Because Android requires background location to be granted through a separate, explicit user action, the enrollment and permission grant workflow requires specific handling. Akku MDM’s Android enrollment flow presents the foreground location permission request as part of initial device enrollment. After the foreground permission is granted, the enrollment flow directs the user to the system settings to grant the ‘Allow all the time’ background location permission.
The user-facing explanation presented at this step is configurable by the administrator. For corporate-owned devices where the organisation controls the device use policy, the background location requirement can be stated as a condition of device enrollment. For BYOD devices, the permission grant remains subject to the user’s acceptance, and the MDM can be configured to flag devices where background location permission has not been granted as having a policy exception rather than as enrollment-blocked.
This distinction between corporate-owned and BYOD handling reflects the broader Akku MDM architecture, which maintains work profile isolation on Android to separate corporate data from personal data. Background location tracking applies to the device as a whole rather than to the work profile, which means the permission grant and the privacy disclosure to the user need to be consistent with the organisation’s BYOD policy.
For healthcare organisations managing Android devices that carry access to patient data, continuous location tracking supports the requirement to demonstrate that protected health information was accessed only from permitted locations. HIPAA does not specify a location tracking requirement for devices, but organisations that use location-based access controls as a technical safeguard under HIPAA Section 164.312(a)(1) need the location data to be continuous rather than sparse to satisfy the control.
For ITeS and BPO organisations with client contractual requirements around where data can be accessed, background location tracking provides the continuous location evidence that spot-check foreground logs cannot. For field operations and logistics environments where device location tracking is an operational requirement tied to route compliance and asset tracking, background location data at configurable intervals produces the operational dataset the use case requires.
Under DPDPA Rules 2025, the collection of background location data from employee devices constitutes processing of personal data. Organisations implementing background location tracking are required to ensure that the processing is based on a legitimate purpose, that employees are informed of the tracking, and that the data is retained only for the period necessary for the stated purpose. Akku MDM’s group-based policy model supports scoping background location tracking to specific device groups, allowing organisations to apply tracking only to the roles and use cases where it is operationally justified rather than to the entire enrolled fleet.
Open your MDM console and pull the location history for three enrolled Android devices used by field employees. Count the number of location data points recorded during a standard eight-hour shift. If the count is in single digits, the MDM is using foreground-only location access. The location compliance dashboard is showing you check-in points, not continuous shift coverage.
Check the Android permission state for the MDM app on those devices. If the location permission shows as ‘While using the app’ rather than ‘Allow all the time’, background location access has not been granted. The MDM platform is architecturally limited to foreground-only reporting. For environments where continuous location coverage is operationally or contractually required, Akku MDM’s background location tracking capability closes the gap without requiring a change to the device management model.
Explore Akku MDM Capabilities | Talk to the Akku Team
Q: What is the technical difference between ACCESS_FINE_LOCATION and ACCESS_BACKGROUND_LOCATION on Android?
A: ACCESS_FINE_LOCATION grants an application the ability to receive precise location updates from GPS and network sources. It is classified as a foreground permission on Android 10 and later, meaning it allows location access only while the app is in the foreground or while a foreground service is running with the location foreground service type declared. ACCESS_BACKGROUND_LOCATION is a separate permission that extends location access to background operation, allowing the app to receive location updates regardless of whether it is the active foreground application. Android 11 and later require this permission to be granted separately through system settings, where the user explicitly selects ‘Allow all the time’ rather than ‘While using the app.’ The two permissions have different grant flows and different battery impact profiles.
Q: How does Akku MDM implement background location reporting without draining the device battery?
A: Akku MDM’s background location worker uses Android’s WorkManager with a configurable periodic task interval. WorkManager is battery-optimised by design: it batches work requests with other background operations and respects Android’s Doze and App Standby restrictions while still delivering location updates at the configured interval. Administrators set the reporting interval based on operational requirements. A thirty-minute interval produces sixteen data points over an eight-hour shift with minimal battery impact. Shorter intervals are available for environments requiring tighter tracking, with the understanding that battery consumption scales with reporting frequency.
Q: What happens to the background location track if the device loses connectivity mid-shift?
A: Akku MDM’s location worker stores location events locally on the device when the MDM platform is not reachable. On connectivity restoration, the stored events are uploaded to the Akku console with their original timestamps. The location track in the admin console reflects the full shift coverage, including the offline period, not just the connected periods. This is relevant for field environments where network connectivity is intermittent, such as warehouses with coverage gaps or field sites outside urban areas.
Q: How does DPDPA apply to background location tracking of employee devices?
A: Under DPDPA Rules 2025, background location tracking of an employee’s Android device constitutes processing of personal data. The data fiduciary, which is the employing organisation, is required to ensure the processing is based on a legitimate purpose, that the employee is informed of the tracking, and that the data is not retained beyond the period necessary for the stated purpose. For corporate-owned devices, the employment agreement and device use policy can establish the legitimate purpose and notification requirement. For BYOD devices, the explicit permission grant required by Android for background location access serves as part of the user notification, but the organisation should ensure the permission request is accompanied by a clear explanation of what data is collected, how it is used, and how long it is retained.
Q: Can background location tracking be applied to specific device groups rather than the entire enrolled fleet?
A: Yes. Akku MDM’s group-based policy assignment allows background location tracking to be applied at the organisational unit or user group level. An administrator can enable background location for field operations devices while leaving office-based devices on foreground-only location or no location tracking. This allows the organisation to scope continuous location tracking to the roles and use cases where it is operationally justified and to maintain a clear, defensible basis for the processing under DPDPA and similar data protection requirements.
Q: How does background location tracking interact with Akku MDM’s work profile isolation on BYOD devices?
A: Work profile isolation on Android separates corporate applications and data from personal applications and data within the same device. The work profile runs as a separate user space, but location services operate at the device level rather than at the profile level. Background location tracking granted to the Akku MDM app applies to the device as a whole, not only to the work profile. This means background location data is collected from the full device, not only from work profile activity. For BYOD deployments, this distinction should be addressed explicitly in the device use policy and the permission grant flow, so that employees understand the scope of location data being collected before granting the permission.
Your SCIM provisioning connector ran its last sync six hours ago. It failed. Nobody received an alert. Nobody knows. The…
What is the most sensitive system in your organisation? Not the most technically complex. The one with the highest concentration…
Here is a question worth asking your compliance team: how long would it take to produce the evidence package for…
Your BYOD policy permits employees to access corporate applications from personal devices. The security team agreed to this because blocking…
When did your MDM platform last produce a complete list of every application installed on every enrolled device? Not the…
A security incident investigation is three days in. A privileged user accessed a production database server on a Tuesday afternoon.…