Power, Thermal & Battery

The power stack at a glance

A device is always in one of a few power states, and the difference in current between them is enormous. Almost all battery engineering is about spending more time in the low states and less in the high ones. The stack that decides this spans hardware (PMIC, clocks, co-processor), the kernel (cpuidle, cpufreq, suspend, wakeup sources, thermal), the HALs (power, thermal, health, power stats) and the framework (PowerManagerService, DeviceIdleController, JobScheduler, AlarmManager, ThermalManagerService, BatteryStatsService).

Framework   PowerManagerService  DeviceIdleController  JobScheduler  AlarmManager  ThermalManagerService  BatteryStats
               |                    |                      |             |               |                     |
HALs        SystemSuspend (suspend HAL)   Power HAL (hints)   Thermal HAL   Health HAL   Power Stats HAL
               |                                              |             |              |
Kernel      suspend / autosleep / wakeup sources   cpuidle   cpufreq   thermal zones   power_supply   rail monitors
               |                                                                              |
Hardware    PMIC, clocks, regulators, CPUs, DDR, always-on co-processor, fuel gauge, charger, thermistors

Suspend and resume: the sleep machine

Android power saving is built on Linux suspend-to-RAM. When nothing needs the CPU, the whole system suspends: tasks are frozen, devices are put to sleep through their driver callbacks, non-boot CPUs go offline, clocks and regulators are gated, and RAM stays in self-refresh. Something must actively block suspend (a wakeup source or wakelock), and something must trigger resume (a wake-capable interrupt).

The suspend sequence

1. Decide to suspend On Android the userspace SystemSuspend service (the suspend HAL) waits until no wakelocks are held, reads /sys/power/wakeup_count, writes it back, then writes mem to /sys/power/state.
2. Freeze The kernel freezes userspace tasks and freezable kernel threads.
3. Device suspend Drivers run their prepare, suspend, suspend_late and suspend_noirq callbacks. Any driver returning an error aborts the whole suspend.
4. CPUs down Non-boot CPUs are taken offline, syscore callbacks run, and the platform enters its deepest state (on Arm through PSCI firmware; on Qualcomm SoCs rails and the crystal oscillator can be shut down).
5. Wake A wake-capable interrupt fires. Resume runs the callbacks in reverse order, thaws tasks, and the kernel records the wakeup reason.

no wakelocks held
   -> SystemSuspend: read wakeup_count, write it back (fails if a wakeup event happened in between)
   -> echo mem > /sys/power/state
   -> freeze tasks -> suspend devices -> offline CPUs -> platform low-power state
                                                         |
                          wake IRQ (RTC, button, sensor, modem, BT) 
                                                         v
   <- thaw tasks  <- resume devices  <- online CPUs  <- platform resume
   -> wakeup reason logged; the event usually takes a wakeup source briefly so the work can run

Autosleep, suspend blockers and wakeup sources

• Suspend blockers were Android's original (2009) kernel mechanism: "opportunistic suspend" whenever no blocker was held. They were controversial upstream and never merged as-is.
• Wakeup sources are the mainline Linux object that replaced the idea. They were introduced in kernel 2.6.37 (2010). A driver creates one and calls __pm_stay_awake / __pm_relax, or pm_wakeup_event with a timeout, to block suspend while it handles an event.
• Autosleep and userspace wakelocks landed later, in kernel 3.5 (2012). /sys/power/autosleep lets the kernel itself suspend whenever no wakeup source is active; /sys/power/wake_lock and wake_unlock expose a userspace wakelock interface compatible with Android's old API.
• Modern Android (Android 10 and later) usually does not use autosleep. The SystemSuspend service tracks userspace wakelocks itself, uses the wakeup_count handshake to avoid races, and triggers suspend. Kernel wakeup sources still block suspend from drivers.
• Mem sleep modes: /sys/power/mem_sleep selects between s2idle (suspend-to-idle, CPUs in deepest idle) and deep (full suspend-to-RAM), depending on platform support.

cpuidle is not suspend

Wakelocks: what keeps the device awake

