Manual review request: tag-audio-recorder — audio-record, removable-media

store-requests privileged-interfaces
1

name: tag-audio-recorder

description: Records audio and lets users attach timestamped tags to the recording’s metadata for later reference.

snapcraft: Not publicly available (repository has no public remote)

upstream: PRIVATE

upstream-relation: maintainer

plugs:

audio-record:

request-type: auto-connection

reasoning: recording the microphone is the core functionality of the snap —

  tags are attached to timestamps within an active recording, so the app

  is unusable without this working out of the box.

removable-media:

request-type: manual-connection

reasoning: finished recordings are published into a user-selected public

  folder (via SAF-style file picker, not a fixed app-private directory),

  and later read back to edit tag metadata. This mirrors how the app

  already asks the user to grant folder access on Android, so it is

  expected to require an explicit connection here too.
2

This request has been added to the queue for review by the @reviewers team.

3

hey @gavtechapplications, for this request I am convinced about audio-record: +1 for auto-connection. Recording the microphone is manifestly the core function of a recorder app.

For removable-media: you have asked for manual, which is the default for this interface, so nothing needs granting, it will work with snap connect out of the box.

thanks

4

Thanks for the audio-record approval! I apologize, this is my first snap store app and I didn’t request the removable-media auto-connection properly. I requested it as manual instead. Would it be possible for that to be granted as well?

It’s not an optional/secondary feature: the app streams the recording to a local staging file, then on stop publishes it into a user-granted public folder as the final step of every recording. Without this connection, recordings can be captured but never actually saved anywhere the user can find them — the app is non-functional post-recording without it, in the same way it’s non-functional without audio-record.

Requiring a manual snap connect after install means every user’s first recording silently fails to save unless they’ve already run that command, with no in-app way to explain or trigger it (strict confinement gives the app no way to detect the missing connection and prompt the user). Given that, I think it fits the same bar you applied to audio-record — core to the app’s stated purpose rather than a convenience.

Updated request:

plugs:
  removable-media:
    request-type: auto-connection
    reasoning: finished recordings are published into a user-selected public
      folder as the final step of every recording (not an optional feature);
      without this connection the app can record but never save the result,
      and strict confinement gives it no way to detect the missing connection
      and prompt the user to grant it.

Happy to add more detail on the record→publish flow if useful.

5

Thanks for the detail. But I am going to decline auto-connection here, because the argument rests on a premise that isnt quite right and I think there is a better solution for your actual problem.

strict confinement gives the app no way to detect the missing connection and prompt the user

snapctl is-connected removable-media returns the connection state, so the app can check on first run and show a message explaining the connect command rather than silently failing. Several published snaps do exactly this.

More importantly, I dont think removable-media is the right interface for what you’re describing. You mention a user-granted public folder via a SAF-style picker and the Linux equivalent of Android’s SAF is the xdg-desktop-portal file chooser. If your publish step uses a portal file chooser, you likely need no privileged interface at all for destinations under the user’s home and removable-media (which grants blanket access to /media, /run/media and /mnt) is both broader than you need and for a home-directory “public folder,” not even the relevant interface, that would be home.

So my suggestion to use the portal file chooser for the user to pick the destination (no grant needed, works like SAF); rely on home for home-directory targets; and keep removable-media as a manual connection only for users who specifically save onto external/mounted media like a USB drive. Happy to help if the portal integration raises questions

1 Like
6

I fully agree with @0xnishit

+1 for granting tag-audio-recorder auto-connection to the audio-record interface. This should be expected by the user given the snap name.

+2 for, 0 against granting auto-connection to the audio-record interface. This is now live.