Question on permissions

[IzzySoft]

Our updater at IzzyOnDroid reported a few sensitive permissions, which are not covered with an explanation. Can you please help out? (Ideally, having them documented in the Readme or a privacy.md might be a good idea as well):

The chocolate ones are the sensitive candidates. From digging around, I figured CAMERA is for an integrated QR code scanner. Can you please outline what the other ones are needed for?

• android.permission.SYSTEM_ALERT_WINDOW
• android.permission.READ_MEDIA_AUDIO
• android.permission.RECORD_AUDIO

Filling the other gaps is of course welcome, too 😉 Thanks in advance!

[A-EDev]

@IzzySoft Thanks for reaching out, and sorry these weren't documented anywhere. I was about to open a ticket on your repo for metadata update this week after i move my project to @Flow-Tube. Here's what the flagged
ones do, and I'll be adding a privacy.md to the repo root with the full list soon.

CAMERA - as you found, QR scanning only. It's used by one screen (Settings > Device Sync),
which copies a library between two of the user's own devices over the local network. The
session key is passed out of band via a QR code so it never goes over the wire. Frames are
decoded locally by ZXing, nothing is stored or sent. If you never open that screen you're
never asked for it.

RECORD_AUDIO - microphone song recognition, the Shazam-style feature. While the user holds
the button it records a short sample, computes a fingerprint on device, and sends only the
fingerprint to Shazam's public endpoint to get a title back. The recording is not written to
disk and not uploaded. No background or passive listening.

READ_MEDIA_AUDIO - two local uses. The local media browser plays music files already on the
device (the app works fully offline as a local player), and it's needed to recover downloads:
Flow can save to a public folder that survives an uninstall, and rebuilding the download
library after a reinstall means reading those files back. The MediaStore query only runs when the user opens the local
browser or triggers a rescan.

SYSTEM_ALERT_WINDOW - fallback popup player. Native PiP is the default path and needs no
permission, but on ROMs where PiP is missing, vendor-disabled, or broken, the app draws the
floating video window itself with TYPE_APPLICATION_OVERLAY. It's checked with
Settings.canDrawOverlays before that path is taken, and if not granted the app just stays on
native PiP or shows no popup. No overlay outside an active playback session.

For the rest, briefly:

• INTERNET, ACCESS_NETWORK_STATE: streams and metadata, offline detection, retry logic, and the
  "Wi-Fi only" download constraint.
• ACCESS_WIFI_STATE: reads the device's own LAN address. Needed by DLNA casting and by Device Sync (host address goes
  into the QR). No network scanning, and the app declares no location permission.
• CHANGE_WIFI_MULTICAST_STATE: multicast lock for SSDP discovery when searching for DLNA/UPnP
  renderers. Acquired when a cast search starts, released when it ends.
• WAKE_LOCK, FOREGROUND_SERVICE, FOREGROUND_SERVICE_MEDIA_PLAYBACK: background audio via the
  Media3 playback service.
• FOREGROUND_SERVICE_DATA_SYNC: the download service and the Device Sync transfer service, both
  only while that work is running.
• POST_NOTIFICATIONS: media notification, download progress, optional new-video alerts.
• READ_MEDIA_VIDEO: same as READ_MEDIA_AUDIO but for video files.
• READ_EXTERNAL_STORAGE (maxSdkVersion 32), WRITE_EXTERNAL_STORAGE (maxSdkVersion 28): the
  pre-Android-13 equivalents, capped so they aren't requested on newer releases.
• MANAGE_EXTERNAL_STORAGE: optional and off by default. Downloads go to app-private storage
  unless the user picks a custom location in Download settings, so the files survive an
  uninstall and are visible to other apps.
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS: only shows the system dialog, in context, when the user
  enables new-video notifications. Several OEM battery managers drop the app into a restricted
  standby bucket and cut its background network access, which starves the periodic check.
  Declining changes nothing while the app is open.
• RECEIVE_BOOT_COMPLETED: not mine, merged in from androidx.work:work-runtime to reschedule
  jobs after reboot. I register no boot receiver.
• DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION: not mine either, androidx.core defines it under
  package name at signature level so ContextCompat.registerReceiver can keep dynamic receivers
  non-exported.

one more thing worth flagging:

DOWNLOAD_WITHOUT_NOTIFICATION is dead. Downloads go through the app's own service and nothing is
enqueued into the system DownloadManager, so it does nothing. I'll remove it from the
manifest.

[IzzySoft]

Wow, that was thorough, thanks! 🤗 Updated here to:

DOWNLOAD_WITHOUT_NOTIFICATION is dead … I'll remove it from the manifest.

Will disappear from the listing here then with the next release automatically.

I was about to open a ticket on your repo for metadata update this week

Always welcome! You can even throw in a PR if you want something adjusted: https://codeberg.org/IzzyOnDroid/repodata/src/branch/main/metadata/io.github.aedev.flow.yml 🤗

[A-EDev]

Awesome, thank you!
Then i will open a PR after i move the project .