A wakelock is a request to keep the CPU (and optionally the screen) from sleeping. In apps it is a PowerManager.WakeLock; PowerManagerService tracks them and asks SystemSuspend to hold a native wakelock while any are held. Drivers use kernel wakeup sources. Held too long or too often, both destroy standby battery.

Kinds of leaks

• Never released: exception path skips release().
• Held during stalled I/O: a network or Binder call that hangs while the lock is held.
• Re-acquired in a loop: short locks acquired thousands of times, each waking the AP.
• Kernel side: a driver takes a wakeup source on every interrupt of a chatty device, or never relaxes it.
• Fake work: a foreground service kept alive to avoid process death, holding a lock for "just in case" work.

// Correct pattern: always use a timeout and release in finally
val wl = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "myapp:sync")
wl.acquire(10 * 60 * 1000L)   // timeout as a safety net
try {
    doShortWork()
} finally {
    if (wl.isHeld) wl.release()
}

CPU power while awake: DVFS, cpufreq, cpuidle and EAS

Suspend decides whether the application processor is on. The next question is how expensive that awake time is. Dynamic voltage and frequency scaling (DVFS), the cpufreq and cpuidle governors, and Energy Aware Scheduling (EAS) decide which cores run, at what frequency and voltage, and how deeply idle cores sleep between tasks. A device that never suspends but stays on little cores at a low OPP can still last a day; the same workload pinned to a big core at max frequency will not.

DVFS and cpufreq

Dynamic voltage and frequency scaling changes a CPU cluster's clock and its supply voltage together. Dynamic power is roughly proportional to C·V²·f, so dropping voltage with frequency saves more than frequency alone. Each cluster has an operating-performance-point (OPP) table (device tree or firmware) of legal frequency and voltage pairs. The cpufreq subsystem picks an OPP; cooling devices and thermal policy can cap the maximum.

adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

cpuidle: C-states between tasks

When a CPU has no runnable task it enters an idle state. Each state has an exit latency and a target residency: if the predicted idle time is shorter than the residency, a shallower state is cheaper because the entry and exit energy would not be paid back. Governors: menu (predicts idle duration from recent history) and teo (Timer Events Oriented, the usual modern default). States typically run from WFI (wait-for-interrupt, shallow, fast exit), through cluster clock gating, to cluster power collapse and rail collapse (deepest, longest wake). This is per-CPU idle, not system suspend: timers still fire, DDR and shared rails usually stay on. See the compare box under Suspend and resume.

Energy Aware Scheduling

EAS uses an energy model of each CPU (capacity and power at each OPP, from the device tree or firmware) plus PELT utilization to place a waking task on the CPU that can meet its needs with the least energy. Small tasks stay on little cores; heavy tasks go to big or prime cores. It works with schedutil. When the system is overutilized (not enough spare capacity), EAS steps aside and ordinary load balancing takes over so performance is not sacrificed. Android steers it with:

• uclamp (utilization clamp): uclamp.min boosts a task (used for top-app and launches) so schedutil raises frequency; uclamp.max caps background work.
• cpusets / cgroups: top-app may use all clusters; background and cached apps are often limited to little cores.

EAS replaced earlier big.LITTLE placement (HMP and vendor scheduler hooks) on modern Android Common Kernels. It was developed on Android kernels first and mainlined around Linux 5.0. Scheduler detail lives on the Linux Kernel & BSP page; the power takeaway is that placement plus frequency decides energy per unit of work, and a wrong boost (everything on big cores at max OPP) shows up as heat and drain, not as a functional bug.

Doze, App Standby and standby buckets

Wakelocks are the mechanism; Doze and App Standby are the policy. They stop apps from waking the device whenever they like by deferring network access, jobs, syncs and alarms into shared maintenance windows. Batching many apps' work into one wakeup is far cheaper than letting each app wake the device separately.

Light Doze and deep Doze

screen off, on battery
  ACTIVE -> INACTIVE -> IDLE_PENDING -> SENSING -> LOCATING -> IDLE
                                                                |  ^
                                                   maintenance  v  |  window gaps grow over time
                                                         IDLE_MAINTENANCE
motion / screen on / charger  ->  back to ACTIVE

What still gets through Doze

