Location Based Tracking
A field-operations platform for Z&Z with a Grameenphone partnership: continuous GPS, OpenStreetMap journeys, point-of-interest proximity, and attendance that stay reliable when Android background limits and weak networks get in the way.
Z&Z
Dhaka, Bangladesh
Sr. Software Developer
TechTrioz · Production
Cross-Platform Flutter Engine
Private / enterprise distribution
Manager dashboard · live map · routes, tasks, and attendance in one field workflow
Keep tracking alive on supported Android devices without constant interaction
Location and activity stay on device until the backend acknowledges them
Routes, stops, dwell time, and points of interest on OpenStreetMap
Platform channels and recovery jobs where Flutter’s lifecycle was not enough
Executive Summary
Location Based Tracking (LBS) is a field-operations app for sales and marketing teams whose people work across cities and customer sites. Managers needed more than a pin on a map. They needed the day’s journey: where someone is, where they have been, how long they stayed, which points of interest they were near, which leads, tasks, and appointments they completed, and whether the reported location looked genuine.
I built the mobile system at TechTrioz for Z&Z, in a Grameenphone partnership. Flutter owned the product and the field workflow. Native Android owned the parts of background execution a normal Flutter lifecycle could not guarantee. OpenStreetMap rendered the geography. A local queue sat between GPS capture and the backend so a dead network did not become lost history.
The hard requirement was continuous background tracking on Android, including a target of roughly 72 hours on supported devices, across manufacturer battery policies that kill a process on one phone and leave it running on another.
The Challenge
The Challenge: Reliable Tracking Under Hostile Android Conditions
A simple GPS call is not a field system. The app had to keep collecting location when the user left it, the radio dropped, the battery changed, and a customized Android ROM decided the process should die. The problem was reliability, not coordinates.
Reported Activity Was Not the Journey
Traditional field tools record what an employee says they did. This product had to reconstruct the actual path: start, stops, dwell, nearby points of interest, and the work assigned along that path.
Flutter’s Lifecycle Was Not Enough
Continuous background tracking, targeted for extended periods up to about 72 hours on supported Android devices, needed native execution, platform channels, scheduled recovery, and restart logic. A foreground Flutter session could not carry that.
Every Manufacturer Kills Processes Differently
A service that stayed alive on one device could be terminated early on Samsung, Xiaomi/Redmi, Huawei, and other customized ROMs. The design had to survive those policies, not assume stock Android.
Weak Networks and Fake GPS
Field staff move through bad coverage, and location data drives attendance and visits. Points had to persist locally and retry, and sudden impossible jumps had to be treated as suspicious rather than accepted as a real visit.
Project Scope
Engineering Objectives & Delivery Scope
- Collect a continuous location stream (coordinates, timestamps, movement, and dwell) and turn it into a day’s route, not a single current pin.
- Keep background tracking alive on Android with native execution, platform channels, scheduled jobs, and recovery when the process is killed.
- Render journeys, stops, current position, and points of interest on OpenStreetMap.
- Tie location to the work: leads, tasks, appointments, customer visits, and completion status.
- Record attendance against the same location picture, including proximity to assigned sites.
- Persist locally first and synchronize in batches, deleting local records only after the server acknowledges them.
- Adapt collection frequency for battery, movement, precision, and network instead of sampling at maximum rate all day.
- Flag abnormal movement that suggests GPS spoofing or otherwise invalid positioning.
Engineering Foundation
Architecture & Technical Design
Flutter and an MVC application layer ran the field workflow. A native Android location layer, reached through platform channels, owned background collection and recovery. Everything landed in local storage before it was allowed to depend on the network.
Tracking Pipeline
Device GPS flows through the native location layer into the Flutter application, then into local storage, a sync queue, and the backend, and only then into the route and operations views.
Reliability Stack
Background execution, scheduled jobs, restart logic, native Android integration, battery-aware sampling, and manufacturer testing each covered a different way the process could die.
Offline-First Sync
Capture, store locally, attempt sync, mark success, and keep the record if the call fails. Background and batch retries clear the queue. Local rows are removed only after acknowledgement.
Map & Integrity
OpenStreetMap draws the journey, markers, and points of interest. Location streams are checked for unrealistic jumps so spoofed or broken fixes are not treated as completed field work.
Screen Walkthrough
The product, in the order a user moves
Production screens from the live apps, framed as a journey rather than a pile of captures. Follow them from the first screen to the last action.
Follow the journey →
Deep Dive
Key Technical Implementations
Detailed breakdown of core features addressing complex mobile engineering requirements.
Background Location That Survives the OS
Native Android where a Flutter lifecycle stops being enough
The product had to keep a location stream going after the app was backgrounded, including a target of roughly 72 hours on supported devices. I split the work: Flutter kept the workflow, and native Android (platform channels, background execution, and scheduled recovery) kept the collector alive when a manufacturer ROM tried to stop it. Samsung, Xiaomi/Redmi, Huawei, and other customized builds were part of the test matrix, not an afterthought.
- Native location collection behind platform channels
- Scheduled jobs and restart logic when the process is killed
- Work-hours consent so tracking is tied to an active field session
A Day Reconstructed, Not Just a Pin
Start, stops, dwell, and the path between them
Each fix joined a chronological journey: where the day started, where the person is now, which stops they made, how long they stayed, and which leg is still planned. OpenStreetMap is the canvas. Route analytics then rolls those days up (distance, field hours, visits) so a manager can read a week instead of a single coordinate.
- Live route with completed stops, current position, and planned legs
- Dwell and active time separated from raw point spam
- Historical routes compared across days for one employee and territory
Points of Interest on the Live Map
Movement associated with customers, leads, and appointments
A trail only matters if it lines up with the work. The live map places field staff against customer and lead locations, shows who is at a site, and opens the current task and next appointment from the person, so proximity is an operations fact, not a decorative marker.
- Personnel, customer sites, and route segments on one map
- At-location state with last update and distance to the next stop
- POI proximity used to connect presence with assigned visits
Leads, Tasks & Appointments on the Same Trail
Where they were, what they were supposed to do, what they did
Location was not a separate admin tool. The same session carries today’s visits, tasks, and appointments: distance to each stop, in-progress or pending state, and a geofence check when they arrive. Completing the work and proving the visit live in one list.
- Visits, tasks, and appointments in one daily queue
- Geofence verification on arrival, not a manual “I was there” note
- Navigate and complete actions attached to the assigned location
Attendance That Knows the Site
Check-in, working time, and the route underneath
Attendance sits in the same workflow as tracking. A check-in can be verified against a known site, working time is visible against the shift, and the day’s distance, visits, and tasks sit under that status, so presence and activity are one record.
- Check-in and check-out with site-level geofence verification
- Working time against the planned shift
- Daily distance, visits, and tasks generated from the same location stream
Offline Queue & Location Integrity
Keep the points, and do not trust an impossible jump
Field coverage is unreliable, so the app writes locally first and syncs when it can. Failed uploads stay queued; local rows are cleared only after the server accepts them. Because those points also justify attendance and visits, the stream is checked for abnormal deviations. A sudden, unrealistic move is a signal to review, not an automatic completed visit. Battery level, movement, and network decide how often to sample, so an all-day shift does not require maximum-rate GPS.
- Local queue with retry, including a visible pending-sync state
- Suspicious movement flagged instead of accepted as field activity
- Sampling adjusted for battery, motion, precision, and connectivity
Hurdles & Solutions
Technical Challenges & Trade-Offs
Real production obstacles overcome during engineering and deployment.
Long-running background tracking after the user leaves the app
Combined native Android location execution, platform channels, background jobs, and recovery/restart so collection did not depend on a foreground Flutter session.
Supported devices could keep a field day, and longer windows up to roughly 72 hours, without the employee babysitting the app.
Android OEMs apply different background and battery kills
Tested and configured against Samsung, Xiaomi/Redmi, Huawei, and other customized ROMs instead of treating stock Android as the only runtime.
Tracking behavior was designed around real device policy differences, not a single lab phone.
Continuous GPS would drain a phone before the shift ended
Adjusted collection frequency from battery level, movement, required precision, and network availability rather than sampling at the highest rate all day.
Accuracy, battery, and network use stayed in the same tradeoff instead of maximizing one of them.
Field routes pass through weak or missing connectivity
Persisted location and activity locally, retried in the background, and removed local records only after a successful sync acknowledgement.
A dropped network delayed upload. It did not delete the day’s trail.
Location data drives attendance, so fake GPS is an integrity problem
Analyzed the location stream for abnormal deviations and unrealistic position changes and surfaced those as suspicious events.
Spoofed or broken fixes could be reviewed instead of silently counting as a customer visit.
Outcomes
Impact & Production Outcomes
LBS turned field reporting into a location-aware operations record for Z&Z. The meaningful result was not a prettier map. It was a tracking pipeline that kept working in the conditions field phones actually see: background kills, manufacturer battery policy, weak networks, and location data that has to be trustworthy enough to stand behind a visit and an attendance mark.
Location, route, visits, tasks, appointments, and attendance in one workflow
Native recovery so tracking is not limited to an open Flutter screen
Queue retained points through outages and cleared them after acknowledgement
Unrealistic movement flagged before it was treated as completed work
Technology Breakdown
Tools, Frameworks & Libraries
Categorized technical stack employed to achieve reliability, performance, and store compliance.