Remember what is in the trash, and add a screen to restore from it

The staged-delete work left a hole. The undo handle lived in BrowserUiState, so a delete from an earlier session was unreachable even though the files were sitting on the volume; and because nothing on disk recorded which folder an item came from, not even the user could put one back by hand with confidence. Adding a Trash screen alone would not have fixed it: the recovery data did not survive the process. So the origin is now written at delete time.

data/ gains its first persistence: a SQLite index (staged path, original path, name, type, size, timestamp). SQLite rather than Room because an annotation processor is a large addition to this build for one table and three queries, and behind a TrashIndex port so domain/Trash keeps no Context while the tests drive it with a map and the real one is still tested against real SQLite. New Trash entry in the overflow menu lists batches and restores a whole one.

The index is an index, not the truth: the staged files are the truth, and the two can disagree if a user empties the folder by hand or pulls a card. Reconciled both ways - restorableFrom drops entries whose file has gone, purgeExpired forgets entries whose folder has gone and sweeps folders no entry mentions - and rows are written after the move, so a crash leaves an unindexed folder (harmless, swept) rather than an entry that could never restore. Verified on hardware: delete, force-stop, relaunch, restore.

Also corrects the docs where they claimed input swipe x y x y 900 is delivered as a plain tap on MIUI. It does open the selection bar - it was driven that way - but it has also landed as a tap, so it is flaky rather than impossible.
This commit is contained in:
2026-10-15 10:25:37 +02:00
parent d1bc61e717
commit 667a85f80c
16 changed files with 758 additions and 22 deletions
+7 -4
View File
@@ -50,10 +50,13 @@ An udev rule widening the mode for Android vendors fixes it
## Not verified, and why
- **Long-press multi-select via adb.** `input swipe x y x y 900` is delivered as a plain
tap on this MIUI build, so the selection action bar (and therefore compress/extract from
the UI) could not be driven from the host. The archive engine itself is covered by
end-to-end JVM tests, including a zip-slip archive. **Worth a manual pass.**
- **Long-press multi-select via adb: it works, but not every time.** `input swipe x y x y 900`
*does* open the selection action bar on this MIUI build — it was driven that way to reach
Delete, Rename and Compress — but the same gesture has also landed as a plain tap, which
opens the row instead of selecting it. So the bar is reachable from the host, and yet
compress/extract from the UI is still worth a manual pass rather than trusted to a scripted
gesture. The archive engine itself is covered by end-to-end JVM tests, including a zip-slip
archive.
- **The SAF folder-picker round trip.** Driving the system picker and granting a tree was
not attempted; the code path is unit-tested against a stand-in `DocumentsProvider`.
- **Image viewer and thumbnails.** Verified on the AVD in M4/M5; not repeated on the phone.