• setExactAndAllowWhileIdle() and setAndAllowWhileIdle() alarms, rate-limited per app.
• setAlarmClock() alarms (user-visible alarms); the system leaves idle shortly before they fire.
• High-priority FCM messages, which grant the app a short temporary exemption to do work; they should be used only for user-visible events.
• Apps on the battery-optimization allowlist (for example, companion or accessibility apps with a strong reason).

App Standby buckets (Android 9+)

Adaptive Battery can predict usage and assign buckets. Android 12 did not invent Restricted; it made unused or misbehaving apps more likely to land there, and added app hibernation (unused apps have permissions revoked and their cache cleared). Android 12 also freezes cached processes so they do not run. Android 13 added Low Power Standby: after a long unused period (screen off, not charging), the device applies even tighter idle restrictions than deep Doze. Separately, background execution limits (Android 8+) stop apps from running background services freely, Android 12+ restricts starting foreground services from the background, and Android 14+ requires a declared foreground service type. Exact alarms need the SCHEDULE_EXACT_ALARM or USE_EXACT_ALARM permission on recent releases; allow-while-idle exact alarms are rate-limited to roughly one every nine minutes while idle. Battery Saver mode adds further restrictions on top of buckets and Doze.

# Force Doze for testing
adb shell dumpsys battery unplug
adb shell dumpsys deviceidle force-idle       # jump straight to deep idle
adb shell dumpsys deviceidle step             # or step through states
adb shell dumpsys deviceidle get deep
adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset

# Standby buckets
adb shell am get-standby-bucket com.example.app
adb shell am set-standby-bucket com.example.app rare

Deferred work: WorkManager, JobScheduler and AlarmManager

Apps and system components should never run their own timers to wake the device. Android offers scheduling APIs that let the system batch work, respect Doze and buckets, and pick a good moment (charging, on unmetered network, idle).

Wakeup versus non-wakeup alarms

Alarm types ending in _WAKEUP (RTC_WAKEUP, ELAPSED_REALTIME_WAKEUP) wake the device from suspend; the others fire only when the device is next awake. Prefer ELAPSED_REALTIME types for intervals, since wall-clock time can change.

Sensor-hub and always-on offload

The single biggest wearable power lever, and an important phone one, is to run always-on work on low-power hardware so the application processor stays suspended for minutes at a time. The sensor hub (always-on co-processor) is the main example, but the same idea appears in audio, Wi-Fi, Bluetooth, GNSS and cellular data paths.

Sensors -> [ always-on hub: fusion + FIFO batching, AP asleep ] -> batch full or event -> wake IRQ
                                                                   -> AP resumes briefly
                                                                   -> HAL -> framework -> app
                                                                   -> AP suspends again
Battery win = AP asleep time, maximized by batch size and offload coverage

Other offloads worth naming

Thermal: skin temperature and throttling

Every watt consumed becomes heat. Handheld and wearable devices have no fans, so heat must spread through the case into the air and the user's skin. Thermal management keeps components below their limits and, most importantly for wearables and phones, keeps the surface the user touches comfortable and safe.

Why it is acute on wearables

• Worn against the skin for hours, so skin-temperature limits for prolonged contact (in the low 40s degrees Celsius, set by product and safety standards) bind before silicon junction limits.
• Tiny thermal mass heats up quickly during workouts with GPS, LTE calls, and charging (charging itself produces heat in the battery and charger).
• Heat and power feed each other: hotter silicon leaks more current, which produces more heat.

The thermal stack

Sensors: on-die sensors (CPU, GPU, modem), board thermistors, battery thermistor
   -> Kernel thermal framework: thermal zones + trip points + governors
        cooling devices: cpufreq, GPU devfreq, charge current, modem, backlight
   -> Fast hardware limiters: CPU frequency limits, battery current limiting on voltage droop
   -> Userspace thermal engine / vendor policy: virtual skin sensor, multi-sensor rules
   -> Thermal HAL (AIDL IThermal): temperatures, thresholds, cooling devices, callbacks
   -> ThermalManagerService -> PowerManager thermal status and headroom -> apps back off
   -> At SHUTDOWN severity the framework shuts the device down cleanly

