n0tst3v3andClaude Opus 5
97c1e48e91
Sends X-Device-ID on every upload so the server can attribute sightings to the phone that recorded them; it now rejects uploads without one. Prefers Settings.Secure.ANDROID_ID: it survives reinstalls, costs nothing to read and needs no permission. It is not always trustworthy though - null before first boot completes, and a known family of builds all report the same constant - so those readings are rejected outright rather than repaired, and a random UUID is generated and kept instead. Guessing at a malformed reading would produce an identifier that changes between reads, which is worse than falling back. The fallback UUID is stored encrypted under an AES-GCM key held in the AndroidKeyStore, so the key material never enters the app process and cannot be lifted out of a backup or off a rooted device. androidx.security's EncryptedSharedPreferences does exactly this, but it needs AndroidX and API 23; this project builds in AIDE with no dependency resolution and minSdk 14, so the same construction is done directly against the platform Keystore. The Keystore calls sit behind SDK_INT checks and are never resolved below 23, where the identifier is kept in memory for the process lifetime rather than written out in the clear. A stored value that will not decrypt - key cleared, or restored onto another device - yields a new identity rather than a crash. The old one is genuinely unrecoverable at that point. Upload errors now surface the server's "error" field instead of the raw JSON envelope, so a rejected device ID reads as a sentence. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
