The #1 is just about changing the Settings menu in some of its parts therefore I think that Patch Manager is the right tool to deliver them.
Alternatively, I found that qCommand can do the job of setting the power energy saving battery threshold (and create a related icon) but changing the menu would be more stylish. 
The #2 cannot be implemented with a patch by Patch Manager and I already got it as soon as I have tried to do a patch for Patch Manager. Thanks.
About the service that you link to me
service_do restart sailfish-fpd
sleep 3
service_do restart sailfish-fpd
@piggz → The sleep 3 is a waste of time and having to repeat the restart means that restart does not work correctly and it should be fixed.
@ichthyosaurus → It would be nice to have a patch in Patch Manger to remove that 2 lines of code. The diff patch could be downloaded from here while the Patch Manager patch from here:
Obviosly, if the patch improves the performance and does not introduce regressions then it should be integrated with the SailFish Utilities. Unfortunately, in PM2 the fingerprint is missing among the category therefore I choose others
About the FP reader restart
Looking at the running process, I found these about FP reader:
[root@sfos defaultuser]# ps | grep fpd
2904 root /usr/lib64/qt5/plugins/devicelock/encsfa-fpd --daemon
4887 root /usr/bin/sailfish-fpd --systemd
4888 root /usr/libexec/sailfish-fpd/fpslave --log-to=syslog --log-level=4
4954 root grep fpd
Restarting the service is quite immediate:
[root@sfos defaultuser]# time systemctl restart sailfish-fpd
real 0m 0.14s
To understand which processes were restarted I did a stop and a check:
[root@sfos defaultuser]# ps | grep fpd
2904 root /usr/lib64/qt5/plugins/devicelock/encsfa-fpd --daemon
5107 root grep fpd
Probably the restart from Utilities will restart also the QT5 plug-in, I did not verified the code of service_do function but considering the parameters passed to the function, it is about systemctl.
About power saving on Xperia 10 II
My Xperia 10 II is running with energy power saving alway active and at the beginning it shown some troubles about BT and FP reader awakening which forced me to reset that sub-systems.
I should not say this because it will be considered trolling but…
After having configured some options about suspending/awakening hardware subsystems in Android while I was running the Android Support, the BT and FP reader never got stuck anymore even with AS stopped. However, the counterside is that my smartphone - when left alone without no any interaction or connections active - started to be busy in suspend/awake the systems continuosly loading the CPU for 25% but with no impact on the battery discharge rate (less than 1%) because the CPU seems busy by System Monitor handling I/O but no power is drained because there is no code/math processing.
In fact, the dmesg -Hw shows a lot of this stuff on the WARN level and above:
[ +0.000236] ------------[ cut here ]------------
[ +0.000202] WARNING: CPU: 7 PID: 6013 at /home/abuild/rpmbuild/BUILD/kernel/sony/msm-4.14/kernel/mm/vmscan.c:1685 isolate_lru_page+0x1e0/0x1e8
[ +0.000365] ---[ end trace b94aa1c373c520dc ]---
[ +0.001869] cache: parent cpu2 should not be sleeping
[ +0.026021] OOM killer enabled.
[ +0.000003] Restarting tasks ... done.
[ +0.022791] PM: PM: suspend exit 2023-06-18 08:17:15.039700682 UTC
[ +0.000003] PM: suspend exit
[ +0.045724] ## mmc1: mmc_gpio_set_uim2_en: gpio=101 value=1
[ +4.943132] PM: PM: suspend entry 2023-06-18 08:17:20.028365718 UTC
[ +0.000016] PM: suspend entry (deep)
[ +0.000010] PM: Syncing filesystems ... done.
[ +0.015110] Freezing user space processes ... (elapsed 0.040 seconds) done.
[ +0.040466] OOM killer disabled.
[ +0.000002] Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
[ +0.003784] Suspending console(s) (use no_console_suspend to debug)
[ +0.029206] Disabling non-boot CPUs ...
[ +0.002401] CPU1: shutdown
[ +0.005101] CPU2: shutdown
[ +0.004633] IRQ 7: no longer affine to CPU3
[ +0.000259] CPU3: shutdown
[ +0.004800] CPU4: shutdown
[ +0.003805] CPU5: shutdown
[ +0.003962] CPU6: shutdown
[ +0.004003] CPU7: shutdown
[ +0.003154] suspend ns: 30885642235516 suspend cycles: 1068241562170
[ -0.000010] resume cycles: 1069294245240
[ +0.000854] Enabling non-boot CPUs ...
[ +0.001628] CPU1 is up
[ +2.401109] somc_panel_color_manager: somc_panel_inject_crtc_overrides (788): Override: Already have original funcs! Is setup called twice??
[ +0.000435] somc_panel_color_manager: somc_panel_pcc_setup (886): Cannot read uv data: missing command
If what written above is correct (because correlation does not necessarly means cause-effect relationship) then SFOS should correctly set the FP reader about suspend/aswakening. About BT, one single event even in conjunction with the FP reader failure make the assumption statistically too weak,
Original hi-res image is here.
About FingerPrint reader service
Considering how fast is the FP reader service in being started
[root@sfos defaultuser]# systemctl stop sailfish-fpd
[root@sfos defaultuser]# time systemctl start sailfish-fpd
real 0m 0.16s
and the few static places in which it is needed 1. unlock the screen and 2. add a new fingerprint, I think that it would a sane policy to start it only when it is necessary and stop immediately after. By default do start it at the boot time.
Unlock the screen:
- is there a PIN set?
no: proceed - is there a FP set, at least?
no: wait for the PIN - start the FP service
- does unlock succeed?
no: wait for unlock or timeout - timeout exipired?
stop the FP service - stop the FP service
Add a new fingerprint:
- start the FP service
- acquire the fingerprint
- stop the FP service
Probably implementing the logic about unlocking the screen would be easier that the one described because those check are just done for sure. Therefore there are just three points to change: start, stop and stop. Instead, the logic for adding a fingerprint is straightforward.