adb shell dumpsys thermalservice                       # HAL temperatures, status, cooling devices
adb shell 'for z in /sys/class/thermal/thermal_zone*; do echo "$(cat $z/type) $(cat $z/temp)"; done'
adb shell cat /sys/class/thermal/cooling_device*/cur_state
adb shell cmd thermalservice override-status 3         # simulate SEVERE for app testing
adb shell cmd thermalservice reset

Power HAL and ADPF performance hints

The kernel governors react to load they already see. Launching an activity, handling a touch, or rendering a game frame needs the frequency and core placement to rise before the load shows up in PELT, otherwise the first 50 to 200 ms feel slow. The Power HAL and the Android Dynamic Performance Framework (ADPF) are how the framework and apps tell the SoC that work is coming, and how they back off before thermal throttling hits.

Power HAL

The Power HAL (android.hardware.power; HIDL 1.x, then AIDL from Android 11) is implemented by the vendor and called from PowerManagerService, the activity manager, input, HWUI and others. It does not run the CPUs itself; it programs the same knobs EAS and cpufreq already expose (uclamp, schedtune, cpusets, temporary max-freq boosts, often a vendor "boost" driver).

On a wearable the same HAL is where you tune "boost hard enough that wrist-raise to face is fast, then drop immediately so AOD current stays in budget." Over-long interaction boosts are a common silent drain.

ADPF

ADPF (Android 12+) is the app-facing, closed-loop version of the same idea. PerformanceHintManager.createHintSession(tids, targetNanos) tells the platform "these threads should finish one unit of work every N nanoseconds." The app then calls reportActualWorkDuration() each cycle. The vendor uses the error (actual versus target) to raise or lower frequency instead of a blind timed boost. HWUI uses sessions for RenderThread; games and camera pipelines should too.

• Thermal headroom (PowerManager.getThermalHeadroom(seconds), Android 11+) is part of the same story: forecast how close the device is to throttling so the app can drop frame rate or quality first. See Thermal.
• Thermal status listeners (Android 10+) report the stepped severity the Thermal HAL publishes.
• Later releases add more ADPF surfaces (GPU hints and extra headroom APIs). The interview point is the loop: target duration, actual duration, thermal headroom, then back off before the kernel thermal governor slams frequency.

// Sketch: one ADPF session for a render loop
val hintMgr = getSystemService(PerformanceHintManager::class.java)
val session = hintMgr.createHintSession(intArrayOf(Process.myTid()), 8_333_333L) // 120 Hz
// each frame:
val start = SystemClock.elapsedRealtimeNanos()
drawFrame()
session?.reportActualWorkDuration(SystemClock.elapsedRealtimeNanos() - start)

Battery: fuel gauge, charging and health

The battery subsystem answers three questions: how much charge is left (fuel gauge), how to refill it safely and quickly (charger), and how to keep the cell healthy for years (charging policy). Mistakes here show up as sudden shutdowns at 15%, percentage jumps, slow charging, swelling, or capacity fading too fast.

Android battery plumbing

Fuel gauge + charger (PMIC)  ->  kernel power_supply class  (/sys/class/power_supply/battery/...)
   -> Health HAL (HIDL 2.x; AIDL android.hardware.health from Android 13)  ->  BatteryService
   -> ACTION_BATTERY_CHANGED broadcast, BatteryManager properties, Settings battery UI
   -> BatteryStatsService attributes drain to apps and components (batterystats)
         using ODPM / Power Stats HAL rails when present, else power_profile.xml models

Without on-device rail monitors, batterystats estimates energy from a device-specific power_profile.xml (CPU cluster current at each frequency, screen, radios, GPS, DSP, and similar). A profile copied from another board makes Settings "battery usage" lie; treat it as a model and confirm with a lab monitor or Power Stats HAL rails.

adb shell dumpsys battery                                   # level, status, temperature, plugged
adb shell cat /sys/class/power_supply/battery/capacity      # percent
adb shell cat /sys/class/power_supply/battery/current_now   # usually microamps, sign convention varies
adb shell cat /sys/class/power_supply/battery/voltage_now   # microvolts
adb shell cat /sys/class/power_supply/battery/cycle_count

The power debug toolbox

Power debugging is evidence work: quantify the drain, find what is awake and why, attribute it to an owner, fix, and re-measure. Each tool answers a different question, and a good engineer knows which one to reach for first.

