Appsupport15-gatekeeper-pin-enabler-patch
i removed the patch because for me and for others appsupport isn't starting and i should investigate why. IF YOU REMOVE THE APP REMOVE THE PIN FIRST. it puts credentials in /data/misc/gatekeeper and keystore2 binds keys to that. if you don't remove the pin before removing the patch you could get into an inconsistent state. you could try opening settings from terminal with devel-su lxc-attach -P /tmp/appsupport -n defaultuser – am start -n
com.android.settings/.Settings or tapping a few times on android version in appsupport settings. for me both ways open android settings even though apps don't start. if you cannot enter the pin there because you removed the patch before removing the pin like me and the keyboard doesn't come up, download the package from here and install it again for removing the pin: https://e.pcloud.link/publink/show?code=XZDDry7ZsHihpYjmCOJhGxAHV2klVjD1... then in the terminal run
devel-su lxc-attach -P /tmp/appsupport -n defaultuser -- cmd lock_settings clear --old YOURPIN
and
devel-su lxc-attach -P /tmp/appsupport -n defaultuser -- cmd lock_settings get-disabled
afterwards apps open for me again.
Category:
Changelog:
- Initial release for AppSupport 15 / SailfishOS 5.2 - init .rc with interface declaration for on-demand start - VINTF manifest fragment for IGatekeeper/default
Comments
stoefelz
Fri, 2026/08/28 - 19:41
Permalink
I think after the Sailfish Update to 5.2.0.17 the package was removed automatically and I was left with an non-working Android environment. But with your solution it is working again
projectmoon
Sat, 2026/08/22 - 21:26
Permalink
Also would this allow biometrics in AAS?
aviarus
Sat, 2026/08/22 - 21:34
Permalink
i don't think so but ididn't test
projectmoon
Sat, 2026/08/22 - 21:12
Permalink
What are the implications of using this vs when a system update comes? Like will it break the lock pin?
aviarus
Sat, 2026/08/22 - 21:20
Permalink
Short answer: the PIN itself is safe, but the package may stop taking effect after an update. The PIN is stored inside the AppSupport container under /data/misc/gatekeeper, which isn't touched by this package — it only ships two text files under /opt/appsupport/vendor/. So a system update won't wipe your PIN. What can happen is one of these: Jolla fixes this upstream. If a future AppSupport release adds the VINTF entry itself, you'd get a duplicate IGatekeeper/default declaration. Worth removing the package in that case. The /opt/appsupport/vendor/ tree gets recreated by an update. RPM would still own the files, but they could be overwritten or removed. If Android suddenly refuses your PIN after an update, reinstall the package and restart AppSupport. AppSupport 16 arrives. The package has no version dependency (deliberately, so it installs regardless), so it would still install but likely do nothing if the HAL layout changes again. Removal is clean — rpm -e appsupport15-gatekeeper, no scriptlets, nothing left behind. One caveat worth stating: this is based on nick8325's appsupport-lockscreen work. The difference is that on AppSupport 15 the gatekeeper HAL binary already ships inside the system image — it just never starts, because the interface isn't in the VINTF manifest and the init .rc is missing. So no stub Keyguard APK or RRO overlay is needed here, just the two files. Tested on jp2601 / 5.2.0.17.