docs: cut the Photo and video permissions answer to the Console's 250-character box

The field takes 250 characters, not the 1 689 the draft assumed, so the answer is now 243
characters - measured, not estimated, and deliberately pure ASCII, because one curly quote or dash
pasted from a doc would silently shift the count:

  The app needs READ_MEDIA_IMAGES to read every photo, because duplicate detection compares each
  photo with every other. A picker exposes only selected files, and a photo's duplicates are
  exactly the files it withholds. All hashing is on-device.

What survived the cut is the sentence that carries the argument: the reason the permission is
needed is the same reason the picker cannot work - duplicates are, by definition, the files nobody
selected. What went is the statistical-fit paragraph and the delete path, neither of which a
reviewer needs in order to judge *this* question, and both of which are still in the longer drafts.

Also here: a 228-character alternate that opens with the comparison rather than the permission, and
the two long versions re-labelled as fallbacks for anywhere not capped at 250 (Play sometimes
follows up by email). The evidence table stays unchanged - it is the defence if the answer is
questioned, not part of what gets pasted.
This commit is contained in:
2026-10-14 13:43:13 +02:00
parent fe28373433
commit 6315af1f92
+22 -6
View File
@@ -214,15 +214,31 @@ action except the items marked **[code]**.
a component restriction, not a permission the app requests.) a component restriction, not a permission the app requests.)
- [ ] Answer the **Photo and video permissions** declaration (App content › Photo and video - [ ] Answer the **Photo and video permissions** declaration (App content › Photo and video
permissions). It lists `READ_MEDIA_IMAGES` as *undeclared* and asks one question per permissions). It lists `READ_MEDIA_IMAGES` as *undeclared* and asks one question per
permission: permission — in a box with a hard **250-character** limit:
> **Read media images** — Describe why the Android photo picker or other system pickers do > **Read media images** — Describe why the Android photo picker or other system pickers do
> not fully support your app's core functionality, and why your app needs to use the > not fully support your app's core functionality, and why your app needs to use the
> `READ_MEDIA_IMAGES` permission. > `READ_MEDIA_IMAGES` permission.
Answer the *picker* half first and the *permission* half second — that is the order the Paste — **243** of the 250 characters, pure ASCII so the count cannot drift on paste:
question asks in, and the picker half is the one a reviewer is actually weighing. Paste
(1 689 chars): > The app needs READ_MEDIA_IMAGES to read every photo, because duplicate detection compares
> each photo with every other. A picker exposes only selected files, and a photo's duplicates
> are exactly the files it withholds. All hashing is on-device.
One sentence carries the whole argument: the reason the permission is needed *is* the reason
the picker cannot work. A picker hands over the files the user selected, and duplicates are
by definition the files nobody selected — the copies of a picked photo live in the part of
the library the picker never exposes. The closing sentence is there because a permission
declaration is also a privacy statement, and 25 characters is a cheap way to say it. If you
would rather open with the comparison than with the permission, this fits too (**228**):
> Finding duplicates requires comparing every photo with every other, so the app must read
> the whole library via READ_MEDIA_IMAGES. A picker exposes only selected files, and a
> photo's duplicates are exactly the files it withholds.
The longer versions below are kept for anywhere that is *not* capped at 250 — Play sometimes
follows up by email, and both read well wherever more detail is wanted. **1 689 characters**:
> Foto Dup Finder's core functionality is finding duplicate and visually similar photos > Foto Dup Finder's core functionality is finding duplicate and visually similar photos
> across the user's whole photo library, and letting the user delete the copies. Reading the > across the user's whole photo library, and letting the user delete the copies. Reading the
@@ -248,7 +264,7 @@ action except the items marked **[code]**.
> `MANAGE_EXTERNAL_STORAGE`. Partial access (`READ_MEDIA_VISUAL_USER_SELECTED`) is declared > `MANAGE_EXTERNAL_STORAGE`. Partial access (`READ_MEDIA_VISUAL_USER_SELECTED`) is declared
> and supported as a reduced mode for users who prefer to hand over fewer photos. > and supported as a reduced mode for users who prefer to hand over fewer photos.
If the box is smaller, this says the same in 682 chars: …and **682 characters**, for a box with less room than that:
> Foto Dup Finder's only function is finding duplicate and similar photos across the user's > Foto Dup Finder's only function is finding duplicate and similar photos across the user's
> whole photo library and letting them delete the copies: reading the library is the feature. > whole photo library and letting them delete the copies: reading the library is the feature.
@@ -259,7 +275,7 @@ action except the items marked **[code]**.
> whole library to mean anything. Nothing is uploaded (the app has no INTERNET permission) > whole library to mean anything. Nothing is uploaded (the app has no INTERNET permission)
> and deletion always goes through Android's confirmation dialog. > and deletion always goes through Android's confirmation dialog.
Nothing in either version is aspirational — every claim is a place in the code, so it can be Nothing in any of them is aspirational — every claim is a place in the code, so it can be
defended if Play comes back with questions: defended if Play comes back with questions:
| The answer claims … | … and this is where that is true | | The answer claims … | … and this is where that is true |