Battery Historian workflow

# Start clean, on battery, with a fixed use-case
adb shell dumpsys batterystats --reset
adb shell dumpsys batterystats --enable full-wake-history   # richer wakelock history
# unplug USB or use Wi-Fi adb, run the scenario for a fixed time
adb bugreport bugreport.zip
# Load bugreport.zip into a locally hosted Battery Historian instance
# (open source; run it inside the company network, never upload bugreports to public sites)

Battery Historian turns a bugreport into a timeline of wakelocks, wakeup reasons, CPU running, screen, radio, Doze state, jobs, alarms and per-app statistics. It is useful for "battery regressed" triage, although newer work relies more on Perfetto.

Perfetto with power data

# Perfetto config fragment: battery counters and power rails
data_sources {
  config {
    name: "android.power"
    android_power_config {
      battery_poll_ms: 250
      battery_counters: BATTERY_COUNTER_CURRENT
      battery_counters: BATTERY_COUNTER_CHARGE
      collect_power_rails: true
    }
  }
}
data_sources { config { name: "linux.ftrace"
  ftrace_config { ftrace_events: "power/suspend_resume" ftrace_events: "power/cpu_idle"
                  ftrace_events: "power/cpu_frequency" ftrace_events: "power/wakeup_source_activate" } } }

Power rails come from the Power Stats HAL, backed on supported devices by on-device power monitors (ODPM) that measure energy per rail. Combined with scheduling, frequency, idle and suspend events in one trace, you can see exactly which process woke the device and what it cost.

Kernel-level checks

adb shell cat /sys/kernel/debug/wakeup_sources    # active_count, event_count, total_time, active_since
adb shell cat /sys/kernel/debug/suspend_stats     # success, fail, last_failed_dev, last_failed_errno
adb shell cat /sys/kernel/wakeup_reasons/last_resume_reason
adb shell cat /sys/power/mem_sleep
adb shell cat /proc/interrupts                    # take two snapshots and diff
adb shell dmesg | grep -iE "PM: suspend|wakeup|resume"

A triage method that works

1. Quantify Measure drain per hour or average current for a fixed scenario on several devices, before and after.
2. Is it suspending? Suspend residency and suspend failures. If not suspending, find the holder.
3. Why does it wake? Wakeup reasons and interrupt deltas; alarms, jobs and network in Doze.
4. What runs when awake? Per-process CPU, sensors, radio activity, rails in Perfetto.
5. Attribute and bisect Map to an owner; bisect builds or components if it is a regression.
6. Fix and prevent Fix, re-measure with the same scenario, and add or tighten a regression gate.

Product KPIs and how a platform lead gates on them

A platform lead is accountable for delivering a product that is competitive on functionality, stability, power and performance. That only works if each is turned into measurable KPIs with budgets, tracked on every integration drop, and enforced as promotion gates rather than discovered in the field.

How to gate well

1. Set budgets Agree targets per use case (for example standby current, workout drain, boot time) with product and hardware teams, and split them into per-component budgets.
2. Control the measurement Fixed devices, firmware, accounts, brightness, radio environment; several devices and repeated runs so the noise band is known.
3. Compare with baseline Every drop is compared with the last good build; a change larger than the noise band and the threshold is a regression.
4. Block or waive A regression blocks promotion into the main image unless explicitly waived with an owner and a fix date.
5. Attribute fast Automated bisection across the drop's changes, with dashboards showing which component moved.
6. Watch the field After release, field telemetry (battery drain distributions, crash and ANR rates, thermal events) confirms lab results and catches long-tail issues.

Quick revision

