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)