Mobile/PowerManagement
Different OSes have different application lifecycles. Depending on application states, we might want to do certain things.
We should also compare to what Windows, OS X and Linux do on laptops, as power stuff is important there as well. In particular this can help design the API.
Contents
States
The system-display-dimmed system notification indicates that the screen is not being showed, so the user can't see it. All drawing to the screen can be suppressed at that time (not frozen, since it should appear to have been running during that time). However, we cannot suspend downloads, music playing, calculations, network access, etc.
If a mobile OS has a notion of 'should be totally idle' - then it should likely close or freeze (SIGSTOP) Firefox itself (Android in particular does this - it can close any app at any time, if it wants). We can consider doing that ourselves on other OSes, if they truly have such states, see discussion in bug 581314.
Old Thoughts and Ideas - Out of Date
| State | Brief Description | Android | Maemo |
|---|---|---|---|
| Active | In the foreground, running | ? | + |
| Background Visible | In the background - should still run | ? | + |
| Background Invisible | In the background - should still run, but not visible | ? | + |
| Standby | The application should freeze itself. It is still loaded only in order to quickly continue operation | ? | + |
Mjarvin: for my opinion it's not just Background Invisible. Application can be on foreground, but still invisible (when screen dims).
Detailed Descriptions
- Background Visible: The browser should use less power if it can, but only minor optimizations.
- Background Invisible: The browser should use less power if it can, and can stop showing animations and other costly visual effects.
Maemo states
All these states are supported in Maemo. Also case when browser is started on device startup should be considered as a similar case to "Background Invisible".
System Notices
| Notice | Description | Android | Maemo |
|---|---|---|---|
| AC Power | Connected to a power source | ? | + |
| Battery | Running on battery power | ? | + |
| Low Battery | Battery will last for a while longer, but minutes - not hours | ? | + |
| Critical Battery | Battery can stop working at any time | ? | + |
| Display Off | Screen has been shut off | ? | + |
| Display Dimmed | Screen has been dimmed, either manually or by user inactivity | ? | + |
| Display On | Screen has been turned on | ? | + |
Maemo notices
We can get above notices on maemo.
Most of this is already done in gtk port (in nsNativeAppSupport class), but currently messages sent over observerService are not used anywhere. This code uses libosso functions to retrieve values.
There is qt mobility api coming which adds qt interfaces to these , but thats not currently supported on N900 or older devices. We could directly listen to D-Bus messages sent by bme/mce. These messages goes on system bus, with com.nokia.bme.signal and com.nokia.mce.signal interfaces. Through mce we could receive display state changes and from bme we could receive battery changes.
