PassBolt Android Autofill not triggering on Android 16 (Galaxy S22 Ultra) after system permission reset — only legacy Accessibility autofill works

Community Feedback
1

Summary

After Android 16 unexpectedly reset all of my app permissions to default (most permissions used by third-party apps were turned off) without prior notice, PassBolt’s standard Android Autofill prompt no longer appears in any app or browser on my Samsung Galaxy S22 Ultra. The PassBolt Autofill service is enabled in Android’s Password & Autofill system settings, I have toggled it off/on, and I have also toggled autofill off/on inside Chrome. None of this restores the OS-level autofill popup.

The only thing that currently works is PassBolt’s legacy Accessibility-service-based autofill (the failsafe mode), which fills correctly in both apps and browser. That works perfectly, but it is documented as legacy and is widely expected to be discontinued, so I would prefer to get the proper OS Autofill Framework path working again rather than rely on accessibility long-term.

I am hoping to fix this without reinstalling PassBolt or factory-resetting the device.

Environment

  • Device: Samsung Galaxy S22 Ultra

  • OS: Android 16 (One UI on top)

  • PassBolt Android app: latest from Play Store

  • Server: self-hosted

  • Trigger event: System-initiated app permission reset (all third-party app permissions reverted to default with no prior notification)

Symptoms

  • Standard Android Autofill popup from PassBolt does not appear when focusing login fields, in either native apps or in Chrome web pages.

  • Settings → General management → Passwords, passkeys and autofill → Autofill service is set to PassBolt.

  • Toggling the autofill service off, picking “None,” then re-selecting PassBolt has no effect.

  • Toggling Chrome’s own “Autofill using” setting off/on has no effect.

  • PassBolt’s legacy Accessibility-based autofill (failsafe mode) works correctly in every tested app and in Chrome.

  • Other autofill providers (e.g. Samsung Pass) do still surface their own popups when selected as the default, so the OS Autofill Framework itself is functional — the problem appears specific to PassBolt’s integration after the permission reset.

What I have already tried

  1. Confirmed PassBolt is selected as the system Autofill service.

  2. Toggled the system Autofill service off, rebooted, re-enabled PassBolt.

  3. Toggled Chrome’s in-app autofill setting off and on.

  4. Re-granted every permission visible to PassBolt under Settings → Apps → PassBolt → Permissions.

  5. Cleared Chrome’s autofill cache and forced a fresh login attempt.

  6. Confirmed Accessibility-based failsafe mode works — so the credentials, account, and server connectivity are all fine; only the OS Autofill Framework hand-off is broken.

Hypothesis

When Android 16 reset permissions, on it’s own, without user intervention, it likely also revoked the per-app grant that lets PassBolt act as an Autofill Framework provider, or invalidated some internal handshake between the AutofillService binding and the PassBolt app. The visible toggle in Settings reports PassBolt as the active autofill service, but the underlying binding appears to be in a stuck/half-revoked state that the UI does not expose. Reselecting it via the standard toggle is not enough to rebuild that binding.

Questions for the community / PassBolt team

  1. Is there a known issue with Android 16’s permission-reset behavior breaking PassBolt’s registration as an Autofill Framework provider on Samsung devices?

  2. Is there a way to force PassBolt to re-register its AutofillService with the OS without reinstalling the app — e.g. clearing only the autofill-related cache, or a developer/debug option inside PassBolt that re-binds the service?

  3. Are there any specific permissions or App Info settings (beyond the ones visible under Apps → PassBolt → Permissions) that the Autofill Framework requires — for example a “Display over other apps” or “Appear on top” grant — which the permission reset may have silently revoked and which is not surfaced in the standard permissions list?

  4. Is there an ADB command or a Settings deep-link known to force a clean re-bind of the active autofill provider short of a reinstall?

Things I would like to avoid

  • Uninstalling and reinstalling PassBolt (loss of local state, would also need to reconfigure passphrase storage and biometric unlock).

  • Factory-resetting the device.

Things I am willing to try

  • Targeted “Clear cache” (not “Clear data”) on PassBolt and on Android System Intelligence / Autofill provider services.

  • ADB commands such as adb shell settings put secure autofill_service <component> to forcibly rebind the provider.

  • Disabling and re-enabling Samsung Pass (which sometimes hijacks the autofill role on Galaxy devices) to confirm it is not competing with PassBolt.

  • Any developer/diagnostic mode inside the PassBolt Android app that exposes the autofill binding state.

Why this matters beyond my single case

Android 16’s broad, unannounced permission-reset behavior is going to hit a non-trivial number of users. If the visible permissions UI shows everything as “PassBolt is the autofill provider” but the binding is silently dead, users will assume PassBolt is broken — and the only currently working fallback is a legacy Accessibility path that is on borrowed time. A documented recovery procedure (or, ideally, a self-heal on app launch when PassBolt detects it is the nominal autofill provider but has not been invoked in N days) would prevent a lot of confused support tickets.

Happy to capture adb logcat output filtered for AutofillManagerService / autofill if that would help diagnose. Just point me at what you want to see.

Thanks in advance.