SqliteTrashIndex.onUpgrade emptied the table and recreated it, which was defensible only while nothing had shipped. It loses more than a cache: the staged files are still on disk, but only this table knows where they came from, so emptying it turns every staged delete into a permanent one, silently, with no error raised anywhere.
onCreate and onUpgrade now delegate to a create/upgrade pair on the companion, which is internal so a test can drive it against a throwaway database. Version 1 is the first version this app has shipped, so the loop has no steps yet and DATABASE_VERSION stays 1 — the shape is the point. When a version 2 arrives the step for version 1 becomes the ALTER TABLE plus backfill, or the copy-and-swap for a change SQLite cannot make in place. A version with no step now reports itself with error() rather than wiping the table, so the failure mode of forgetting a migration is a loud message instead of quiet data loss.
Two tests pin it against real SQLite: a bump to a version with no migration must report itself and leave the rows intact (the old code would have returned normally with an empty table, which is exactly what this guards), and an already current schema is a no-op. 206 JVM tests, lint clean.
SoftwareApp
9c39f15aa8