How to Detect and Optimize Android App Battery Drain with Bytecode Hooking

Background

Android devices often hide battery‑drain problems because most apps run only a few seconds per launch, making it hard for users to notice excessive power consumption. The article introduces a systematic way to understand and measure battery usage at the framework level.

System Battery Statistics

The core entry point is getCurrentBatteryUsageStats, which gathers data from a list of PowerCalculator objects. The default list includes calculators for battery charge, CPU, memory, WakeLocks, radio, Wi‑Fi, Bluetooth, sensors, GNSS, camera, audio, video, phone, screen, ambient display, idle, custom measurements and user‑level stats.

private List<PowerCalculator> getPowerCalculators() {
    synchronized (mLock) {
        if (mPowerCalculators == null) {
            mPowerCalculators = new ArrayList<>();
            mPowerCalculators.add(new BatteryChargeCalculator());
            mPowerCalculators.add(new CpuPowerCalculator(mPowerProfile));
            mPowerCalculators.add(new MemoryPowerCalculator(mPowerProfile));
            mPowerCalculators.add(new WakelockPowerCalculator(mPowerProfile));
            // … many more calculators …
            mPowerCalculators.add(new SystemServicePowerCalculator(mPowerProfile));
        }
        return mPowerCalculators;
    }
}

Power consumption is divided into direct (e.g., GPS, Bluetooth) and indirect (e.g., WakeLocks that keep the CPU awake). Direct consumption can be a single factor, while indirect consumption often aggregates many sources.

Choosing the APIs to Hook

Based on the system’s power model, the following high‑impact APIs are targeted for instrumentation:

Location: requestLocationUpdates, removeUpdates Bluetooth scanning: startScan, stopScan Sensor registration: registerListener, unregisterListener WakeLocks: acquire, release Alarms: setExact,

setExactAndAllowWhileIdle

Bytecode‑Level Hooking Strategy

All target methods are virtual ( INVOKEVIRTUAL). To capture parameters and the caller class without breaking the original call, the bytecode is rewritten to:

Insert a LDC instruction that pushes the caller’s class name onto the stack.

Replace the original INVOKEVIRTUAL with INVOKESTATIC that points to a custom hook method.

The hook method receives the original arguments plus the caller name, records the data, and then forwards the call to the original implementation.

Before transformation (simplified):

... 
ALOAD 3
CHECKCAST android/hardware/SensorEventListener
ALOAD 4
ICONST_0
INVOKEVIRTUAL android/hardware/SensorManager.registerListener(...)
POP

After transformation:

... 
ALOAD 3
CHECKCAST android/hardware/SensorEventListener
ALOAD 4
ICONST_0
LDC "com.example.myapp.MainActivity"
INVOKESTATIC com/battery/api/Hooks.registerListener(...)

ASM Helper – replaceNode

static public void replaceNode(MethodInsnNode node, ClassNode klass, MethodNode method, String owner) {
    LdcInsnNode ldc = new LdcInsnNode(klass.name);
    method.instructions.insertBefore(node, ldc);
    node.setOpcode(Opcodes.INVOKESTATIC);
    int anchorIndex = node.desc.indexOf(")");
    String subDesc = node.desc.substring(anchorIndex);
    String origin = node.desc.substring(1, anchorIndex);
    node.desc = "(L" + node.owner + ";" + origin + "Ljava/lang/String;" + subDesc;
    node.owner = owner;
    System.out.println("replaceNode result is " + node);
}

The helper is called for each matched method, passing a boolean predicate that decides whether the method belongs to the target class (e.g., android/hardware/SensorManager).

Data Structures for Collected Information

All hook data implement InvokeData and are stored in a thread‑safe ConcurrentHashMap. The most detailed example is WakeLockData, which records acquisition count, release count, total hold time, reference‑count flag, automatic timeout releases, and the class names of the acquire/release callers.

class WakeLockData : InvokeData(), BatteryConsumer, Serializable {
    var acquireTime: Int = 0
    var releaseTime: Int = 0
    var useTime: Long = 0L
    var startHoldTime: Long = 0L
    var lastAcquireTime: Long = 0L
    var endHoldTime: Long = 0L
    var isRefCounted = true
    var autoReleaseByTimeOver: Long = 0L
    var autoReleaseTime: Int = 0
    var holdClassName: String = ""
    var releaseClassName: String = ""
    private fun isRelease(): Boolean { /* logic omitted for brevity */ }
    override fun getRecordingBatteryConsume(): Double { /* uses powerProfile.wakeLockPower */ }
    override fun getRecordedBatteryConsume(): Double { /* uses powerProfile.wakeLockPower */ }
    override fun toString() = "WakeLockData(acquireTime=$acquireTime, releaseTime=$releaseTime, useTime=$useTime, isRefCounted=$isRefCounted, autoReleaseByTimeOver=$autoReleaseByTimeOver, autoReleaseTime=$autoReleaseTime, holdClassName='$holdClassName', releaseClassName='$releaseClassName')"
}

Power Profile Parsing

The tool can read the device’s power_profile.xml (bundled in framework-res.apk) to obtain baseline power values (e.g., bluetooth.on, gps.on, cpu.idle, wifi.on, screen.on). These values are used to convert recorded hold times into milli‑ampere‑hours (mAh).

fun parseXml(inputStream: InputStream?): BatteryPowerProfile? {
    if (inputStream == null) {
        Log.e(Constant.TAG, "inputStream is null, make sure power_profile.xml is in the asset!")
        return null
    }
    val powerProfile = BatteryPowerProfile()
    val parser = Xml.newPullParser()
    parser.setInput(inputStream, "utf-8")
    var type = parser.eventType
    while (type != XmlPullParser.END_DOCUMENT) {
        if (type == XmlPullParser.START_TAG && parser.name == "item") {
            when (parser.getAttributeValue(null, "name")) {
                "bluetooth.on" -> powerProfile.bluetooth = parser.nextText().toDouble()
                "gps.on" -> powerProfile.gps = parser.nextText().toDouble()
                "cpu.idle" -> powerProfile.wakeLockPower = parser.nextText().toDouble()
                "battery.capacity" -> powerProfile.capacity = parser.nextText().toDouble()
                "wifi.on" -> powerProfile.wifiOn = parser.nextText().toDouble()
                "screen.on" -> powerProfile.screenOnPower = parser.nextText().toDouble()
            }
        }
        type = parser.next()
    }
    return powerProfile
}

SPI‑Based Dumping

When a hook reaches a terminal state (e.g., a WakeLock is released), the InvokeHashMap invokes a user‑provided dumper via Java ServiceLoader. The dumper receives the final InvokeState and the populated InvokeData object, allowing the host application to export CSV, JSON, or feed a monitoring dashboard.

Real‑World Cases Solved

Long‑Lived WakeLocks : Detected a global WakeLock that was never released in a specific feature flag, leading to a battery‑drain warning from device manufacturers. Fixing the release eliminated the warning.

Sensor Leaks : Identified a legacy component that kept a sensor listener registered for hours, consuming power unnecessarily. The listener was correctly unregistered.

Excessive GPS Requests : Found code that requested GPS updates every 3 seconds even when coarse location would suffice. Switching to PASSIVE_PROVIDER reduced GPS power consumption dramatically.

Open‑Source Release

The complete instrumentation library, power‑profile parser, and data‑dumping framework have been open‑sourced so that other Android teams can adopt the same low‑overhead, compile‑time hooking technique for battery analysis.