MailSyncer.prefetchIfEnabled() (MailSyncer.kt:140-151) decides whether to aggressively pre-download a
message's body/attachments purely from FetchPolicy (ALWAYS/WIFI_ONLY/ON_DEMAND) and, for WIFI_ONLY, whether the network is unmetered (isUnmetered()). There is no battery check anywhere in
this path — or anywhere in the app; no BatteryManager/battery-level usage exists today — so this
background prefetch keeps running at any battery level, including for ALWAYS/WIFI_ONLY users at
critically low battery.
Proposed behavior
Regardless of FetchPolicy, pause the aggressive content prefetch once battery is at or below 20%,
resuming once it rises back above that threshold (or the device starts charging — see open question).
Header sync (new-mail detection/notifications) is unaffected; this only pauses the aggressive
body/attachment pre-caching that prefetchIfEnabled performs.
Suggested approach
Add a battery check alongside the existing isUnmetered() (MailSyncer.kt:154-158), e.g. via BatteryManager.BATTERY_PROPERTY_CAPACITY:
and gate prefetchIfEnabled's shouldPrefetch on it in addition to the existing FetchPolicy switch
(MailSyncer.kt:141-145).
Open question
Should this still prefetch while charging even below 20% (a phone plugged in at 15% isn't under the same
pressure as one unplugged)? BatteryManager can also report charging state (BATTERY_PROPERTY_STATUS,
or the ACTION_BATTERY_CHANGED sticky broadcast) if that exemption is wanted.
Acceptance criteria
Content prefetch (all FetchPolicy values) pauses at ≤20% battery.
Prefetch resumes once battery rises back above the threshold (picked up on the next sync, not
necessarily instantly).
Decision recorded on the charging-exemption open question.
Unit test for the new gate (mockable battery source).
Relates to #88 (Wi-Fi-only default) and #90 (battery's effect on IMAP IDLE) — all three are about sync
behavior adapting to device resource constraints; may be worth a shared battery/network-state utility
rather than three ad hoc checks.
## Problem
`MailSyncer.prefetchIfEnabled()` (`MailSyncer.kt:140-151`) decides whether to aggressively pre-download a
message's body/attachments purely from `FetchPolicy` (`ALWAYS`/`WIFI_ONLY`/`ON_DEMAND`) and, for
`WIFI_ONLY`, whether the network is unmetered (`isUnmetered()`). There is no battery check anywhere in
this path — or anywhere in the app; no `BatteryManager`/battery-level usage exists today — so this
background prefetch keeps running at any battery level, including for `ALWAYS`/`WIFI_ONLY` users at
critically low battery.
## Proposed behavior
Regardless of `FetchPolicy`, pause the aggressive content prefetch once battery is at or below 20%,
resuming once it rises back above that threshold (or the device starts charging — see open question).
Header sync (new-mail detection/notifications) is unaffected; this only pauses the *aggressive*
body/attachment pre-caching that `prefetchIfEnabled` performs.
## Suggested approach
Add a battery check alongside the existing `isUnmetered()` (`MailSyncer.kt:154-158`), e.g. via
`BatteryManager.BATTERY_PROPERTY_CAPACITY`:
```kotlin
private fun isBatteryOk(): Boolean {
val batteryManager = context.getSystemService(BatteryManager::class.java) ?: return true
return batteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY) > LOW_BATTERY_CUTOFF
}
```
and gate `prefetchIfEnabled`'s `shouldPrefetch` on it in addition to the existing `FetchPolicy` switch
(`MailSyncer.kt:141-145`).
## Open question
Should this still prefetch while charging even below 20% (a phone plugged in at 15% isn't under the same
pressure as one unplugged)? `BatteryManager` can also report charging state (`BATTERY_PROPERTY_STATUS`,
or the `ACTION_BATTERY_CHANGED` sticky broadcast) if that exemption is wanted.
## Acceptance criteria
- [ ] Content prefetch (all `FetchPolicy` values) pauses at ≤20% battery.
- [ ] Prefetch resumes once battery rises back above the threshold (picked up on the next sync, not
necessarily instantly).
- [ ] Decision recorded on the charging-exemption open question.
- [ ] Unit test for the new gate (mockable battery source).
Relates to #88 (Wi-Fi-only default) and #90 (battery's effect on IMAP IDLE) — all three are about sync
behavior adapting to device resource constraints; may be worth a shared battery/network-state utility
rather than three ad hoc checks.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
MailSyncer.prefetchIfEnabled()(MailSyncer.kt:140-151) decides whether to aggressively pre-download amessage's body/attachments purely from
FetchPolicy(ALWAYS/WIFI_ONLY/ON_DEMAND) and, forWIFI_ONLY, whether the network is unmetered (isUnmetered()). There is no battery check anywhere inthis path — or anywhere in the app; no
BatteryManager/battery-level usage exists today — so thisbackground prefetch keeps running at any battery level, including for
ALWAYS/WIFI_ONLYusers atcritically low battery.
Proposed behavior
Regardless of
FetchPolicy, pause the aggressive content prefetch once battery is at or below 20%,resuming once it rises back above that threshold (or the device starts charging — see open question).
Header sync (new-mail detection/notifications) is unaffected; this only pauses the aggressive
body/attachment pre-caching that
prefetchIfEnabledperforms.Suggested approach
Add a battery check alongside the existing
isUnmetered()(MailSyncer.kt:154-158), e.g. viaBatteryManager.BATTERY_PROPERTY_CAPACITY:and gate
prefetchIfEnabled'sshouldPrefetchon it in addition to the existingFetchPolicyswitch(
MailSyncer.kt:141-145).Open question
Should this still prefetch while charging even below 20% (a phone plugged in at 15% isn't under the same
pressure as one unplugged)?
BatteryManagercan also report charging state (BATTERY_PROPERTY_STATUS,or the
ACTION_BATTERY_CHANGEDsticky broadcast) if that exemption is wanted.Acceptance criteria
FetchPolicyvalues) pauses at ≤20% battery.necessarily instantly).
Relates to #88 (Wi-Fi-only default) and #90 (battery's effect on IMAP IDLE) — all three are about sync
behavior adapting to device resource constraints; may be worth a shared battery/network-state utility
rather than three ad hoc checks.