# Charging While Off

## Definition

A device that **can charge while off** can continue charging its battery when it is powered down (screen off, OS not running).

In practice, this is the *general rule* for many battery-powered devices. The important exceptions are:

- some devices **auto-boot when power is connected**, so they do not reliably stay off while charging

- some devices **cannot be turned off**, so an off-state session is not possible

- some devices **only charge while off**, meaning they must be powered down to accept charge

## How the app should decide ON vs OFF

When information is available, the app should decide the charging mode automatically:

- If the available information clearly indicates **ON** or **OFF**, use it.

- If the information indicates multiple plausible variants, show a **non-intrusive hint** that the user should specify whether the session is **ON** or **OFF**.

- If no information is available, the app assumes **ON** for devices that support **both ON and OFF charging** (for capacity learning and confidence rules).

## Why it matters for battery capacity estimation

Off-state charging sessions tend to produce the cleanest signal for estimating battery capacity (energy stored):

- Most of the measured input energy goes into the battery, instead of being consumed by the device itself.

- The result is less affected by background processes, radios, thermal throttling, screen usage, and OS-level behavior.

## App implications

### Defaults

- **Default assumption (for capacity learning):** if the user does not specify otherwise, a device is treated as **on/unknown-state** while charging.

### Capacity estimation priority (conceptual rule)

When we have both:

- high-confidence capacity determinations from **off-state** charging, and

- lower-confidence determinations from **on/unknown** charging,

then:

- off-state determinations are **preferred** for establishing the device’s capacity baseline

- on/unknown determinations **must not overwrite** off-state determinations, **except** when they imply a **smaller capacity**

  - example: the user logs a large measured energy, but later battery-percent checkpoints indicate the battery can’t actually hold that much energy (or has degraded), so we allow the estimate to move downward

### Current implementation note

For devices that are **not** marked as chargeable while off, the app **does not accept sessions that end at “full”** as capacity inputs (near-full can hide unknown “top-off” time/energy while the OS is doing its own work). For devices marked as chargeable while off, full / near-full sessions remain eligible.

## Device-specific notes (practical guidance)

- **iPhone:** tends to auto-boot when connected to a charger. To record an off-state session, you may need to shut it down after connecting power. Some factors can still trigger a boot even if the phone was shut down.

- **Powerbank:** treat as “chargeable only while off” (no active output load). For capacity learning, prefer sessions where the powerbank is not simultaneously powering other devices.

- **AirPods case:** treat as “off” **only if the earbuds are not inside** the case while charging (otherwise the case is also charging the earbuds).

- **Apple Watch:** cannot be reliably powered down for charging; treat as **always on**.

- **Garmin Edge bike computers / some Garmin watches:** treat as **chargeable only while off** (they need to be powered down to charge).