Also including appspace-app-dev and appspace-app-qa in this request; two separate snaps, so we can have the production listing ‘public’ and others as ‘unlisted’.
I think most of those requirements are supported by the various available interfaces. You probably want:
network-observe
hardware-observe
process-control
network-bind
system-files - configured for readonly access to the release files (*-release, os-relese, and openwrt_release)
To cache content you may use the available writable areas without classic.
The only thing here that I am unsure about is rebooting the system. Can you explain further what your app is designed to do and why it needs to reboot the system?
Auto-launching with .desktop files is supported by adding autostart: file.desktop and then adding a file with that name to $SNAP_USER_DATA/.config/autostart/file.desktop when your Snap is run.
Hello, given the “network-observe” interface, how to query the network information in terms of code level? Can you give an example in Node.js?
About the auto-start, by adding autostart: file.desktop in snap.yaml, do we still need to add the file “$SNAP_USER_DATA/.config/autostart/file.desktop” when our Snap is running? Wouldn’t that require us to maintain the access level? Does autostart in snap.yaml mean only allow us to create an entry startup file, but we still need to create it?
The “snap connections” showing that our app requesting for shutdown interface, but why the slot is empty? Does user have to manually connect it by command line after installation? Wouldn’t it become bad user experience? We actually want it to be automatically connected after installation.
We also need to call ‘df -P’ command to get storage space info (total, used and available space), what is the interface to use? This time we get a permission error:
The various interfaces are documented at https://snapcraft.io/docs/supported-interfaces - please spend some time to read that page and familiarise yourself with them and the sub-documentation for each. As you can see on that page, for audio playback there is the appropriately named audio-playback interface.
After test using the ‘mount-observe’ or ‘system-observe’, notice that all the mount points are changed to become:
Filesystem
1024-blocks
Used
Available
Capacity
Mounted on
/dev/loop8
56320
56320
0
100.00%
/
udev
1986036
0
1986036
0.00%
/dev
tmpfs
2014196
0
2014196
0.00%
/dev/shm
/dev/sda5
61145932
15709316
42300872
28.00%
/etc
tmpfs
2014196
0
2014196
0.00%
/sys/fs/cgroup
The root ‘/’ information, which is originally to be the proper storage information (available, used, and 60GB total), is now incorrect (56MB only), then how to get the proper information?
When your snap uses strict confinement, it is run in a special mount namespace providing a known set of libraries from your chosen base snap (e.g. core18). This is generally a good thing, since it means your app will behave the same way on different systems. The base snap is a read only compressed file system, which is why / shows as having no free space.
If your aim is to determine how much space is available to store files in a particular directory, then the statfs system call is probably more appropriate. Even without snaps, there is no guarantee that the directory is on the same file system as /. In particular, multiplying the f_bsize and f_bavail members from the result should give you the amount of free space available in that part of the file system.