search

sailfishos-patches / patchmanager

Patchmanager for SailfishOS
https://openrepos.net/content/patchmanager/patchmanager
Other
21 stars 22 forks source link

[PM3 question] Why is the SFOS GUI always started twice after booting? #36

Open Olf0 opened 5 years ago

Olf0 commented 5 years ago

Patchmanager 3 always restarts the SFOS GUI right after it has been initialised and displayed after booting. Patchmanager is expected to restart the SFOS GUI, if Settings -> Patchmanager -> Settings -> Apply on boot is switched off (the default), after interactively acknowledging the application of the installed Patches. But on first sight (which is at least partially wrong, see below) the same procedure seems to be carried out, when this setting is switched on, just without the interactive dialogue. This is somewhat surprising, as PM2 does not show this behavior (i.e. does not restart the SFOS GUI twice).

When looking more closely, all Patches already seem that be applied in the initial bring-up of the SFOS GUI (i.e. before it is restarted), if Settings -> Patchmanager -> Settings -> Apply on boot is switched on in PM3, by judging from the look of the lock-screen (i.e., patched!). On a Jolla 1 phone the initial SFOS GUI starts so far, that one can switch to the unlocking panel of the lock-screen (plus the charging sound and notification appear, if a charger is plugged in), before the SFOS GUI is restarted by PM3. On an Xperia X the restart occurs earlier, so one only gets to shortly peek a the patched lock-screen, before the SFOS GUI is restarted.

Hence I am asking, if the restarting the SFOS GUI is really necessary, when Settings -> Patchmanager -> Settings -> Apply on boot is switched on in PM3? It would be nice, if future PM3 versions mimic PM2's behavior in this aspect.

Advantages, if this behavior could be eliminated:

Tested with Patchmanager 3.0.55 under SailfishOS 2.2.0, 2.2.1 and 3.0.0 on a Jolla 1 phone and an Xperia X. Edit: I forgot to mention that I think it needs a device without a SIM-card inserted (or disabled "SIM security") and a disabled the device-lock (those two "testing phones" stay at home) to observe this behavior.

Olf0 commented 5 years ago

Cross checked against my "production phone" under SFOS 2.2.1.18 with Patchmanager 2 and both Settings -> Device lock -> Use security code and Settings -> PIN code -> Require PIN code (temporarily) switched off: PM2 really does not show this behavior (I became insecure, if I remembered that correctly from when the "testing phones" still had PM2 installed).

Olf0 commented 5 years ago

I have not observed this issue with Patchmanager 3.0.57, anymore. Is this supposed to be fixed?

Olf0 commented 5 years ago

My former comment was written way too quick and brief:

I have not observed this issue with Patchmanager 3.0.57, anymore.

Considering the original question posed in the issue headline: No. But I assume a restart of lipstick / the SFOS UI is unavoidable the way PM3 works. Side note: Mmmh, maybe PM3 could delay the start of lipstick until its "live patching" mechanism is up and running (Edit: e.g. by a Before=lipstick.service statement in a systemd unit). (Just a spontaneous idea.)

But there seems to be a speed-up in PM 3.0.57, as with it (in contrast to PM 3.0.55) my Jolla 1 (still under SFOS 2.2.1) never reaches the point on first start of the SFOS UI anymore, when the charging sound is played. The behaviour of PM 3.0.57 on an Xperia X with SFOS 3.0.2 is similar (seemingly a bit faster than PM 3.0.55).

Is this supposed to be fixed?

Well @CODeRUS, if you looked at this and did, what is easy to implement, you may close this issue. If my perceived, slight speed-up is just wishful thinking, then please leave it open.