Android AI Features Without Draining the Battery

Android surfaces battery usage by app, by name, to the user. That single piece of platform design sets a constraint on every AI feature you ship: if it costs a noticeable share of the day's charge, a proportion of your users will find the screen that says so and act on it.

This is not a reason to avoid on-device inference. It is a reason to account for power the way you account for memory.

Where the power actually goes

It is rarely the model arithmetic itself, which is the part teams optimise first. On a typical feature the larger costs are elsewhere.

Keeping a sensor open. A camera session held for a preview is expensive whether or not you are doing anything with the frames. Microphone capture for wake-word detection runs continuously by definition. These often cost more than the inference they feed.

Running on the wrong processor. A model that falls back from the NPU to the CPU — because an operator is unsupported, or the delegate failed to initialise — may still work, and will use several times the energy while producing the same result more slowly. This failure is silent. Nothing throws. You find it by measuring, or you do not find it.

Waking the device. Background work that pulls the CPU out of a low-power state repeatedly is disproportionately costly. Ten small wakeups scattered across an hour cost far more than one batch of the same work.

Uploading. The radio is one of the most expensive components on the device, and it stays in a high-power state for a period after each transmission. Many small uploads keep it there almost continuously; one batched upload does not.

Practical measures that hold up

Match the inference rate to the need, not the sensor. A camera delivers 30 or 60 frames a second. Almost no classification feature needs to run on every frame. Document detection at four or five frames a second feels immediate and costs a fraction of the power. Decide the rate deliberately rather than inheriting it.

Stop when you are not visible. Tie inference to lifecycle properly, and verify it. An analyser that keeps running because a listener was registered against the wrong scope is one of the most common and most expensive bugs in this area, and it is invisible in normal testing because the feature works.

Verify the accelerator is actually being used. Log which delegate initialised, and treat a CPU fallback as an error worth reporting rather than a silent degradation. Otherwise one unsupported operator introduced in an updated model quietly triples the cost of the feature.

Batch and defer anything that can wait. Work that is not needed right now belongs in WorkManager with constraints attached — on charge, on unmetered network. Embedding a batch of documents for local search is a perfect candidate: nobody needs it this second, and done overnight on the charger it costs the user nothing.

Quantise, and check what it cost you. An INT8 model is smaller, faster and cheaper to run than a float model. It is also slightly less accurate, and how much depends entirely on your task. Measure the accuracy difference on your own data before assuming it is negligible, and measure it on the segment that matters most rather than overall.

Measure on the devices people own

A current flagship will hide most of these problems. It has thermal headroom, a fast NPU and a large battery, and a feature that is wasteful there can still feel fine.

The phones in your user base are mostly not that. Test on mid-range hardware from two or three years ago, and let it run for a realistic session rather than a thirty-second demo — sustained load is where thermal throttling appears, and once the device throttles, inference slows and the feature that felt instant starts to stutter.

Android's own tooling is adequate for this: Battery Historian for where the power went, the profiler for what held the CPU awake. The important discipline is making a power measurement part of shipping the feature, in the same way a crash-free rate is, rather than something investigated after a review mentions it.

The design decision underneath

The best power optimisation is usually not a smaller model. It is noticing that the feature does not need to run as often as it does.

Continuous detection is easy to build and hard to justify. Most features can be triggered — by the user pointing the camera at something, by a document appearing in frame, by an explicit tap — and a triggered feature costs a rounding error compared to a continuous one.

Ask what the feature would look like if it ran a tenth as often. Frequently the answer is that it would be identical from the user's point of view, and that answer is worth more than a week of kernel-level tuning.