• Battery life is roughly capacity divided by average current; average current is dominated by suspend residency.
• Suspend-to-RAM freezes tasks, suspends devices, offlines CPUs and puts DDR in self-refresh; only wake interrupts resume it.
• One driver's failing suspend callback aborts the whole suspend; check suspend_stats and last_failed_dev.
• Modern Android triggers suspend from the SystemSuspend service using the wakeup_count handshake and /sys/power/state.
• Suspend blockers were Android's original (2009) mechanism. Mainline wakeup sources arrived in kernel 2.6.37 (2010); autosleep and /sys/power/wake_lock followed in 3.5 (2012).
• cpuidle is per-CPU idling between tasks; system suspend is the whole device sleeping.
• DVFS scales frequency and voltage together; dynamic power is roughly C·V²·f.
• cpufreq governors: historic Android interactive, modern default schedutil (frequency from scheduler utilization).
• cpuidle governors (menu, TEO) pick a C-state by predicted idle time versus target residency.
• EAS places tasks using a per-CPU energy model; it yields to ordinary load balancing when the system is overutilized.
• Android steers EAS with uclamp (min boosts, max caps) and cpusets (top-app versus background).
• The Power HAL (AIDL from Android 11) implements short setBoost hints (interaction, launch) and longer setMode (interactive, low power, sustained performance).
• ADPF (Android 12+) hint sessions close the loop: target work duration versus actual, plus thermal headroom so apps back off before throttle.
• A partial wakelock keeps the CPU on with the screen off; it is the number one invisible drain.
• Always acquire wakelocks with a timeout and release in a finally block; tag them as app:component.
• Kernel wakeup sources are visible in /sys/kernel/debug/wakeup_sources; app wakelocks in dumpsys power.
• Light Doze starts soon after screen off on battery; deep Doze requires the device to be stationary.
• In deep Doze, network, jobs, syncs, standard alarms and Wi-Fi scans are deferred and app wakelocks are ignored.
• Exact allow-while-idle alarms, alarm-clock alarms, high-priority FCM and allowlisted apps get through Doze.
• App Standby buckets: active, working set, frequent, rare, restricted (Restricted added in Android 11, API 30).
• Android 12 adds app hibernation and cached-app freezer; Android 13 adds Low Power Standby for long unused periods.
• Allow-while-idle exact alarms are rate-limited to roughly one every nine minutes while idle.
• WorkManager is the default for deferrable guaranteed work; periodic minimum is 15 minutes.
• Exact alarms wake the AP and need special permission; use them only for user-visible times.
• Handler.postDelayed uses uptime, which stops during suspend.
• The sensor hub runs always-on sensing with FIFO batching so the AP stays suspended.
• Other offloads: CHRE nanoapps, audio DSP hotword, Wi-Fi packet filtering, BLE scan filtering, GNSS batching, modem DRX.
• Skin temperature, not junction temperature, is usually the binding thermal limit on phones and watches.
• Thermal zones have trip points; cooling devices (cpufreq, GPU, charge current, modem) are applied by governors.
• The thermal HAL reports severities from NONE to SHUTDOWN; apps use thermal status listeners and headroom.
• Heat increases leakage, which increases power, which increases heat.
• batterystats uses Power Stats HAL rails when present, otherwise a device power_profile.xml model.
• Fuel gauges combine voltage models and coulomb counting, corrected for temperature and aging.
• Lithium-ion charging is constant current then constant voltage; JEITA zones limit charging when hot or cold.
• Voltage droop under load plus an aging cell causes shutdowns at non-zero percent.
• Battery Historian turns a bugreport into a drain timeline; run it locally and keep bugreports internal.
• Perfetto with power rails shows energy per rail alongside scheduling, frequency and suspend events.
• Never measure power with USB attached; use a power monitor or pure battery runs in a controlled setup.
• Triage: quantify, check suspend, find the waker, attribute, bisect, fix, re-measure, gate.
• Gate each integration drop on power, thermal, stability, performance and functionality KPIs against a baseline and noise band.

Glossary

ADPF

Android Dynamic Performance Framework: hint sessions (target versus actual work duration) and thermal headroom so apps and HWUI can hold a frame rate without over-boosting.

Adaptive Battery

Android feature that predicts app usage to place apps in standby buckets.

App hibernation

Android 12+ state for unused apps: permissions revoked and cache cleared until the user opens the app again.

AlarmManager

Android API for time-based triggers, inexact or exact, optionally waking the device.

ANR

Application Not Responding: the main thread was blocked too long; a stability KPI.

App Standby bucket

Per-app category (active, working set, frequent, rare, restricted) that limits background jobs and alarms.

Autosleep

