Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Olf0 opened this issue Nov 18, 2018 · 3 comments
Open
Labels
#question someone asked something

Comments

@Olf0
Copy link
Contributor

Olf0 commented Nov 18, 2018

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:

  • Shortened boot time.
  • Visually nicer boot experience.
  • Makes a more trustworthy impression for users.

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
Copy link
Contributor Author

Olf0 commented Nov 19, 2018

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
Copy link
Contributor Author

Olf0 commented Jan 26, 2019

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

@Olf0
Copy link
Contributor Author

Olf0 commented Apr 23, 2019

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.

@nephros nephros added the #question someone asked something label Nov 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
#question someone asked something
Projects
None yet
Development

No branches or pull requests

2 participants