Supported interfaces

doc
32

The meaning of the ‘autoconnect’ column is unclear to me. For interfaces marked “autoconnect: no”, does this mean:

  1. The interface is not automatically connected by default, but can be auto connected by adding appropriate declarations in the snapcraft.yaml

  2. The interface cannot be made to autoconnect by adding declarations in the snapcraft.yaml. The only way to connect it is for users to explicitly run ‘snap connect’ commands.

33

Thanks for flagging this, and I can see what you mean. All interfaces used by a snap need to be added to a snap’s snapcraft.yaml, regardless of whether they’ll be connected automatically to the system after they’ve been installed by the user. Then:

This is from the text above the table. But I can see that this isn’t 100% clear - it’s also possible for a snap developer to request permission for their snap to auto-connect an interface that wouldn’t ordinarily auto-connect. I’ll update the text at the top to explain this.

2 Likes
34

This page explains how to add interfaces to your snapcraft.yaml: https://snapcraft.io/docs/t/snapcraft-interfaces/13123

1 Like
35

Can we adjust this section to indicate that a snap that was already installed before a snap was granted auto-connect for some interface (i.e. mount-observe), will be updated to use the new auto-connection when that is granted as per store processes? I.e. this is the expected workflow:

  1. publisher pushes snap that plugs mount-observe w/o auto-connect from store
  2. user installs the snap, mount-observe is not connected
  3. publisher requests and receives auto-connect, snap declaration in the store is updated
  4. at some point in the future, snapd downloads the new snap declaration for the snap and applies the new auto-connect.

There was some confusion from others about this point and I’m not sure how to succinctly summarize this point.

1 Like
36

Yes, absolutely. I’ll work on something and add it to the doc. Thanks for flagging this!

2 Likes
37

This page suggests that the pulseaudio interface does not auto-connect, but my experience was that it did. Has this changed?

38

yup

1 Like
39

If your snap previously used pulseaudio when it was automatically auto-connected, then it will continue to do so, but new snaps will not get auto-connection of pulseaudio.

2 Likes
40

I answered this question over here: Electron Audio on Ubuntu Core. What is listed on this page is mostly about implicit slots or expected auto-connections for app-provided slots. The pulseaudio snap predates the audio-* interfaces and still allows auto-connecting to it. If/when it is updated, we can update its snap declaration to match the above.

1 Like
41

Thank you very much for explaining.

Might it be useful to add a note to explain this documentation only applies to Classic? I assumed from reading it that it applied to all operating systems equally.

42

This page should talk about the cups interface as the new interface to enable your snap to print. I’m not sure if this is already supported on all distributions, though.

43

Thanks - and a great point. I’ll look into it and make sure this page (and a corresponding CUPS interface page) is updated/created.

2 Likes
44

I think power-control interface is missing. cheers

45

Thanks for flagging this. I’ve just done a quick audit and there are actually a few more missing too:

allegro-vcu
cups
dm-crypt
fpga
gconf
hugepages-control
ion-memory-control
kernel-crypto-api
media-control
microstack-support
power-control
ptp
qualcomm-ipc-router
snap-refresh-control
tee
vcio

I’ll start adding these now.

Edit (15th Sept 2021): The above interface docs have now been added.

46

It would be really helpful to explain the use case for snap-refresh-control in simple terms: it looks like it might be useful. thanks!

47

Is there a programmatic way to list all supported interfaces?

48

There’s GET /v2/connections in the Snapd REST API (basically the same as snap connections --all):

$ sudo curl -sS --unix-socket /run/snapd.socket http://localhost/v2/connections\?all \         ✔  11:30:02  
| jq
{
  "type": "sync",
  "status-code": 200,
  "status": "OK",
  "result": {
    "established": [
      {
        "slot": {
          "snap": "snapd",
          "slot": "audio-playback"
        },
        "plug": {
          "snap": "ardour",
          "plug": "audio-playback"
        },
        "interface": "audio-playback"
[...]
49

note that snap connections only shows connections in use while the deprecated snap interfaces shows all interfaces snapd knows …

filtering all duplicates and non-snapd (i.e. content) interfaces with snap interfaces:

$ snap interfaces 2>/dev/null | grep -v ^\- | cut -d' ' -f1 | sed 's/^://' | sort | uniq | grep -v : | wc -l 
137
$

doing the same for snap connections --all:

$ snap connections --all | cut -d' ' -f1 | sort | uniq | wc -l
77

we sadly never got a proper 1:1 replacement for snap interfaces when it got deprecated …

1 Like
50

Weird leading hyphen on line for “kernel-module-load”

This list might not be complete, I can see in the source go files for polkit and scsi-generic interfaces which are not in this list, there might be others.

I might add, at the bottom, a URL to take readers to https://github.com/snapcore/snapd/tree/master/interfaces/builtin if they want to peruse the source code.

51

There is a bullet point paragraph describing the “Transitional interfaces” column, but no such column exists, and there is no other mention of “transitional” on the page. Should this bullet be removed now?