EcoTrace
Android Energy Intelligence Platform
Every Android battery tool tells you what is draining the battery. Battery Historian tells you a wakelock was held for two hours. Android Profiler tells you the radio never slept. None of them tell you why.
Why is not a pattern-matching problem. It is a reasoning problem: understanding how one architectural decision — a repeating alarm registered in MainActivity.onCreate() — propagates through six layers of a codebase to become a drain that only shows up on a physical device. A linter sees the last link of that chain and stops.
Built at the IBM Bob 2.0 Hackathon
September 25–27, 2026 · Fully online · 48-hour build with team Code & Chaos. The brief was to improve a specific developer workflow using IBM Bob 2.0 — an AI development partner with full repository context — and to demonstrate impact rather than assistance. Projects were judged on application of technology, presentation, business value and originality.
View the submission on lablab.aiHow it works
Three stages, in order. The third is the one that matters.
- 01
Detect
23 energy detectors run over the Java and Kotlin sources, surfacing candidate drain across wakefulness, network, location and lifecycle patterns.
- 02
Trace
A real cross-file call graph is built and walked backwards from each finding to the lifecycle entry point that caused it, so the report names the decision rather than the line.
- 03
Explain and fix
Every finding is reported with its causal chain, its provenance, and a fix authored against that specific chain — then re-verified by the same detectors that produced it.
The 23 detectors
Grouped by the resource they protect. Every detector runs offline.
Wakefulness
Unclosed WakeLock, missing release on error path, wakelock held across configuration change
Network
Polling loops with postDelayed, unbounded retry without backoff, redundant periodic sync jobs
Location
Sub-30-second GPS intervals, location updates requested in onCreate, missing significant-change optimization
Lifecycle & Jobs
JobInfo constraints written but never submitted, alarms re-armed from onCreate, work scheduled per-resume instead of once
The self-verifying agent loop
IBM Bob 2.0 is not a chat panel bolted onto the tool. It sits inside a loop that the tool itself can reject.
Whole-repository ingestion
The entire repository goes into IBM Bob 2.0, which holds every file in a single reasoning pass rather than reasoning over one snippet at a time.
Severity revision and description correction
Bob revises the severity EcoTrace assigned and rewrites the description — including for defects the local pass attributed to the wrong method.
Chain-specific fix
Bob writes the fix against the specific traced chain, so the patch addresses the architectural cause rather than muting the symptom.
Self-verification
Bob proposes a patch; EcoTrace re-runs its own detectors over it. A patch that silences a rule by deleting the construct is rejected outright.
Branch, never main
Accepted changes land on a branch for a human to merge. The agent never writes to main.
What makes it different
It reasons about cause, not symptoms
The call graph is the product. Findings are not a flat list of lines — each one is walked backwards to the lifecycle entry point that put it there. A leaked wakelock inside NetworkManager is reported as the symptom of a repeating alarm registered in MainActivity that re-arms the path 96 times a day.
It is honest about provenance
Every number reports where it came from: measured, estimator-derived, or unknown. A tool that quietly blends a heuristic with a real measurement is worse than no tool, because the reader cannot tell which is which.
It works without a key
All 23 detectors, call-graph chains, grading, history and reporting run offline, deterministically and free. IBM Bob makes the analysis sharper; it is never a prerequisite. A tool that only works when you hand it an API key is a demo, not a product.
Measured where devices are available
For teams that have hardware, EcoTrace parsesadb shell dumpsys batterystats snapshots and differences them into a drain rate in mAh/min, attributed to the app under test rather than to the whole device. Where no device is available the same report is produced from the static analysis, and each figure says which of the two it is.
Output is a self-contained HTML or PDF report that attaches to the ticket, plus an optional one-click patch that is authored, verified and branched for review.
Stack
- Kotlin
- Java
- Android
- Gradle
- AST analysis
- Call graph
- IBM Bob 2.0
- adb batterystats
- HTML/PDF reports