Is there some reason you’re looking in the /root/snap folder and not the folder of the user who would likely be running the androidsdk snap? What’s in /home/$USER/snap/androidsdk?
yes, the link became correct after the launch of androidsdk. But this is not acceptable, since it is an assembly machine, and the automatic update of the snap package breaks my assembly, because I do not use the androidsdk tool constantly, but only when I need to pull new packages.
Is it possible to make the link overwrite itself on a new one when updating, and not on the first start?
How are you using the data stored in $SNAP_USER_DATA ? If you are using it out-of-band from the snap, I think a more reliable way than hard-coding /root/snap/androidsdk/current as the dir to read from would be to run something like
DATADIR=$(sudo snap run --shell androidsdk -c "echo \$SNAP_USER_DATA")
and then reference DATADIR instead of /root/snap/androidsdk/current. This has the advantage that this will also update the symlink for you when the snap is updated.
As to whether or not snapd should update the current symlink, that is a bit of a sensitive area, because specifically in the case of running apps that get refreshed while they are running, we don’t want to change the symlink until the new version of the snap is run (i.e. the app is restarted), because otherwise a running snap for the old revision during an update would keep using the process / static app files from /snap for the old revision, but now $SNAP_USER_DATA was moved to point to a new revision because an update happened, but confinement policy would deny these accesses.
I think after [WIP] Refresh App Awareness is completed and enabled everywhere, we can visit the suggestion to update the current symlinks for SNAP_USER_DATA, et. al when the snap is updated and not just on snap running.