Snap interfaces from Android App developer perspective

If you are already building Snap packages, I guess you know what an “interface” is in the world for Snapcraft. However it seems, the terminology may not be very clear for someone who doesn’t know anything (my developer friends and colleagues) about Snap. So I just wanted to clearly write this one out so that it becomes clear for people coming from Android App development background. I like to think that “permissions” in Android and “interfaces” in Snap world are pretty much interchangeable. I have done a fair amount of Android App development (professionally and privately) in the past six years and have been involved in the Snapcraft ecosystem almost since it’s inception.

Before going into further details I think it’d make sense to clear some of the Snapcraft terminologies as well.

• Snapcraft is the name of the wider project, which involves the build tools, the public Store, the daemon that runs on your computer to manage and update snap packages. However snapcraft is also the name of the command line tool that is used to actually build snap packages, confusing ? yeah, a bit!
• Snapd is the software and daemon that runs on your computer to install/remove/update snap packages both from the Snap store or a locally built one. The CLI tool is called snap

Android App permissions

In Android, if an app wants to access geolocation, it has to “request” the OS for it’s permissions, which then pops up a dialog that the user sees, in that dialog the user may choose to grant the requesting app the permission to use geolocation or deny it.

It is also pertinent to mention that some permissions like INTERNET only needs to be added to AndroidManifest.xml file and the user is not asked if the App should be allowed to access the internet.

Snap Permissions

In the classic Linux packaging like deb and rpm, the installation is mostly the extraction of the relevant software into the rootfs and some scripts get run (as root!) during the installation process. After that the software has unrestricted access to the system, it can access different hardware devices, can read the whole filesystem and even change it.

However the above stuff is quite different for a Snap package, a snap package’s build configuration is a simple yaml file, that defines what system resources the snap is expected to access, like the network, usb camera, opengl or the sound server etc. Specifically that gets defined under the plugs stanza, similar to how permissions are defined in AndroidManifest.xml.

Just like the INTERNET permission in Android, there are multiple such interfaces in the snap-world that are pre-granted or “connected” as you would call it in the snap world.

For interfaces that are deemed sensitive for auto-connection, there is a process by which an app developer can request the snap store admins to grant their snap the permissions to automatically connect a specific interface on installation. That process is documented here. The developers mostly need to justify why their App needs permission to access a certain system resource.

One thing that is missing currently is that there is no way for a software to request the system to prompt the user to grant permissions for an interface. I think something like that could help circumvent the need for asking the Snap store admins. Hopefully we can have that feature some day as well.

That mostly concludes this article. We have been using Snap packages for building a commercial product and have been using them on a Yocto-based system. I will be writing quite a bit more in the coming days and months about that journey.