Run apps at specific times (and wake system from suspend if needed)

[jsparber]

I first started looking into how we can have apps start at specific times a few years ago, primarily to properly support alarm clock apps. Since then I had multiple discussions on how we can get rid of having to have a background process running for each app that needs to perform tasks priodically or at a specifc moment in time (like e.g. GNOME Clocks or Pika Backup are doing today).

Android has two features related to this:

• Alarm Manager: Allows to invoke intents at a specific time, or at repeating intervals. Alarms can either be precise (e.g. at exactly 17:00) or inexact (if an approximate time is fine, this allows the device to optimize wakeups). Alarms can also be set to go off in a window of time (e.g. 17:00 - 19:00).
• Work Manager: Allows to specify work that will be performed in the background based on various constraints (unmetered network, battery level, etc.), including at specific intervals.

My feeling is that for us a good first step is to focus on the Alarm Manager style use cases. They are both more common, and much easier to handle (seeing as they don't require a whole new system that executes background workloads).

Requirements

With that in mind I'd start with something like this as a scope:

• Activate an app
  • Precise moment in time (e.g. for alarm clocks)
  • Inexect moment in time: More or less at a given moment in time (e.g backups, check for new emails)
  • Time frame: Start between time A and time B
  • Repeating times: Wake app at an interval without precise timing so that system wakups could be minimized
• Activate app via
  • DBus activation
  • Command line: like in the background portal
• Allow the app to run for some time (maybe there should be a limit?)
• We need a way to go back to sleep after the app has done it's work if the system was woken up
• Permissions
  • Users should be able to decide whether an app can wake the system from suspend

Questions

Some things I'm wondering about:

• Should this be part of the background portal or a separate one?
  • Personally I'm leaning towards the former, since it's a very similar permission, which might cause cofusion. Ideally most apps would do this instead of always running in the background.
• Should there be a limit for how long apps can run when it's activated?
• After an app wakes up the system, how long do we wait to suspend the system again?
  • We have the inhibit portal which prevents suspend. Apps can use it to stop the system from suspending until they've done what they needed. Should apps be allowed to use this to prevent the system from suspending forever?

Prototypes

I've worked on two prototypes for this.

Older prototype from 2023:

• Draft background: Add ability to specify timers to start app #1098
• Extension to the background portal
• Very simple, allows any app that has the permission to run in the background to wake up the system and run the app at specific times
• Implemented and works, but very prototype-y

New prototype from last week:

• https://github.com/jsparber/xdg-desktop-portal/tree/alarm_timer_background_portal
• Extension to the background portal
• More involved addition to the background portal to set alarm times, following the requirements outlined above
• Work in progress, so far mostly defined the addtion to the D-Bus API

CC: @calebccff

[Mikenux]

To have a real alarm and work ("task") manager, the system will always need to identify what it is facing. Without that, no way no manage anything. When something is identified, then the system should knows what to do with it. To identify something, you are playing with constraints, limits (they can be minimal depending how you can group cases).

For wake-up, the app waking-up the system is not a property an app can set, but a property of a case where the system can decide to wake-up or not for this case.

For checking (like checking for new mails), this can be a case (as a direction) where the app asks to start each X time (time period maybe to be selected by the user) and have limit such as a given time window to do its thing before being stopped.

If you really want to have properties which can be combined at will, then it is about explaining how a system is supposed to manage things. Explaining facilitates review and acceptance of what you want without having to guess you have in mind.

[Mikenux]

Sorry, I only read the first part "RequestBackground". Now I saw the "AddAlarmTimes" method. (Is it necessary to duplicate things in both methods?)

My point remains the same: try to have specific cases (e.g. alarm only to alarm, task involving files, etc. and impose the constraints) rather than cases that are too vague (e.g., exact and inexact alarms, which do not seem necessarily intended to alarm if we think about the vocabulary to use). Don't forget that Google also uses an app review system that does not exist in xdg-desktop-portal.

[Mikenux]

A small feedback on the current work:

• "alarm": Perhaps be more generic because it will not only be intended for alarms.
• "alarm-time": Seems to be the general permission. However, this does not seem to allow an app to register both works that require starting at specific times and works that do not require it.

For the system, be clearer on what these new features should allow. Here is what I expect:

• Make background activity an exception.
• Use app focus (Restrict some portals to focused applications #42) to allow/disallow any app activity, as background activity can also be activity of an app that has a window but is not focused.
• Include current app activity (i.e. when the app is not running in the background and is focused). This should allow certain types of app activities to be disallowed or deferred, based on system state (e.g. very low battery).
• This would then mean overriding the restrictions imposed by the app focus and on background activity. This would require determining which portals are candidates for restrictions on background activity and with app focus usage, and how to override these with task registration.

Here is an example with the screenshot portal ("easy" case I looked at). Here I'm using a variation of the portal where the user can choose between the permissions "always allow the app to take screenshots" and "ask to take screenshots" (i.e. always display interactive mode).

• An app can only take screenshots when it is focused. This is not possible in the background and when it is not focused.
• To be able to take screenshots in the background or when not focused, the app must register tasks. This may need to be explicitly asked in some way. The advantage is that we can communicate that the app will take screenshots and possibly monitor the presence of this activity. This also allows the user to register such tasks even when the permission has been set to "ask to take screenshots".
• In the case of this portal, running tasks without asking the user to register them is not a good idea. This would allow the app to bypass focus and background restrictions and take screenshots without permission, especially if the app doesn't use other relevant permissions (due to their absence or lack of functionality).