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>
