Design Maps & Live Location Tracking

FusedLocationProviderClient (FLPC) is Google's smart location provider that internally combines GPS, Wi-Fi positioning, Bluetooth beacons, and cell towers, choosing the best available source for the requested accuracy and battery trade-off. Raw LocationManager with GPS_PROVIDER only uses satellites — it's slow to get a fix (cold start can take 30–60 s), drains battery constantly, and fails indoors. FLPC gets a fix in ~1–2 s because it uses the last known location from Wi-Fi as an immediate result while GPS warms up. For consumer apps, always use FLPC over raw LocationManager.

PRIORITY_HIGH_ACCURACY enables GPS hardware — it can achieve 3–5 metre accuracy but uses significant battery. Use it when precise turn-by-turn navigation or real-time driver tracking is needed (active trip). PRIORITY_BALANCED_POWER uses Wi-Fi and cell towers only — no GPS chip activated. Accuracy degrades to 50–100 metres but battery impact is minimal. Use it when you just need city-block precision, e.g., checking if the driver is in the general area. For the passenger app just showing their own location as a blue dot, BALANCED is sufficient. Only activate HIGH_ACCURACY when the user is actively navigating.

Android aggressively kills background processes to conserve battery. A plain background service will be killed within minutes. A Foreground Service with a persistent notification signals to the OS that this is intentional, user-visible, ongoing work — it has much higher priority and is rarely killed. Since Android 8, location updates in a background service (no foreground promotion) are throttled to once per hour. For real-time driver tracking at 2 s intervals, a Foreground Service is mandatory. Declare android:foregroundServiceType="location" in the manifest (required since Android 10) and call startForeground(id, notification) within 5 seconds of service start.

GPS fixes arrive at 1–5 second intervals. Without animation, the marker teleports — jarring UX. Use ValueAnimator.ofFloat(0f, 1f) with the animation duration matching the update interval (e.g., 1 000 ms). In addUpdateListener, linearly interpolate the latitude and longitude: lat = startLat + (endLat - startLat) * t. Update marker.position on each frame. Also interpolate marker.rotation for the bearing — but handle the 359° → 1° wrap: compute the delta, if >180 subtract 360, if <-180 add 360. The LinearInterpolator gives a constant-speed glide that matches expected car movement.

Introduced in Android 10, ACCESS_BACKGROUND_LOCATION is a separate runtime permission from ACCESS_FINE_LOCATION. It grants the app the ability to receive location updates when the app is not visible to the user. You must request FINE first, and only after it's granted can you request BACKGROUND. On Android 11+, requesting both in the same dialog is not allowed — the system forces the user to go to Settings to grant background location (no runtime dialog). The Play Store also reviews background location use and requires a compelling justification. For driver apps, the justification is clear: the driver's location must update while they navigate. Always use it minimally and explain the benefit to the user before requesting.

Register GoogleMap.setOnCameraMoveStartedListener. The callback receives a reason integer. REASON_GESTURE means the user is physically panning/zooming — set a isFollowing = false flag. REASON_API_ANIMATION means your own code called animateCamera() — don't change the flag. When a new driver position arrives: if isFollowing is false, skip animateCamera() but still animate the marker. Show a "Re-center" FAB button that sets isFollowing = true and calls animateCamera() to snap back to the driver. This pattern matches the Uber/Ola UX exactly.

You register a Geofence with a circular region (center + radius) and transition types (ENTER/EXIT/DWELL). The GeofencingClient passes this to Google Play Services, which monitors the device's position against all registered geofences at the OS level — using low-power cell/Wi-Fi positioning, not GPS. When a transition is detected, it fires a PendingIntent to your BroadcastReceiver or IntentService. This is far more battery-efficient than polling: your app code doesn't run at all during monitoring. The OS handles everything and only wakes your app when the boundary is crossed. Remove the geofence immediately after the event to avoid lingering monitoring.

Fetch the route from the Google Directions API (or a Routes API equivalent) as a list of LatLng waypoints. Draw it with map.addPolyline(PolylineOptions().addAll(points)). Store the Polyline reference. As the driver moves, call polyline.remove() and re-draw with the updated points — or more efficiently: trim the waypoints list by removing all points before the driver's current position. Find the closest point in the list to the driver's LatLng, then call polyline.points = originalPoints.drop(closestIndex). This gives the appearance of the road "disappearing behind" the driver without a full redraw.

setMinUpdateDistanceMeters(5f) tells FusedLocation to suppress callbacks if the device has moved less than 5 metres since the last update, even if the time interval has elapsed. This filters out GPS jitter — when a driver is stationary (waiting at a signal), the GPS chipset still oscillates slightly, generating false position updates. Without this filter, you'd upload hundreds of tiny "moves" per minute to your backend, burning bandwidth and battery. Setting a threshold of 5–10 metres ensures only meaningful movement triggers a callback and a server upload. Combine with the time interval to get both time-based and distance-based filtering.

Implement exponential backoff in the WebSocket manager: on onFailure() or onClosing(), schedule a reconnect after min(baseDelay * 2^attempt, maxDelay) milliseconds, with jitter (e.g., add a random 0–1 s). Show a UI indicator ("Reconnecting...") while disconnected. Stop showing the driver marker moving — optionally grey it out. On reconnection, request a fresh snapshot from the server (last known position + ETA). Cap the retry counter; after N consecutive failures, show "Unable to track — check connection" and offer a manual retry button. On Android, also listen to ConnectivityManager network callbacks to trigger reconnection immediately when the network comes back.

