I’m wondering how the Librem 5 (or more precisely how KDEMobile/Phosh/etc.) are going to manage locking a device while preserving background functionalities (like receiving msgs) as well as apps life cycle ?
As I see it, now that Flatpak is using Portal through D-Bus, we start to see a cleaner API emerge which basically consists to interact only through D-Bus to access resources. This also allows sand-boxing & a permission system.
-> This is the parallel with Android’s Binder IPC & permission system.
However I see two missing pieces left to have a mobile OS :
A “modern” app life cycle management. On Android we have a well defined App LifeCycle which can be in multiple states. This is very important for resources saving. Without this kind of lifecycle, battery is going to go down extremely fast.
Android can safely kill any app at any time because it knows the app can restore its state (which is kind of confusing on Android for some users, there is no notion of app “running” or not, because if it is killed it will restore its state and the user cannot notice it).
If an app needs to run in background (music player, downloads, etc…) there are very specific background process / media APIs that allows it. This is because as an app can be killed at any moment, we cannot rely on the app to handle background tasks. This policy results in a well controlled and efficient management of apps and resources.
So I was wondering which kind of solution could there be for KDE/Phosh/etc. here ? Killing an app when not in focus cannot work (you couldn’t listen to music or download a file) and apps are not made to restore their state. Living all apps open might kill the battery / take all the RAM. To me it seems very problematic…
Something that can be done is telling the Wayland Compositor to not send the “update UI” signal for non-focused apps. This save some unnecessary UI redraws but the app is still running and taking CPU/RAM potentially.
The second very problematic aspect is Sleep / Lock vs Background services. When you lock the phone, it must still be able to receive messages, check updates, receive calls, etc… But just turning off the screen and not going to sleep would drain the battery in a few hours. By going to S3 Sleep without waking up mechanism, then you can’t receive a call or msgs.
Android implemented the controversial wakelocks : https://lwn.net/Articles/318611/
And has different well defined APIs that will leverage them and be able to wakeup on events or to regularly check updates for receive msg on a server, etc…
Currently there is nothing on linux distros that solve this. So I was wondering how Purism is approaching the problem ? Is there a conversation with Kernel Dev & Flatpak/FreeDesktop.org to come to an agreement on how to expose an API that allows this ? Also I guess this is related to the “Connected Standby” or S0ix of some processors.
So I would be curious if you know links to any recent discussion on the topic by Purism, Flatpak or Kernel devs ? Or if you know if they have any idea on how they plan to solve those two issues ?
I don’t know a way to quickly and nicely solve it as great as in android with preserving states and such, but a possible “good enough” solution to avoid battery drain for now would be to suspend the processes. That way we can for example fetch an SMS while screen is locked without also having all other applications start spinning up aswell. They would have to create a service which suspends all application processes when going to sleep, and a nice addition would be to have the ability for apps to ask for being in a whilelist temporarily (such as a music player). Some applications also don’t properly handle being suspended, but most simple GTK/Qt apps should.
Really good question about wakelocks also, I don’t have any experience with that so I can’t answer that question.
Thanks for your answers ! Indeed whitelist could be a solution and this would require minimal changes for already existing apps (for e.g Firefox asks to be whitelisted when it is downloading a file, or a music player when it plays a song).
But I guess an issue is that some whitelisted apps would prevent the phone to ever go to sleep. Whitelists are okay for continuous tasks like downloads or music where you don’t want to sleep, but for periodic tasks this is problematic.
If we take a simple alarm clock, it will prevent the phone to ever go to sleep because it has to ring every morning at 8am.
So I guess there will still be a need for some sort D-Bus service that would manages those. There could be a service where apps notify the D-Bus service that they need to run some code every X seconds or at time Y. Then it’s up to that D-Bus service to manage going to sleep & waking-up. So when we lock the phone, if there is only an event planned at 8am then it knows it can go to sleep until 8am.
"We discussed this a bit at the flatpak bof - application life-cycle, foreground/background apps, etc. This needs some careful planning and infrastructure."
I hope we will end up with an API/Architecture that is elegant. It would be nice to have open discussions with many different parties (Kernel dev, Flatpak, Purism, KDE Mobile, Necunos, Gnome, etc.) about that because this is going to be very important for the future of mainstream Linux on tablets & phones
New APIs may restrict the phone too much to be only usable with those apps that support these.
Maybe there could be something like classic local SOCKS and proxy servers running (useable by classic applications) which are whitelisted in order to keep connections open etc. while the classic applications are suspended. And the proxies may be patched to wake up other processes and thus the phone as necessary.
I think in the long run a suitable API for such a management is the only elegant and efficient way to be able to be competitive on the mobile phone market. The great goal should be that all involved parties (Purism, KDE, GNOME, …) must cooperate to integrate this API into e.g. libhandy or similar. This topic may be one of the essential topics which have an impact on the success or failure of such big mobile phone linux projects as it has a direct impact on how people experience the mobile OS and find it usable. There will (in the near to mid future) always be a trade off between unity (mobile + dektop applications in one) and power efficiency.
Completely agree, but I suppose with new APIs it might be still possible to have Android’s power efficiency as long as the user is using those new apps only (and have more battery drain only if the user decides to launch legacy desktop apps).
It’d be nice if Purism posts a few blog-posts on that topic in the future so we can follow how things are shaping up
So I guess you can at least prevent the phone to go to sleep. The API allows to prevent “Logout” , “User Switch”, “Suspend” , “Idle”. It is maybe a bit too fine-grained in the context of a mobile phone but at least we have such an API so that’s good.
There is still the need for periodic/planned wake-up (alarm clock, check msg, etc, …) and see how all those fit with app lifecycle, background/forground, power management, etc.
Actually, solutions for all these things seem available since there is support for laptops and netbooks in the linux kernel. Laptop-mode, ramlogs, anacron, just to name a few. Part of the purism pitch was a phone that is able to run standard linux systems.
This does not mean there shouldn’t be any support for special app environments, possibly even emulating walled-gardens for dubious closed source software that had been created in the past, but for free software there shouldn’t be much of a need or incentive for such things. The better standard applications behave about using resources (incl. using things like cron or at jobs, etc. to work even if not running) and are able to sleep or suspend, the better they’ll work on a mobile phone.
For eg as far as I know you cannot trigger for e.g a wake-up from sleep without sudo (using rtcwake for example) and to take the example of the cron jobs, letting an app edit them would allow it to execute anything. This is out of question to allow apps to have such privileges. So it seems a natural way to use an IPC layer that let you talk with services that allow you to perform similar functionalities but in a controlled/sandboxed way like Flatpak is doing.
But I think a modern clean model (common IPC API, secure, sandboxed, signed, permission system, can’t execute arbitrary apps, etc.) can co-exist with the messy “old” desktop model of the 90s that we are currently using (unsecure, edit cron jobs & .bashrc to execute anything, run sudo stuff, execute unsandboxed program outside flatpak, no common api, mess around in the terminal, etc…) if it is enabled only for “advanced users” (a kind of developer mode).
This is just some random thoughts and just my point of view, but I think it is extremely important for Linux OSes to agree on a common IPC API if they want a future because of :
security : the current desktop model of the 90s is just craziness in terms of security, any apps can access any resources (mic, camera, etc), can execute anything and can access all your files. This model has to die (but as I mentioned we can keep a “developer mode” for programmers where you can execute anything, open a terminal, etc. but for any regular user we don’t want this total lack of security).
And the open-source argument against that is not sufficient. I want Firefox to be sandboxed because it might have a security breach, I want Atom to be sandboxed because it is vulnerable to code injection and because it executes un-trusted add-on from the web which can access anything on my computer, I want Blender to be sandboxed because .blend files I download might contain python scripts which can also do anything, etc. Moreover many people will always use at least some proprietary apps.
simplicity & maintainability : a single versioned spec where everybody (KDE/GNOME/Purism/etc.) can all come together to design and agree on a IPC API. Apps can target a particular version of the API. No more hacky ways to do the same things in a dozens of different ways.
We can tell all soft dev & companies around the world : “On any Linux distro, if you want to access the microphone, you have make these calls over that IPC. Period. End of the story.”.
Currently it’s like “Well on X you can use ALSA and do that call to that library, on Y you can use OSS, oh, but also you should rather use PulseAudio on those distro, oh but wait, some apps rather directly write to /dev/dsp but for that you need root, but then you could also etc. etc. etc. etc…”. Nobody want to write an app for such a mess.
portability / efficiency / future proof : If there is only one common layer, then any improvement we make under that layer will benefit all apps. A change of underlying technology does not affect the apps. If underneath the distro wants to use ALSA, OSS, cron, anacron, etc. it does whatever it wants, but on the surface there is only one well defined IPC layer accessible to the app. And there is only this layer to port if you want to support those apps on another OS/distro.
We can take an analogy : the Web. It is because we have a single common API that we can run the web everywhere, sandboxed and that it is so successful. We can have a single doc (Official Spec, MDN) where dev can just go, look at “microphone” doc and this is the only one way to use it.
And it applies down to all the stack of the web (Physical vs Link vs IP vs Transport vs Application layer). This is why we didn’t have to re-invent the web when we started to use optical fiber instead of copper wire.
We can also look at Android : same story (security, simplicity for developers, etc…) and in terms of portability I suspect it’s not going to be too hard for them to make make android apps compatible with Fushia. All they have to do is expose an IPC layer that implements Binder’s API.
We don’t know what the future will be, but the more we abstract away from the intricacies of the OS the more any work we do will be re-usable and portable.
Weren’t the arguments by pulseaudo also about unifying into a common API etc.?
I think device access and sandboxing should be solved nicely separated.
(Unix style, small tools doing specific things well.)
In any case, it’s the recent linux kernels that provide the features to sandbox applications.
One example tool that can manage arbitrary applications is firejail. There could be nice defaults to run everything in it’s own firejail.
“Everything is a file” (also sockets and devices) already is a common unix interface with programmers having libs available in every language. I don’t think it is necessary for the librem 5 to mix in another one and attempting to force unification on another level, because the problem will need a broader linux solution.
Hasn’t the web rather become a mess for application building? Based on a plethora of javascript frameworks with all different page/content/resource APIs.
Basicly, what I mean is that it could be better to take the time to think about “smaller” solutions that can actually be more universal, than “large” constructions that can be rather self-specific.
I can’t give you concrete answers to your questions at the moment because I am still finding my way around issues like these, but it’s good that you bring them up. Part of my job is to document applications development on the Librem 5, so the corresponding mechanism to the application lifecycle on Android is something I’m aiming to describe.
Earlier phone environments like Qtopia had ways to effectively suspend applications, though this wasn’t based around a cross-platform standard. Again, things like writing applications that don’t just drain the battery is something that needs to be documented (see this issue) and taking advantage of existing frameworks to do this is desirable.
To add to David’s answer, we discussed power management since the early stages of the project. One of the ideas was to use a suspend daemon that would manage applications that don’t need to be running. A different approach we discussed was an equivalent to “connected standby”, because talking to the network cannot be easily suspended.
In the end, there is precedent with the N900, which didn’t sleep at all and still managed 2+ days of battery life. That’s what we’re going to focus on at first: make sure that programs behave nicely, and downclock or turn off hardware when not in use. That should be a solid base for any future improvements anyway.
Thanks for your posts. Sounds like a good approach to me.
Regarding the suspend daemon, there is of course the need of some hardware interrupt line for the powered modem that needs to be present, to allow…
EDIT: …waking up the low-power core of the CPU and…
…triggering the daemon (and for it to decide to wake up individual apps). Not sure if wifi and bluetooth could support to wake up the CPU from suspend.
That’s a correct observation and we’re not getting away with sleep modes without interrupts from communication devices. Thankfully, interrupts are unavoidable to operate both WiFi and the modem.
This definitely would work great for general use cases, but I would like to have the option for application to provide specialized background services. For example, having a video editing application render my video while my phone is charging.
Maybe Flatpak applications could offer a Systemd service that can be run in a restricted environment. It would have it’s own lifecycle so that the phone can turn off the daemon without losing any data.
This is already largely a solved problem in mainline linux: SIGSTOP. The default is to let programs run, but it would be pretty easy to create a daemon that manages background programs and suspends them when they are unfocused and idle. Then again, well written programs generally fall into a select/poll/epoll loop and when unfocused should go to consuming ~0 CPU time anyway.