Write the release notes, the permission answers, and the video
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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user