Kernel mode in which the system suspends automatically whenever no wakeup source is active.

Battery Historian

Open-source tool that visualizes batterystats from a bugreport as a timeline.

batterystats

Framework service and dumpsys output that attributes battery use to apps and components.

CHRE

Context Hub Runtime Environment: runs small nanoapps on the low-power sensor hub.

Cooling device

Kernel thermal object that can reduce heat, such as CPU frequency, GPU frequency or charge current.

Coulomb counting

Measuring charge in and out by integrating current over time.

cpufreq

Kernel subsystem that sets CPU frequency and voltage (DVFS) via a governor such as schedutil or interactive.

cpuidle

Kernel subsystem that puts idle CPUs into low-power idle states between tasks, chosen by latency and target residency.

Doze

Device-wide idle mode that defers apps' network, jobs and alarms into maintenance windows.

DRX / eDRX

Modem sleep cycles between paging occasions; extended DRX gives longer sleep.

DVFS

Dynamic voltage and frequency scaling: clock and supply voltage move together; dynamic power scales about as V²f.

EAS

Energy Aware Scheduling: places tasks using a per-CPU energy model and PELT utilization; pairs with schedutil.

Foreground service

Service with a visible notification that the system keeps alive for user-visible work.

Fuel gauge

Hardware and algorithm that estimate battery state of charge and health.

Health HAL

HAL that reports battery and charger information to BatteryService.

JEITA

Industry guideline that adjusts charge current and voltage by battery temperature.

JobScheduler

Android system service that runs background jobs when constraints are met, batched and Doze-aware.

Low Power Standby

Android 13+ deeper idle after a long unused period, with tighter restrictions than ordinary deep Doze.

Maintenance window

Short period during Doze when deferred work is allowed to run.

ODPM

On-device power monitor: hardware that measures energy per power rail, exposed through the Power Stats HAL.

OPP

Operating performance point: a legal frequency and voltage pair for a CPU or GPU cluster.

Partial wakelock

Wakelock that keeps the CPU running while allowing the screen to turn off.

PerformanceHintManager

ADPF API that creates a hint session for a set of threads with a target work duration.

Perfetto

Android's system-wide tracing tool, including power rails, battery counters and suspend events.

PMIC

Power management IC: regulators, charger, fuel gauge and power sequencing.

Power HAL

Vendor HAL (android.hardware.power) that applies boosts and modes (interaction, launch, low power) by programming cpufreq, uclamp and related knobs.

Power Stats HAL

HAL that exposes per-rail energy and per-subsystem residency data.

power_profile.xml

Device overlay of component currents used by batterystats when measured rails are not available.

PowerManagerService

Framework service that manages wakelocks, screen state and requests to suspend.

schedutil

cpufreq governor that sets frequency from scheduler utilization; the modern Android default.

Sensor hub

Always-on low-power processor that samples, fuses and batches sensor data.

Skin temperature

Estimated temperature of the device surface the user touches, often a virtual sensor.

State of charge (SOC)

Remaining battery charge as a percentage of current full capacity.

State of health (SOH)

Current full capacity relative to the original design capacity.

Suspend blocker

Android's original kernel mechanism for preventing opportunistic suspend; replaced by wakeup sources.

Suspend residency

Share of time the system spends suspended; the key standby power metric.

Suspend-to-RAM

System sleep state with DDR in self-refresh and most of the SoC powered down.

SystemSuspend

Android userspace service (suspend HAL) that tracks native wakelocks and triggers kernel suspend.

Thermal engine

Vendor thermal policy daemon or component implementing multi-sensor mitigation rules.

Thermal HAL

HAL that reports temperatures, thresholds and throttling severity to the framework.

Thermal zone

Kernel object for a temperature sensor with trip points and bound cooling devices.

Trip point

Temperature threshold in a thermal zone that triggers cooling or shutdown.

uclamp

Utilization clamp: per-task or per-cgroup min and max utilization that steers EAS and schedutil.

Wakelock

Request to keep the CPU (and optionally the screen) from sleeping.

Wakeup source

Kernel object that blocks system suspend while active; the mainline form of a wakelock.

WorkManager

Jetpack library for deferrable, guaranteed background work with constraints.

Interview questions