Development Roadmap

Outcome

Project setup, CI/CD, and basic app scaffolding.

Submilestones

• M0.1Repository setup and Gradle configuration
• M0.2CI/CD pipeline (GitHub Actions)
• M0.3Code signing and release workflow
• M0.4Base Android project structure
• M0.5Navigation scaffolding (Jetpack Compose)
• M0.6Theme and design system tokens
• M0.7Debug build variants and logging
• M0.8Unit test scaffolding
• M0.9Instrumented test scaffolding
• M0.10Basic settings screen

Outcome

Prove the VPN service can run stably on Android with lifecycle management, conflict handling, and kill switch.

Submilestones

• M0.11.1VpnService lifecycle (start, stop, crash recovery)
• M0.11.2Foreground notification for VPN active state
• M0.11.3Network traffic byte counters (up/down)
• M0.11.4Conflict detection with other active VPNs
• M0.11.5Kill switch via always-on VPN lockdown
• M0.11.6User consent flow for VPN permission

Technical approach

Use Android VpnService API. Implement a foreground service with persistent notification. Handle VPN revocation and conflicts via BroadcastReceiver. Kill switch uses Android native always-on VPN with lockdown mode.

Acceptance criteria

• ●VPN starts and stops cleanly 50 consecutive times without crash
• ●Kill switch blocks all traffic when VPN service is stopped unexpectedly
• ●Conflict with another VPN is detected and surfaced to the user
• ●Battery impact under 5% in 24-hour test

Outcome

Encrypted local storage, incident logging schema, and privacy controls UI.

Submilestones

• M1.1Encrypted SQLite database (Android Keystore derived key)
• M1.2Incident log schema and CRUD operations
• M1.3Privacy Center UI: retention controls
• M1.4Data purge functionality
• M1.5Sanitized export to JSON
• M1.6Settings persistence (SharedPreferences + encrypted DB)

Technical approach

SQLCipher for encrypted SQLite. Room as the ORM layer. Privacy Center as a dedicated settings screen. Export strips PII (device IDs, account emails, exact timestamps) and outputs a JSON file via Android share intent.

Acceptance criteria

• ●Database survives app restart and OS kill
• ●Export JSON does not contain device serial, Google account, or exact timestamps
• ●Delete All removes all rows and resets baseline state
• ●Retention policy automatically removes records older than configured days

Outcome

Passive metadata collection and first statistical baselines.

Submilestones

• M2.1Network flow sensor (destination IP, port, request count, timing)
• M2.2Permission usage tracker
• M2.3App install source detector (Play Store vs sideloaded)
• M2.4Background activity monitor (wake locks, foreground services)
• M2.5Baseline calculation v0 (rolling window statistics)
• M2.6Basic drift scoring (z-score based)
• M2.7Monitor Mode toggle and debug screen

Technical approach

Network sensor reads from VPN tunnel packet headers (IP + port only, no payload). Permission tracker uses PackageManager queries on a schedule. Baselines calculated with 7/14/30-day sliding windows, storing mean, stddev, and percentiles per metric per app.

Acceptance criteria

• ●Sensor captures network metadata for all apps routing through VPN
• ●Permission changes detected within 60 seconds
• ●Baseline established after 7 days of data for a given app
• ●Drift score increases when simulated anomalous traffic is injected

Outcome

Automatic containment of apps that exceed drift thresholds.

Submilestones

• M3.1VPN routing engine with per-app allow/block rules
• M3.2Containment trigger from drift score threshold
• M3.3Incident notification explaining what changed
• M3.4Review UI for contained apps (allow, keep blocked, permanently block)
• M3.5App update grace period (learning window after version change)
• M3.6Protect Mode toggle in settings

Technical approach

VPN packet filter checks app UID against containment list. Drift threshold is configurable per mode. Notifications use Android notification channels with expand-to-review action. Grace period resets baseline window on detected version change.

Acceptance criteria

• ●App exceeding drift threshold is contained within 30 seconds
• ●Contained app cannot make outbound network connections
• ●User can allow or keep blocked from notification or review screen
• ●App update triggers grace period and suppresses enforcement for configured duration

Outcome

Improved drift detection accuracy with multi-dimensional scoring and user feedback.

Submilestones

• M4.1Multi-dimensional scoring (network + permissions + behavior combined)
• M4.2Context-aware weighting (time-of-day, connection type)
• M4.3Confidence intervals for anomaly significance
• M4.4Version-aware baseline transitions
• M4.5User feedback loop (mark as false positive / legitimate)
• M4.6Per-app scoring weight persistence

Technical approach

Weighted composite score across all sensor dimensions. Context features (time bucket, wifi vs cellular) added as conditioning variables. User feedback adjusts per-app scoring weights over time.

Acceptance criteria

• ●False positive rate below 10% in controlled testing
• ●User feedback reduces repeated false positives for the same app
• ●Time-of-day patterns correctly suppress expected nighttime backup activity

Outcome

Polished app ready for public beta on Google Play.

Submilestones

• M5.1Onboarding flow explaining modes and permissions
• M5.2In-app help and documentation
• M5.3Performance optimization (battery, memory, startup time)
• M5.4Crash reporting (opt-in only)
• M5.5Play Store listing, screenshots, and marketing assets
• M5.6Beta testing program via waitlist invitations

Technical approach

Onboarding as a multi-step wizard. Performance profiling with Android Studio profiler. Crash reporting via opt-in Firebase Crashlytics (no PII collected). Beta distribution via Play Store internal testing track.

Acceptance criteria

• ●New user can complete onboarding and reach Monitor Mode in under 2 minutes
• ●Battery impact under 5% in 24-hour usage
• ●App starts in under 2 seconds on mid-range device
• ●Crash-free rate above 99% in internal testing