PowerManagementArchitecture
Concepts
Lifecycle
In the short-term, e.g. October time frame, basic phone use case: one app active in the foreground. Apps put in the background are serialized as soon as possible and might be killed immediately to save memory.
For tablet: possibly multiple apps active (sidestage)?
For desktop and convergence: multiple apps active and shown at the same time.
Apps APIs
Background audio playback
- need to expose recommended codecs and audio format
- avoid app getting killed if it goes in the background
Full screen video playback
Keep screen on API? e.g. for a mapping app, photo booth app
Background tasks?
- downloads
Periodic task schedulers?
Aligned periodic tasks
- would be nice to tight to a hardware wakeup schedule (e.g. 3G pings)
Convergence: session management; prevent logout/shutdown/suspend?
Notifications (see notification server section)
Corresponding permissions:
- audio output (in the background?)
- keep screen on
- receive notifications
Settings and indicators
Most power states will be influenced by user settings set from a settings app or from indicators.
- airplane mode (turns off all radios)
- automatic vs. manual brightness; brightness level
- wifi on/off
- GPS on/off
- bluetooth on/off
- battery level; battery usage
- thermal management
Notification server
Avoids apps staying connected/generating traffic all the time as that keeps the device and its radio on, and it generates random network load.
Used to transfer incoming calls, messages, or other notifications.
Priority is indicated in notifications.
Lower priority notifications are consolidated.
Data collection
Track usage of resources, e.g.:
- screen
- radios (GPS, bluetooth, mobile signalling / mobile data, wifi...)
- sensors
- CPU/GPU cycles
We can assume that we have Android-ish kernels and drivers (wakelocks and such)
Track apps drawing power.
Battery charge tracking.
Do we collect app power usage?
Lab infrastructure
Per target device power metrics (mainly Nexus devices for now).
Automated software testing; system-wide, per app
Power benchmarks
Docs
Power management docs for application authors?
Implementation
Current stack
Uses gnome-power-manager, gnome-screensaver, gnome-settings-daemon, upower.
- (-) GNOME apps are very GNOME and X specific.
- (-) gnome-settings-daemon is a bit of a kitchen sink.
- (+) GPM provides interesting statistics
We're also using many indicators.
Proposed new stack
- Indicators
- Indicator services
- Settings app
- RILd/oFono for radio control
- Ubuntu platform API to control sensors
- Android sensors daemon
- Notification server
- Power manager -- needed for:
- tracking of battery state (e.g. to trigger shutdown)
- tracking of power consumption per-app and per-device
- adapting between Android-style drivers/kernels and upstreamish drivers/kernels
- perhaps adjusting system state on specific events; e.g. set CPUfreq governor when the screen is turned on/off
PowerManagementArchitecture (last edited 2013-04-10 13:58:43 by lool)