Non-Functional Requirements (NFRs)

Because Speed Assist is a continuous-tracking app targeting safety and potentially fleets, Non-Functional Requirements are just as critical as the features themselves.

1. Battery & Resource Optimization

Continuous GPS polling is the #1 reason users uninstall driving apps.

• Adaptive Polling: Do not request high-accuracy 1-second GPS updates if the user is stationary for > 5 minutes. Downscale the request interval dynamically.
• Wakelocks: Use ForegroundService properly with clear notifications rather than raw CPU Wakelocks whenever possible. Release resources in onDestroy() or onStop().
• Auto-Start Efficiency: Leverage :speed-autostart (Google Play Services IN_VEHICLE transition) for zero-friction background trip detection instead of continuous CPU wakelocks, saving massive battery power while waiting for trips to start.

2. Location & Privacy Compliance (Crucial)

• Permissions: Always handle permission degradation gracefully. If ACCESS_BACKGROUND_LOCATION is denied but foreground is granted, the app should still function while open.
• Dialogs: Adhere strictly to Google Play policies by showing explicit "Prominent Disclosure" rationale dialogs before requesting background location. (See dialogs.showLocationPermissionRationale).

3. Performance & Stability

• Compose Recomposition: Avoid passing unstable data classes or heavily mutating lists directly to Compose functions. Use remember and key blocks. Monitor for "jank" caused by excessive recomposition in HUD modes.
• GPS Jitter (EMA & Schmitt Trigger): Raw GPS data is noisy at low speeds. The SDK implements Exponential Moving Average (EMA) smoothing and Dual Schmitt Trigger Hysteresis (with asymmetric alert and reset thresholds) to eliminate velocity jitter and prevent alarm fluttering at boundary limits.

4. Background Resiliency

• OS Kill Prevention: Android (Doze mode) aggressively kills background apps. Always utilize a highly optimized ForegroundService with a persistent, non-dismissible notification to prevent the OS from silently killing the app during a drive.

5. Safety & Distraction Optimization (Legal NFR)

• Voice & Audio First: The UI must not distract the driver. Once driving begins, the screen should require zero interaction. Rely on audio escalation and high-contrast, glanceable UIs (HUD mode).
• Drive Mode Lockout: Consider disabling complex UI interactions or typing while the vehicle is in motion to comply with hands-free and distraction laws.
• HUD Mode: The HudDisplay component enforces distraction safety by utilizing a high-contrast, pure OLED black (#000000) background intended strictly for windshield reflection during night driving, eliminating peripheral glare.

6. Hardware Heterogeneity Handling

• Calibration Offset: Different phones have varying GPS chip qualities, and car speedometers are intentionally calibrated to show faster speeds than reality. Allow users to manually adjust the app's speed calculation by a percentage offset to match their dashboard perfectly.

7. App Size & Offline Capability

• Zero Cloud Reliance: The core speed tracking and alerting must function 100% offline without an internet connection. Do not rely on cloud processing for real-time safety critical alerts.
• Lightweight Footprint: Total download size and runtime memory footprint must both remain < 5 MB.

8. SDK Modular Architecture (B2B Ecosystem)

Per the research failure analysis, the consumer app market is tough, and B2B SDK licensing is the future.

• Core Independence: The location tracking and speed calculation logic (TelematicsEngine, SpeedWatcher, ISpeedRepository) in :speed-core is completely decoupled with zero UI or ad dependencies.
• Modular Mindset: Features are isolated across :speed-core, :speed-ui, :speed-overlay, :speed-autostart, and :speed-bom with minimal public API surface.

9. App Startup & Launch Weight

• Lightweight Initialization: The app must open instantly. Do not initialize heavy SDKs, database migrations, or complex location requests synchronously on the main thread during Application.onCreate() or Activity.onCreate(). Defer non-essential initializations until after the first frame has rendered.