network-manager is needed for dbus to avoid the following errors:
_logging_message__21:16:57.763 WARN unknown propsReply “An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=”:1.72" (uid=1000 pid=1795 comm="/snap/strawberry/x1/usr/bin/strawberry " label=“snap.strawberry.strawberry (enforce)”) interface=“org.freedesktop.DBus.Properties” member=“GetAll” error name="(unset)" requested_reply=“0” destination=“org.freedesktop.NetworkManager” (uid=0 pid=609 comm="/usr/sbin/NetworkManager --no-daemon " label=“unconfined”)"
alsa is needed for the device finder to locate devices for direct output to alsa, otherwise no devices are listed.
udisks2 is needed for the devices support, copying songs to udisks2 mounted devices:
21:16:58.199 WARN Udisks2Lister:175 Error enumerating udisks2 devices: "org.freedesktop.DBus.Error.AccessDenied" "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.72\" (uid=1000 pid=1795 comm=\"/snap/strawberry/x1/usr/bin/strawberry \" label=\"snap.strawberry.strawberry (enforce)\") interface=\"org.freedesktop.DBus.ObjectManager\" member=\"GetManagedObjects\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.UDisks2\" (uid=0 pid=592 comm=\"/usr/lib/udisks2/udisksd \" label=\"unconfined\")"
It seems your snap is trying to detect if it is on the network. Would the new ‘network-manager-observe’ interface work for you? If not, since network-manager grants access to configure all networking on the device, why does a music player need to configure networking?
This isn’t surprising for a music player, but I wonder since strawberry is just a player why pulseaudio wouldn’t be better. Can you comment?
Typically one uses the ‘removeable-media’ interface for this sort of thing rather than udisks2 directly. Indeed, it is surprising that a music player requires the ability to configure and partition disks for the entire system, which is what udisks2 provides (and therefore device ownership of the device). Can you comment on why ‘removeable-media’ is insufficient for your use case?
You are right about network-manager, network-manager-observe is sufficient. I’ve changed to network-manager-observe in snapcraft.yaml now.
alsa:
A lot of users prefer not to use pulseaudio, some uninstall it from their system. I’ve been using Linux on the desktop since before pulseaudio came default in distros and still never use pulseaudio and do not even have it installed on the system.
I know direct output to alsa is relevant to a lot of users because of the amount of e-mails and feedback I receive from users.
The problem with the snap is that new users who wants to try it thinks the player is broken because they can’t select their sound card in the settings, and they blame the player because they do not know about the restrictions in the snap.
I realize pulseaudio has it’s uses, if you have multiple soundscards, headphones and want an easy way to direct the sound output from applications where you can’t select output. But for me and a lot of other users we set up a computer in the living room connected to the TV with a DAC that is mostly used for music, we want the sound to go directly to the DAC without any resampling or the use of pulseaudio.
It needs the removable-media too, otherwise users won’t be able to add music from removable devices, I already have it in the snapcraft.yaml file but thought it was auto-connected.
+1 for network-manager-observe, alsa and removeable-media (though I recommend that your application also supports pulseaudio because not all hardware can do multiplexing through alsa directly)
-1 for auto-connects udisks2. I understand that your application wants to list devices, however the udisks2 interface is far too much access to grant by default. I suggest adjusting your application to either not require udisks or to detect that the access is not available and somehow let the user know that the manual connection must be made.