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
9b8a32fbd6