Every CI build previously minted a fresh debug keystore, so each release failed
to install over the last (signature mismatch) — forcing an uninstall and loss of
the on-device proxy token. Commit a fixed debug.keystore (a debug key is
non-secret; password is the well-known "android") and point the debug
signingConfig at it, so CI and local builds sign identically and updates install
in place. No functional app changes.
versionCode 17 -> 18, versionName 0.5.1 -> 0.5.2.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015jgJnzMr2bdNuWcDX2xRUR
- Larger main-screen map circle (220 -> 300dp) wrapped in a threat-color ring
(green/yellow/orange/red while scanning, gray idle).
- User position renders as a ⌖ crosshair; map geodata color-coded by source
(Flock/DeFlock red, Waze blue, Citizen purple) in both the main circle and
the floating overlay bubble.
- START button moved to the bottom of the screen.
- README brought current: COMMERCIAL source + overlay documented, Waze-via-proxy
and the CI release pipeline described, architecture/permissions/changelog
updated, build reqs corrected to JDK 17 / SDK 35.
versionCode 16 -> 17, versionName 0.5.0 -> 0.5.1.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015jgJnzMr2bdNuWcDX2xRUR
Re-adds the WAZE detection source (removed in v0.1.5 when Waze reCAPTCHA-gated
its live-map endpoint). Data comes from OpenWeb Ninja's hosted Waze feed, but
the paid API key never ships in the app: a Caddy reverse proxy at
api.blackflagintel.com injects the key server-side, and the app authenticates
with a scoped X-App-Token entered in Settings and stored encrypted via the
Android Keystore (SecureStore). No credential is baked into the APK.
- scan/WazeClient.kt, scan/WazeScanner.kt: proxy client + 4-min poller,
200-alert page + client-side POLICE filter, 45-min freshness window.
- data/settings/SecureStore.kt: Keystore AES/GCM at-rest store (no dependency).
- Settings: encrypted wazeProxyToken + "Waze police feed" token field.
- ConfidenceEngine.scoreWaze, SourceHealth/DetectionSource WAZE, service wiring.
- Removes the BuildConfig/local.properties key baking entirely.
versionCode 15 -> 16, versionName 0.4.0 -> 0.5.0.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015jgJnzMr2bdNuWcDX2xRUR
Stale items corrected:
- Architecture file list referenced WazeClient.kt and WazeScanner.kt
(deleted) and CDN-tile DeflockClient (now Overpass POST). Added the
missing CitizenClient/CitizenScanner/SourceHealth/ThreatLevel files.
- Permissions table said "DeFlock CDN + Waze API" — now Overpass +
Citizen. Added VIBRATE row.
- Settings section listed Waze instead of Citizen; missing the new
Vibrate-on-escalation toggle and Restart-to-apply button.
- Status said "Phases 1-5 complete as of v0.1.0" — bumped to v0.1.7
with a per-version changelog of what landed.
Added:
- Hero paragraph mentions notification + vibration alerting.
- New "How alerts work" section explaining notification updates,
vibration cadence, drill-down sheet, and Open-in-Maps.
- Idle-visual note in scoring section.
- START_NOT_STICKY note in architecture.
- Open-app-settings recovery note in permissions section.
Waze's reCAPTCHA gating on live-map/api/georss has no clean mobile
workaround, and the Citizen source added in v0.1.4 covers the same
threat model with better data. Keeping a permanently-failed source
visible was UI clutter — drop it.
Removed:
- scan/WazeClient.kt and scan/WazeScanner.kt (deleted)
- WAZE from DetectionSource enum
- waze flow from SourceHealth (+ flowFor/record/reset cases)
- WazeObservation + scoreWaze + W_WAZE_POLICE from ConfidenceEngine
- wazeEnabled from Settings (+ KEY_WAZE)
- WAZE row from SettingsScreen
- wazeScanner from DetectionService
Renamed (Citizen now owns the proximity slider that Waze used to share):
- Settings.wazeProximityM → citizenProximityM
- Settings.setWazeProximityM → setCitizenProximityM
- KEY_WAZE_PROX → KEY_CITIZEN_PROX
- DEFAULT_WAZE_PROX → DEFAULT_CITIZEN_PROX (still 500)
- SettingsScreen "Waze alert distance" → "Citizen alert distance"
Existing users will see the slider reset to 500 m default since the
SharedPreferences key changed.
versionCode 5 → 6, versionName 0.1.4 → 0.1.5.
Waze remains gated behind 2025/2026 reCAPTCHA on live-map; added Citizen
as a working alternative for police-presence signal. Citizen pulls from
911 + scanner traffic, returns rich incident data (lat/lon, timestamp,
severity level, responding precinct, title), and has no auth or
rate-limit gating.
New scan/CitizenClient.kt:
- GET /api/incident/trending (bbox query → list of incident ids)
- GET /api/incident/{id} (full detail per id)
- Sealed TrendingResult so the scanner can surface 4xx via SourceHealth.
New scan/CitizenScanner.kt:
- 60s poll interval, 30-min freshness window
- Per-id detail cache for the lifetime of a start/stop cycle —
incidents are immutable, so each is fetched at most once per session
- Title regex filter: drops pure fire/medical events that don't imply
police presence; retains them when the title also names police action
- Submits to the shared DetectionStore as DetectionSource.CITIZEN
ConfidenceEngine.scoreCitizen:
- Base 55 (matches the old W_WAZE_POLICE weight)
- +5 if level >= 2 (Citizen's own severity)
- +5 if title contains police-action keyword (police/officer/arrest/
swat/tactical/raid/pursuit/stop/search warrant)
Settings: new citizenEnabled toggle (default on); UI row in
SettingsScreen. SourceHealth has a new flow for CITIZEN. DetectionService
starts the scanner alongside the others when location is available.
Continued investigation of Waze / Google Maps police APIs:
- Waze SDK (hewliyang/waze-traffic-api): wraps the same blocked endpoint
- ddd/google_maps reverse-engineering: locations only, no incidents
- Google Maps Platform: no public incidents API (just displays Waze data internally)
- TomTom Traffic Incidents: traffic-only, no police presence
- Waze for Cities partner feed: real but requires being a city/police agency
versionCode 4 → 5, versionName 0.1.3 → 0.1.4.
The cdn.deflock.me CDN is gated behind Cloudflare bot mitigation that
mobile HTTP clients can't pass. The live deflock-app Flutter client
abandoned that path; it POSTs Overpass-QL queries directly to
overpass.deflock.org (with overpass-api.de as a fallback). Verified by
hitting the same endpoint from curl — 22 ALPRs returned for the
Springfield VA bbox, matching the user's screenshot of the working app.
DeflockClient rewrite:
- POST [out:json][timeout:25];(node[surveillance][type=ALPR](bbox););out body;
- 5 km half-width bbox around the user
- 24h on-disk cache keyed by 0.05° grid cell (revisits don't refetch)
- Returns sealed FetchResult: Success(points) | Failed(reason)
DeflockScanner update:
- Replaces 20° tile concept with distance-based refetch (1.5 km threshold)
- Records SourceHealth on each fetch outcome
Waze: reCAPTCHA gating confirmed. WazeClient.fetchPoliceNear now returns
sealed FetchResult; WazeScanner records SourceHealth.FAILED with
"Upstream blocked (HTTP 403)" so the user sees why no Waze data is
flowing instead of silent zeros.
New fusion/SourceHealth.kt — per-source MutableStateFlow registry,
record(source, ok, message) + reset() called on service start/stop.
UI: SourceRow in the bottom-sheet drill-down now shows the health
message in orange when status = FAILED instead of "no detections".
versionCode 3 → 4, versionName 0.1.2 → 0.1.3.
KaraZajac