Thanks for working on this. At this point, it looks good to me in the abstract, but I haven't tested it yet to make sure it actually works and doesn't block intended functionality. What testing have you done with this so far?

So far, I have tested the sandboxed service on a kinoite-main-hardened image, always using the latest image available, in a vm under the qemu user session, and it has worked exactly the same as if it were unsandboxed. It succeeds when running systemctl start flatpak-system-update.service, and neither systemctl status flatpak-system-update.service nor journalctl -u flatpak-system-update.service (as root) show any error logs

Something I have to mention, though, is that when a system remote is present in the system, the service will fail when trying to run flatpak --system repair. This happens whether the service is sandboxed or not, so it isn't the sandbox's fault. This issue will most likely need to be addressed in a separate issue. (I can confirm that removing flatpak --system repair from the service fixes it.)

Just to clearly state the sort of testing I'd like to see for this: I'd want this to be tested on a system with a variety of flatpaks installed in a system installation, including some flatpaks like Steam that have more complex install hooks. The testing should also cover the case when updates are actually installed, not just checking for updates and not finding any. The failure mode here would be flatpaks (likely silently) failing to update, which is something we definitely want to avoid, so this needs thorough testing.

@HastD Would it help if we add a line like OnFailure=<run script that pushes a desktop notification> to all the auto update services? This way users will be notified when auto update fails. I'm envisioning something like the security-related update notification we run on every auto update.

Up to standards ✅

_{TIP This summary will be updated as you push new changes. Give us feedback}