Evidence for a battery-drain change should make the test reproducible. A screenshot of the battery percentage is not enough because screen use, signal quality, background activity, device condition, and the test workload can all affect the result. Preserve the release context, the controlled scenario, the platform diagnostics, and the decision that followed.
Identify the software and device state
Record the app version, build identifier, release channel, operating-system version, device model, and test date. Note approximate battery health when the platform exposes it, whether the device was charging, screen-brightness setting, network type, location use, notifications, account state, and other known high-activity apps. Do not collect unrelated personal content from the device.
Describe the suspected change in plain language and link it to the approved change request or commit. List the affected feature flags, background jobs, synchronization behavior, location behavior, and network calls. Preserve the previous known-good build through the authorized release system rather than an untrusted package archive.
Keep a repeatable workload
Write the exact test steps, start and end conditions, foreground duration, background duration, and expected user actions. Record the starting charge and elapsed time, but treat percentage movement as one signal rather than the whole result. The same workload should be run on the candidate and comparison build under reasonably similar conditions.
For Android, Google documents how to profile battery use with Batterystats and Battery Historian. The procedure can reset earlier collection and generate a bug report after a controlled period. Record the reset time, collection window, commands used, and report filename. Reset only on a dedicated test device because it removes the previous Batterystats collection.
For iOS, Apple publishes guidance for analyzing an app’s battery use in Xcode. Record the Xcode version, connected device, scenario, capture period, and saved result. Keep Android and iOS evidence in separate lanes because their tools and measurements are not interchangeable.
Preserve the comparison, not just the raw files
Store the diagnostic report with the build and scenario identifiers. Summarize the observed CPU activity, wake locks or background execution, alarms, location use, network activity, and time active when those signals are available. Mark observations separately from hypotheses. A timeline showing activity does not by itself prove which line of code caused it.
Run the same scenario on the known-good build or with the suspected feature disabled. Preserve both captures and record every deviation, such as a changed network or notification arrival. State the acceptance threshold before reviewing the result. If the run is noisy or not repeatable, label it inconclusive and repeat it rather than selecting the more favorable result.
Retain the release decision
Record who reviewed the evidence, the decision time, affected release channels, and whether the team paused rollout, rolled back, disabled a feature, or continued monitoring. Link any user communication and follow-up defect. Verify that the mitigation did not cause data loss, crashes, sign-in failure, or broken background behavior.
The durable packet should contain the change request, build identifiers, device matrix, workload, raw captures, summarized comparison, deviations, reviewer, decision, and corrective actions. Apply access controls and retention rules to diagnostic files, and remove unnecessary personal information before sharing them outside the incident team.