[kdroidFilter]

What

New flatpak module (nucleus.flatpak), the Flathub counterpart of MicrosoftStore.updates, over org.freedesktop.portal.Flatpak (Rust JNI bridge on zbus, Linux only, Kotlin-only Unsupported elsewhere).

Flatpak.updates.status.collect { status ->
    when (status) {
        is FlatpakUpdateStatus.Available -> Flatpak.updates.install(parent).collect { show(it) }
        is FlatpakUpdateStatus.Installed -> Flatpak.updates.restart()
        is FlatpakUpdateStatus.UpToDate -> Unit
    }
}

API	Portal
status: Flow<FlatpakUpdateStatus> (Available / Installed / UpToDate)	CreateUpdateMonitor + UpdateAvailable
install(parent): Flow<FlatpakUpdateProgress>	UpdateMonitor.Update + Progress
restart(arguments)	SingleInstanceManager.releaseForHandoff(), then Spawn with FLATPAK_SPAWN_FLAGS_LATEST_VERSION, then exit
openStorePage(parent)	OpenURI appstream://<app id>

Design notes (from the portal's source)

• No "check now": the portal polls every monitor on one timer (30 min by default), so status is a Flow, not a check().
• Permission dialog: the first Update shows "Update ?". The answer is stored (permission table flatpak, id updates), and a refusal maps to UpdateDenied.
• Error mapping: the portal's messages are translated, so errors are mapped by D-Bus name only. NotSupported raised while planning means NewPermissionsRequired; raised before planning, it means PortalMissing.
• Cancellation: closing a monitor cancels its update, so cancelling the install collection interrupts it.
• Spawn is always given fds 0–2. Without any, the portal hands the environment to flatpak run on fd 0, which rejects it (--env-fd: Cannot use reserved file descriptor 0, 1 or 2), and nothing starts after the app already quit. flatpak-spawn always passes its stdio, which is why this isn't widely known.

Lab

The new system.flatpak-updates probe (Linux) supports deep-link flags ?watch&install&restart, which run the whole update without a click.

Verification

End to end, from a local Flatpak repository with the real flatpak-portal (polled every 10 s) and the Lab as a native image:

• Detection: 1.0.3 → 1.0.4 detected.
• Dialog: the portal dialog was accepted by hand, and the answer was stored.
• Install: progress went 0 → 100 % and ended with status 2.
• Restart after a background flatpak update (1.0.5 → 1.0.6): a single instance came back on the new commit.
• Full in-app path (1.0.6 → 1.0.7): watch → install → restart, again a single instance on the new commit.
• Checks: :flatpak:check (19 tests, detekt, ktlint), apiCheck, :examples:lab:probes:system:check, cargo clippy with 0 warnings.

Checked by hand on Ubuntu GNOME (Lab 1.0.8, Wayland): the dialog opens attached to the Lab window, "Deny" fails install() with UpdateDenied, and openStorePage opens GNOME Software.

CI: one build step and the verify entries in build-natives.yaml, plus the 2 Linux paths in publish-maven.yaml.