Al-Dalilah (Desert Compass)
Offline Desert Navigation & GIS Engine Overhaul
Developer Note: Project Context & Continuous Learning Journey
Relationship to the Other Al-Dalilah Entry:
This entry covers the core offline mapping and navigation overhaul of the Al-Dalilah application on Google Play. While the other project in my portfolio highlights the business modernization phase (SaaS architecture, in-app billing, and anti-abuse systems), this project focuses entirely on the deep-tech engineering challenge: converting the application into a 100% autonomous, offline vector GIS and routing platform for remote desert environments.
AI-Augmented Engineering & Continuous Learning:
Designing and building low-level GIS pipelines, memory-constrained vector tile parsers, and embedded graph search engines was initially well beyond my formal scope as a junior Android developer. Instead of stepping back, I embraced the challenge and actively leveraged AI coding agents as an architectural partner and sounding board. I used this collaboration as an intensive, hands-on learning opportunity to research, experiment with, and master completely unfamiliar domains: VSync-synchronized zero-allocation canvas loops, spatial branch-and-bound pruning algorithms, hardware sensor HAL synchronization, and lock-free thread concurrency in a production-grade system. This project significantly elevated my technical depth, proving how modern AI tools can accelerate deep learning and help bridge the gap to advanced systems engineering.
My Role on This Project
I was the Android Developer responsible for designing and implementing the offline mapping and navigation systems from the ground up:
- Integrated Mapsforge vector tile rasterization with osmdroid, backed by SQLite disk caching.
- Embedded BRouter for pure offline routing and built a 3-leg hybrid desert algorithm (sand departure ➔ road ➔ sand arrival).
- Developed a persistent location foreground service fully compliant with Android 14 requirements.
- Implemented a 4-stage GPS jitter and stationary drift filter to eliminate camp phantom mileage.
- Optimized canvas rendering with zero-allocation draw paths and graphicsLayer GPU execution for a locked 60 FPS.
- Structured Room Database with Write-Ahead Logging (WAL) and atomic transactions.
- Integrated Google Play Billing with dual-key server-backed trial verification.
Project Overview
Al-Dalilah is a native Android application built for navigation and trail recording in desert areas across the Arabian Peninsula where cellular connectivity is completely unavailable. Standard navigation apps fail in desert terrain because vehicles frequently travel over unmapped sand dunes to landmarks situated miles away from the nearest road, while GPS multi-path interference in stationary camps causes severe coordinate drift.
The application operates offline using preloaded .map vector files rendered on-device via Mapsforge and osmdroid. It features an embedded BRouter routing engine with custom profiles, a 3-leg hybrid routing algorithm linking off-road tracks to the nearest road network, a background location service with real-time jitter filtering, and GPX 1.1 file export.
Key Metrics
OFFLINE
Zero network calls for map rendering, POI search, or route calculations.
~60 FPS VSYNC
~60 FPS
Zero heap allocations in the canvas draw loop via Choreographer.FrameCallback.
32 MB HEAP CAP
32 MB
Strict BRouter memory ceiling preventing low-memory kills on 2GB RAM devices.
6-SECOND TIMEOUT
6s Limit
Graph exploration limit with automatic geodesic great-circle fallback.
Key Features
Technical Architecture
1. Offline Map Rendering & Memory Isolation
- •Mapsforge parses vector geometries from local .map files.
- •Tiles are rasterized on CPU and cached on disk using osmdroid's SqlTileWriter instead of filling the JVM heap with bitmaps.
- •Sensor polling runs on a dedicated HandlerThread("HeadingSensor") at ~50 Hz, synchronized to display VSync via Choreographer.FrameCallback with a 0.05° draw gate.
2. Embedded BRouter Engine & Spatial Branch-and-Bound
- •Runs in-process on a single-thread coroutine dispatcher (Dispatchers.Default.limitedParallelism(1)) to avoid CPU contention.
- •Memory allocation capped at 32 MB (rc.memoryclass = 32) with a 6-second timeout before falling back to direct geodesic Slerp lines.
- •Detour sanity guard: Rejects calculated routes that exceed 6× the direct geodesic distance to prevent snapping across impassable dune barriers.
3. Foreground Tracking & 4-Stage Jitter Filtering
- •TrackRecordingService runs as an Android 14 FOREGROUND_SERVICE_TYPE_LOCATION.
- •Maintains an in-memory CopyOnWriteArrayList<TrackPointEntity> so the UI map overlay can iterate and draw live points without concurrency locks.
- •Filters incoming fixes through: (1) Horizontal accuracy gate (<= 25m), (2) Stationary gate (< 0.8 m/s & < 4.0m), (3) Curvature/time gate (≥ 12° & ≥ 3m, or 10s heartbeat), and (4) Altitude EMA filter (0.2/0.8) with a 15 m/s vertical velocity clamp.
4. Database Architecture & Concurrency
- •SQLite configured via Room 2.8.0 with JournalMode.WRITE_AHEAD_LOGGING (WAL), allowing concurrent reads on the UI thread while the background service writes.
- •Relational integrity: tracks table links to track_points with ON DELETE CASCADE and a composite index (track_id, seq_index). Atomic batch saving wrapped in db.withTransaction.
Challenges & Learnings
Challenges
- •Local Snapping Defect — Standard BRouter snapped to the single closest road, often choosing a distant highway loop instead of a nearby track heading toward the destination. Solved by writing CandidateRoadExtractor to scan .rd5 segments directly.
- •Stationary GPS Drift — Parked vehicles accumulated 2 to 5 km of phantom distance over several hours. Solved by implementing the dual-condition stationary gate.
- •Compose Recomposition Lag — Feeding 60 Hz sensor heading into Compose state caused UI frame drops. Solved by reading heading strictly inside Modifier.graphicsLayer during the Draw phase.
- •BRouter Lifecycle Crash — Engine cleared expression contexts on completion. Solved by caching an independent BExpressionContextWay instance.
Learnings
- •Mastering Android Sensor HAL, coordinate remapping, and display rotation handling.
- •Designing spatial search algorithms with mathematical lower bounds to minimize mobile CPU overhead.
- •Zero-allocation canvas pipelines and isolating high-frequency hardware streams from UI composition trees.
- •SQLite WAL mode mechanics and concurrency handling between background services and 60 FPS rendering threads.
Gallery