Use ClusterManager from the Maps Android Utils library. It groups nearby markers into a single cluster marker showing the count, and splits them apart as the user zooms in. For updating positions: maintain a Map<driverId, Marker>. On each position update, call marker.position = newLatLng directly rather than removing and re-adding — this is O(1) and preserves the cluster grouping. For very high volumes (100+ drivers), consider only rendering drivers within the visible map bounds: use map.projection.visibleRegion.latLngBounds.contains(driverPos) to filter before adding to ClusterManager. Off-screen markers waste GPU memory.

Dead reckoning extrapolates the driver's position between GPS fixes using last known speed and bearing. If a fix arrives at time T with speed 14 m/s and bearing 90°, and the next fix is delayed by 1 second, you can estimate the position as newLat ≈ lastLat + (speed * cos(bearing) * dt / R). This makes the marker move continuously rather than jumping in steps. A Kalman filter combines dead reckoning estimates with actual GPS measurements, weighing each by its uncertainty, to produce a smooth, filtered track. Used in Google Maps navigation to keep the blue dot moving smoothly between 1 s GPS fixes. For an interview, describe the concept and the trade-off: extra computation for smoother UX.

Use the Google Maps SDK's MapStyleOptions. Create a JSON style file in res/raw/map_style.json (generate it at mapstyle.withgoogle.com). Apply it with: map.setMapStyle(MapStyleOptions.loadRawResourceStyle(context, R.raw.map_style)). Call this inside onMapReady() after you have the GoogleMap reference. For dark mode: detect resources.configuration.uiMode and UI_MODE_NIGHT_MASK == UI_MODE_NIGHT_YES and load a dark style JSON. The style is client-side — no server changes needed. Commonly used: hide POI labels to reduce visual noise during navigation, change road colors to brand palette.

Three cases after ActivityResultContracts.RequestPermission(): (1) Granted — proceed normally. (2) Denied but not permanently — show a rationale dialog explaining why location is needed ("We need location to show your position on the map"), then re-request. (3) Permanently denied (shouldShowRequestPermissionRationale() returns false) — show a dialog with "Open Settings" that launches Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS) so the user can manually enable it. Never request the permission in a loop. Show the feature as disabled with a CTA rather than crashing. For background location on Android 11+, the user is always directed to Settings — prepare UI for this flow.

Two approaches. (1) Google Maps SDK offline areas: the SDK itself supports caching tiles for a selected geographic region — the user downloads a rectangular area in advance. This works automatically without custom code. (2) Custom TileProvider: implement TileProvider.getTile(x, y, zoom) — check a local tile cache (LRU disk cache), return cached bytes if present, else fetch from tile server and cache. Use MBTiles format for structured offline storage. Register with map.addTileOverlay(TileOverlayOptions().tileProvider(yourProvider)). For navigation apps: pre-download tiles for the route corridor ahead of time using the route bounds to determine which tiles to cache.

fusedClient.lastLocation returns a Task that resolves with the most recently known location from FusedLocation's cache — it's instant (no GPS activation) but can be null if no location has been acquired recently (fresh reboot, no recent app used location). Use it for: showing an initial map position before live updates start ("Where was I last?"), pre-populating a pickup address field, or a coarse check to see if the user is in a service area. Don't use it as the main tracking mechanism — it's stale by design. Start requestLocationUpdates() for live data and use lastLocation only as a quick first position while the live stream warms up.

Several strategies together: (1) Adaptive interval: reduce frequency when stationary (setMinUpdateDistanceMeters) and increase only when moving fast. (2) Trip-state-based priority: drop to PRIORITY_BALANCED_POWER when idle, only switch to HIGH_ACCURACY during an active trip. (3) Server-side filtering: send location only when delta exceeds a threshold — client-side minUpdateDistanceMeters does some of this, but explicit client filtering before the WebSocket send adds another layer. (4) Batch uploads: if the server allows it, buffer 3–5 fixes locally and send as a batch — fewer network radio activations. (5) Request the driver's device to be excluded from Doze mode only during active trips via PowerManager.isIgnoringBatteryOptimizations() and guide the user to whitelist the app.

Multiple signals. (1) location.isMock (API 31+) / location.isFromMockProvider() (deprecated but works pre-31) — returns true if a mock location app is active. (2) Cross-check GPS location against network/cell location: if they consistently disagree by >1 km, flag as suspicious. (3) Velocity sanity check: if the position jumps 10 km in 1 second, that's physically impossible. (4) Sensor fusion: compare GPS bearing with accelerometer/gyroscope data — a spoofed GPS that "teleports" won't match inertial sensor data. (5) Check if developer options "Allow mock locations" is enabled: Settings.Secure.getInt(cr, Settings.Secure.ALLOW_MOCK_LOCATION). Flag these signals and escalate to a server-side anti-fraud system rather than blocking locally — the driver could appeal if flagged incorrectly.

map.isMyLocationEnabled = true enables the built-in blue dot showing the user's current position, plus a "My Location" button in the top-right corner. It requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION to be granted at runtime — if you enable it without the permission, it throws a SecurityException. Always check ContextCompat.checkSelfPermission() before setting it to true. The SDK handles all the FusedLocation calls internally — you don't need to manually manage your own location updates for the blue dot. Use it for the passenger's position; use your own marker + FusedLocation for the driver's position that needs server upload and custom animation.

Two approaches. (1) Server-side: the server receives each driver position update and computes remaining distance using the Directions API or a routing engine (OSRM). It pushes the updated ETA back via WebSocket to the passenger. This is the standard approach — routing is expensive and best done server-side. (2) Client-side: the passenger app detects deviation by checking if the driver's position is >N metres off the drawn polyline. If deviated beyond a threshold, request a new route from the Directions API from driver's current position to destination, redraw the polyline, and recompute ETA from the new route's duration field. Debounce rerouting — don't trigger on every minor deviation, wait until the driver is consistently off-route for 10+ seconds.