A battery showing 100% charge is not necessarily a healthy battery, and a high cycle count does not by itself predict how many hours a device will work today. Procurement and fleet teams need separate evidence for current charge, available capacity, accumulated use, temperature or fault state, and the rule used to retire a specific battery.
This guide uses an editorial service-pool example. It does not claim smart-battery telemetry, cycle reporting, a replacement threshold or a runtime guarantee for any AIDC GO model. Confirm those functions for the exact device, battery part number, operating-system build and management tool.
Identify the battery, not only the handheld
When batteries are removable, the handheld serial number and battery serial number describe different assets. Record the device model, battery part number, battery serial number if available, manufacture date if exposed, firmware or OS build, charger or cradle used and the application workload. Without battery identity, a result can follow the device while the actual battery has already been swapped.
Use the handheld-terminal category to shortlist the device configuration, then request the exact battery and charging documentation through Integration Support. A product image or removable back cover does not establish that battery telemetry is available.
Separate state of charge from state of health
Android's BatteryManager reference defines remaining capacity as a percentage and exposes other properties or broadcasts such as charge counter, energy counter, health and, from API level 34, cycle count. Availability and resolution still depend on the device implementation. A full charge reading tells you the current charge state relative to what the system reports; it does not state how much original capacity remains or how the battery will perform under the planned workload.
The Android Open Source Project's device-power measurement guidance notes that available fuel-gauge properties and their resolution depend on the gauge hardware, connection and software configuration. Compare like-for-like devices and recorded conditions rather than treating one percentage as a universal laboratory measurement.
Understand what cycle and health fields mean
Cycle count, aggregated charge, present capacity and a vendor health classification are different measures. Zebra's named Enterprise Browser battery API describes smart-battery serial, part number, charge cycles, rated capacity, manufacture date and health for supported Zebra devices, while warning that not all values are supported by all batteries and that cycle count may not accurately predict battery life.
Zebra's current Device Diagnostic Tool guide provides another named example: supported PowerPrecision battery tests can report part number, serial number, manufacture date, health, voltage, current, temperature, level and, for supported PowerPrecision+ batteries, current capacity. These examples show the kind of evidence a fleet tool can expose. They do not establish equivalent fields for an AIDC GO device.
Compare the four evidence types
| Evidence | What it can support | What it cannot prove by itself |
|---|---|---|
| Charge level at a recorded time | Whether the system reports the battery near empty, partial or full at that moment | Original capacity, remaining service life or shift runtime |
| Cycle or aggregated-use value | How the supported battery system counts accumulated charging use | Runtime under the current app, radio, scan and temperature workload |
| Capacity or vendor health result | A device- or vendor-defined capacity/health assessment for the named battery and tool | That another battery type, OS build or management interface exposes the same result |
| Controlled workload result | Observed start/end level, interruptions and task completion under recorded conditions | A universal runtime guarantee or future performance after further aging |
Keep the tool version and field definition beside the value. A label such as “good” is not portable unless the underlying threshold and applicable battery class are known.
Run a controlled service-pool comparison
Consider an editorial pool with three identified batteries. The team fully charges them using the approved path, records each serial and available health fields, then runs the same application build through a fixed sequence of scans, data entry, network activity and idle periods. It records start and end charge, any restart or low-battery event, ambient condition and completed tasks.
Battery A may complete the sequence without an interruption, Battery B may trigger the vendor tool's replacement state, and Battery C may expose no cycle or health metric. These are three different outcomes. Do not invent a cycle estimate for Battery C or replace it solely because its telemetry is unavailable; route it through the documented workload and physical-safety assessment.
The battery swap and shift charging guide covers how charged batteries rotate through a working day. K100 instead determines whether each identified battery remains eligible for that rotation.
Define replacement and quarantine rules
Use the device or battery manufacturer's documented health classification and threshold when available. Add operational evidence such as repeated early shutdowns, failure to complete the controlled workload, charging faults or physical damage. Safety concerns such as swelling, leakage or abnormal heat require the manufacturer's handling procedure rather than another performance test.
Record who can quarantine a battery, how the battery is marked, where it is stored, how a replacement is linked to the device pool and how retired batteries are handled under applicable rules. Do not use a generic internet cycle number as the purchase threshold for an unverified battery design.
The spare-device pool guide explains why replacement hardware must also have the approved software and accessories. The USB-C charging guide helps separate battery condition from an incorrect power source, cable or dock path.
Recheck after changes that affect the result
Repeat the comparison after a battery replacement, charger or cradle change, OS update, scanner-service change, application release or major workload change. Preserve prior results rather than overwriting them so the team can distinguish battery aging from a changed test.
Use the Android update guide to record the delivered build and post-update application result. A new build may alter telemetry access or workload behavior without changing the battery itself.
Send an evidence-specific request
Provide the device model and region, battery part number and chemistry documentation, removable or sealed design, expected shift workflow, charger and cradle path, operating temperature, required telemetry fields, tool and OS versions, controlled workload, replacement rule, quarantine owner and disposal requirement. Include the exact values observed for each identified battery.
Use Contact to send the project details. The supplier can identify available battery, charger and telemetry documentation for the shortlisted configuration; the fleet and application teams remain responsible for workload design, replacement approval and service records.