Android Location Forensics: Timeline, Wi-Fi, EXIF

Location questions come in two shapes: "where was this phone at a given time" and "was this phone ever at this place". Android can answer both, but no single artifact does it alone, and the most famous source, Google Location History, changed fundamentally in 2024 and 2025. This guide maps the current location sources on an Android phone, explains how precise each one is, and gives a method for combining them without over-reading any.

The sources

Google Timeline after the on-device move

For a decade, Location History lived in the Google account, and investigators requested it from Google or found it in a user's Takeout archive (Records.json for raw points, Semantic Location History for visits and trips). In 2024 Google renamed the feature Timeline, began storing it on the device, and gave users deadlines into 2025 to migrate. Cloud history that was not migrated was deleted. Users can opt into an end-to-end encrypted cloud backup that Google cannot read.

Consequences for casework:

• The handset is now the primary source. Plan an AFU full file system extraction that covers the Google Maps and Google Play services sandboxes. Public research on the exact on-device files is still developing, so validate your tool's output on a test phone with the same app versions.
• The user can export it. Settings > Location > Location services > Timeline > Export Timeline data produces a Timeline.json with semanticSegments (visits and paths), rawSignals (positions with accuracy) and a user location profile. With consent, a documented export is quick and complete.
• Legacy archives still matter. Takeout exports made before the migration, earlier legal process returns, or backups the user kept can cover years the phone no longer holds.
• Auto-delete. The user may have set Timeline to delete after 3, 18 or 36 months, or deleted specific days: absence of data is not absence of movement.

When working with Timeline, cite raw points and their accuracy radius rather than the inferred place name. A "visit" to a shop is a model's guess from points and nearby place data; the points are the measurement.

Photos and videos

Camera photos often carry GPS in EXIF (GPSLatitude, GPSLongitude, GPSDateStamp, GPSTimeStamp) along with the local capture time and, on recent phones, its UTC offset. Videos carry location in container metadata. That makes the camera roll a set of precise, independently timed location points.

Caveats:

• Location tagging is a camera setting; many users turn it off.
• Messaging and social apps strip EXIF on sending; received images carry none.
• EXIF can be edited. Check consistency with the MediaStore row (date_added, owner_package_name), the file name (for example PXL_20260914_154312345.jpg) and file system times.
• GPS time in EXIF is UTC; DateTimeOriginal is local. A mismatch between them equal to the time zone offset is normal.

exiftool -n -csv -r -DateTimeOriginal -OffsetTimeOriginal \
  -GPSDateStamp -GPSTimeStamp -GPSLatitude -GPSLongitude -Model DCIM/ > exif_gps.csv

Wi-Fi and Bluetooth: proximity, not coordinates

Saved Wi-Fi networks and Bluetooth bonds prove that the phone was once near a specific access point or device:

• A saved home network with a distinctive SSID, a hotel or venue network, an employer's enterprise network: each suggests presence at a place at least once. WifiConfigStore.xml carries few reliable per-network times, so date the association from file system times, dumpsys wifi connection history on a live phone, and other artifacts from the same day.
• A car head unit in bt_config.conf ties the phone to a vehicle; a smartwatch or tracker ties it to another device that may hold its own location data.

To turn an SSID or BSSID into a place you need external data (the venue's own records, a site survey, or public Wi-Fi geolocation databases, which carry their own accuracy and legal considerations). Report such associations as "the device had saved or connected to network X", not "the device was at address Y", unless the network's location is independently established.

System location dumps

On a live phone, adb shell dumpsys location prints each provider's last known location with time and accuracy, recent location requests by app, and the state of GPS and network location. A bugreport contains the same dump. It is a narrow window, but it can place the phone at seizure time or show which apps were requesting location in the background, which matters in stalkerware cases (see the malware triage guide).

App Ops also records the last time each app accessed fine or coarse location, visible in dumpsys appops and in runtime permissions and appops.

App-level location

Many apps keep their own location history in their sandboxes, all requiring an AFU full file system extraction:

• Google Maps: searches, navigated destinations, saved places.
• Ride-hailing and delivery apps: pickup and drop-off addresses with times.
• Fitness and running apps: GPS tracks of workouts.
• Messaging apps: shared locations and live locations in WhatsApp, Telegram and Signal messages (see the messaging guide).
• Browsers: map and directions URLs in Chrome or Samsung Internet history.

Parse them with ALEAPP where modules exist, or with SQL, and validate unknown schemas on a test device.

Cell data

The handset keeps little long-term cell history in accessible form. Modem logs and some OEM diagnostics hold serving cell information for short periods, and dumpsys telephony.registry shows the current serving cell. Historic cell site data usually comes from the network operator through legal process and is analysed separately; it places the phone within a sector, often kilometres wide.

Weighing and combining sources

Build a location table in UTC with one row per observation: time, latitude and longitude (or a named network or device), accuracy, source, and the original record. Then:

1. Prefer measurements over inferences. Raw fixes, EXIF GPS and Wi-Fi connections are observations; place visits and activity types are inferences.
2. Carry uncertainty through. Draw accuracy radii, not pins. Two points 300 metres apart with 500-metre radii do not show movement.
3. Seek independent agreement. A Timeline visit, a photo with GPS nearby, and a Wi-Fi connection to the venue's network at the same time are three independent sources.
4. Check clocks. Confirm the device clock was network-set (auto_time in settings) and note time zone changes during travel.
5. Account for the person. A phone's location is not its owner's. Handovers, shared devices and phones left in cars are common explanations for anomalies.

The timeline analysis guide shows how to merge these rows with app usage and communications into one device timeline.

Worked example: was the phone at the warehouse?

The question: was the suspect's phone at a warehouse on the evening of 14 September? The sources, all converted to UTC:

The inferred visit names the wrong business, which is common in dense areas; the raw points, the photo and the Wi-Fi scan are consistent with the warehouse. The report should rely on the photo and raw points, cite the radii, mention the Wi-Fi scan as supporting proximity, and explain why the inferred place name differs.

Common pitfalls

• Reading the inferred place as fact. Semantic visits can name the building next door, or a place the device merely passed.
• Ignoring the radius. A single cell-based point with a 1,500-metre radius cannot place a phone on a street.
• Treating last known location as current. dumpsys location values have their own age; read the timestamp next to them.
• Assuming the Wi-Fi network is where its name suggests. Mobile hotspots and chains with identical SSIDs make names unreliable without the BSSID and a survey.
• Forgetting stripped metadata. A received image without EXIF is not evidence of an absence of location, and a received image with EXIF shows where the sender's camera was, not the recipient.
• Clock and zone errors. EXIF local time and a travel-related zone change can shift a point by hours if not normalised.

Reporting location findings

• State the source, method of extraction and version of every tool.
• Quote the accuracy radius for every point used and explain what it means in plain language.
• Distinguish "the device" from "the person", and "was near" from "was at".
• Mention sources that were checked and empty (Timeline disabled, location tagging off) as well as those with data.
• For maps, show raw points and radii; avoid smooth lines between sparse points unless the source recorded a path.

Checklist

• Keep the phone AFU and extract the Google Maps and Play services sandboxes.
• Ask whether the user can export Timeline, and look for older Takeout archives.
• Pull the camera roll with timestamps and run ExifTool over it.
• Collect WifiConfigStore.xml, bt_config.conf, and dumpsys location, dumpsys wifi and dumpsys bluetooth_manager on a live phone.
• Parse app-level histories (maps, ride-hailing, fitness, messaging).
• Merge in UTC with accuracy, and report measurements, not guesses.