Write the release notes, the permission answers, and the video
verify / gate (push) Has been cancelled
verify / release (push) Has been cancelled

Play asks three separate things before a file manager may keep All files
access: the What's new copy, a justification for why SAF and MediaStore cannot
carry it, and a short video of the permission in use. Writing them exposed two
stale claims and one privacy problem, so those are fixed here rather than
repeated.

- docs/RELEASE_NOTES.md holds the Console field at 450/500 characters, measured,
  and the longer announcement. The first release's copy leads with the claim no
  competitor makes (no ads, no INTERNET permission) and then proves the app is
  still a file manager.

- docs/PLAY_RELEASE_CHECKLIST.md section 5 holds the declaration answer at
  490/500 characters. It argues from what the Storage Access Framework and
  MediaStore cannot do - one picked tree, no volume enumeration or whole-device
  hierarchy, no arbitrary non-media files - and never from performance, which
  Google's wording rejects. Both APIs are named as already used where they can
  be, so the argument is not that they are useless.

- docs/PERMISSION_VIDEO.md and store-assets/video hold a 19.7 s captioned video
  recorded on the release build. The home-screen segment is cut because its
  library counts are the owner's real totals; the published copy resumes on the
  internal-storage listing. Also recorded: the emulator captures one frame in
  three seconds, and only appops set --uid ... deny brings the prompt back after
  Settings has granted the app-op.

- README and ROADMAP caught up with the build: the status stopped at M15, and
  the trash limitation still said there was no Empty trash and that expiry
  waited for the next delete, both changed in M19.

Verified: ./tools/verify.sh green, the code map current, the Play field measured
at 450 characters and the form answer at 490, and the video decoded as H.264
1080x2400, 19.666 s, no audio, with frames checked at the cut and the end state.
This commit is contained in:
2026-10-18 13:59:50 +02:00
parent f4ca5f22ae
commit 9b8a32fbd6
10 changed files with 400 additions and 26 deletions
+21 -23
View File
@@ -12,25 +12,23 @@ no advertising or tracking SDKs.
## Status
**M15 — favourites: done.** A star in any folder's app bar puts that folder on the home screen, above
the libraries, where a folder that has gone is marked *not found* rather than silently dropped and
the row's own star removes it. Before it: **M14 — renaming a batch** (selecting several files and
choosing Rename opens a **pattern** dialog instead of the single-file one: one name, the number to
start at, and a preview of the names
it will produce — and the numbering **carries on from the folder's own**, so `series (1)` and
`series (2)` already there make the next batch start at 3. A batch that cannot be done is refused
before anything moves, naming the file in the way, and the whole batch is one undo step. Before it:
**M13 — video thumbnails** (a video row shows a frame of the video itself rather than a film icon —
the platform's own retriever, through Coil, with a frame taken a second in and the icon kept as the
fallback when a file cannot be decoded), **M12 — duplicate finder** (size, then the head of every
candidate, then the survivors in full), **M11 — library views** (a **Libraries** section on the
root screen — Images, Videos, Audio, Documents, Archives and Recent — whose rows open
ordinary listings of those files, each carrying a count from the search index), and **M10 — store
assets**: the app is named **Plain Files**, the icon and feature graphic come from the app's own
vectors, and [docs/STORE_LISTING.md](docs/STORE_LISTING.md) holds length-checked listing copy.
Screenshots exist for 5 phone (1080×2160), 4 on a 7-inch tablet (1200×1920) and 4 on a 10-inch
tablet (2560×1600) — but they **predate M11**, so the home screen in them is the old volume list and
they will need re-shooting, which the library views make a privacy question as well as a cosmetic one
**M20 — launcher shortcuts: done.** Long-press the app icon for **Images**, **Recent** and **Trash**.
Since the last release build: **M19** gave the trash its 24-hour window, **Empty trash** and a sweep on
open; **M18** let compression store files instead of squeezing them; **M17** put a dot on the rows an
operation produced; and **M16** added **Copy to… / Move to…** with a destination picker that does not
take you out of the folder you are in. Before them: **M15 — favourites** (a star puts a folder on the
home screen), **M14 — batch rename** (one pattern, a start number, and a series that carries on from
the folder's own), **M13 — video thumbnails** (a frame of the video itself rather than a film icon),
**M12 — duplicate finder** (size, then the head of every candidate, then the survivors in full),
**M11 — library views** (Images, Videos, Audio, Documents, Archives and Recent, counted from the
search index), and **M10 — store assets**: the app is named **Plain Files**, the icon and feature
graphic come from the app's own vectors, [docs/STORE_LISTING.md](docs/STORE_LISTING.md) holds
length-checked listing copy, and [docs/RELEASE_NOTES.md](docs/RELEASE_NOTES.md) holds the copy for the
Console's **What's new** field.
Screenshots exist for 8 phone (1080×2160), 4 on a 7-inch tablet (1200×1920) and 4 on a 10-inch
tablet (2560×1600). The phone set was re-shot on 2026-10-18 and covers M16-M20; the tablet sets
**predate M11** and should be regenerated on a machine with KVM before the listing goes live
([docs/STORE_LISTING.md](docs/STORE_LISTING.md)).
## Tech stack
@@ -179,10 +177,10 @@ UI.** Translated UI text has to be supplied in `values-<locale>/`.
- **The trash is a time window, not a bin you manage.** A delete stages the item in a hidden
`.plainfiles-trash` folder on the same volume and keeps it for 24 hours; the **Trash** entry
in the overflow menu lists what is still there and puts a whole batch back. There is no
"empty it now" action — expired batches are swept the next time something is deleted — and a
name taken again in the meantime is never overwritten, so a restored item can arrive beside
the new one rather than replacing it.
in the overflow menu lists what is still there, puts a whole batch back, and offers **Empty
trash** for when the window is not what you want. Opening the trash sweeps what has expired,
so retention no longer waits for the next delete. A name taken again in the meantime is never
overwritten, so a restored item can arrive beside the new one rather than replacing it.
- **Where a trashed item came from is remembered in the app's own database**, not on the
volume. The staged files are the truth and the database is only an index, so the two are
reconciled in both directions: an entry whose file has gone is not offered back, and a