Play asks separately about FOREGROUND_SERVICE_DATA_SYNC: which use case, what
the service does, what the user loses if the task is deferred or interrupted,
and a video of the user triggering the work. The answers are now in section 5
of the release checklist, and the video is recorded.
The use case is Local processing -> Importing, exporting. Play's own chart
describes it as moving files from an SD card locally, which is what Paste and
Copy to... / Move to... do. The description (482/500 characters) names every
OperationKind - COPY, MOVE, DELETE, COMPRESS, EXTRACT - and states that the app
has no INTERNET permission, so network processing, backup/restore and media
transcoding are explicitly not ticked.
The video (18.0 s, captions burned in) shows a 1.8 GB synthetic folder copied to
another local folder: the selection and Copy, Paste here, the "Copying files"
notification with its progress bar, and the completed folder. It is cut from a
35.2 s raw take to remove the two waits; the target listing stays empty until
the copy completes, so those frames are progress rather than failure. The shade
was cleared of the phone's weather and Play cards first, leaving only Android's
generic USB cards, and every filename is synthetic.
Two traps are written down: do not press Up after Copy, because the selection
is already in AADemo and an extra Up makes Paste target AADemo ("Items already
exist here"); and open the shade only after cmd notification list shows the
app's notification, or the video shows no evidence of the service.
Verified: ./tools/verify.sh green, the code map current, links resolve, both
videos decode as H.264 1080x2400 with no audio, and the SRT has five cues.
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.
The phone set was two days old and predated M16-M20: nothing in it showed the copy-to picker, the
trash's window or the compress dialog. It is now eight shots (Play's maximum) taken from the signed
release build over the demo library: home, folder list, photo grid, storage usage, sort sheet,
Copy to..., the trash with its 24-hour line and Empty trash, and the compress dialog with its switch.
The shots have to stay inside the demo library, so two things were deliberately not captured: the
home screen (its library counts are the real phone's - the old AVD-shot file is kept) and the picker
one level down (it would name real folders). The picker is shot at the volume list instead.
Taking the picker shot exposed a real bug: it listed '.plainfiles-trash' among the destinations,
because unlike every other listing it did not filter hidden entries. Hidden folders are now offered
only when the listing shows hidden files, with a test for both halves.
The tablet sets are unchanged. The tablet AVDs cannot boot on this machine (no KVM) and the
phone-resized path needs more navigation work than this session had left; the checklist says so and
records what to regenerate and where.
A window at or above Material expanded breakpoint (840dp) now splits into a master pane and a detail pane: tapping a row highlights it and the second pane shows a folder children, or a preview plus the metadata for a file. Opening moves to a double tap on wide windows only; phones (~411dp) and the 7-inch in portrait (~600dp) keep their layout and their tap behaviour.
Found while taking the tablet screenshots: the app had no large-screen layout at all, so on a 2560x1600 canvas every row was 2560px wide with its content stranded in the left ~240px.
The tablet sets are re-shot on this build. That also caught a blank capture (7-inch 01-roots) that had already been committed: a headless AVD draws its system bars before Compose composes its first frame, so the file was not obviously empty. make-store-screenshots.sh now measures each capture app area and refuses to normalise one that is blank.
The 7-inch roots capture was pure app background (Compose had not composed its
first frame yet, though the system bars had drawn) so it measured as uniform.
made-store-screenshots.sh now measures each capture and refuses to normalise a
blank one.
SoftwareApp