The selection bar offered Copy and Move, which only filled an in-app clipboard; the
destination picker then lived behind an overflow menu, and Paste in the top bar. That
made a copy a two-step detour through another folder - the thing M16's picker exists to
avoid.
- The bar's two verbs are now Copy to… and Cut to…, both opening the destination picker.
- The clipboard state, Paste here, and the overflow's duplicate Copy to… / Move to… are
removed. The picker's cut title and confirm are Cut to… / Cut here.
- A copy still keeps the selection for a second destination; a cut clears it. Conflicts
still ask before overwriting, naming the picked folder.
- Five clipboard tests are removed; the mark, restart and undo tests now use the picker.
BrowserTopBar's search and overflow sections are extracted so its two new detekt
findings are fixed rather than baselined.
Driven on the Xiaomi phone: Copy to… copied 120 x 16 MB through Internal storage ->
AADemo -> Target and reported Copied 121 items to Target; Cut to… moved file001.bin and
offered Undo; a name in the way raised Items already exist here; the top-bar overflow
has no Paste. The foreground-service video was re-recorded against the new bar at 16.1 s.
Verified: ./tools/verify.sh green, the code map current, 426 unit tests pass, and the
video decodes as H.264 1080x2400 with no audio.
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.
SoftwareApp