Context
Follow-up from PR #978 testing:
- Piotr's successful log with power saving off showed
SERVICE_STOP_ACTION scheduling catch-up, a background feeds.synonym.to request returning 200 OK while Bitkit was stopped, and the later CATCH_UP_ALARM skipping remote widgets because they were already fresh. No UnknownHostException appeared in AppWidgetRefreshWorker.
- Earlier failing exports with power saving on showed the catch-up alarm firing and the worker attempting remote widget refreshes, but DNS failed with
UnknownHostException for feeds.synonym.to / mempool.space until Bitkit was foregrounded.
- Facts can still rotate because it is local; remote widgets need usable background network/DNS.
References:
Current interpretation
On some devices / OS versions, power saving or battery optimization can block background DNS/network access while Bitkit is stopped. The widget catch-up implementation can run correctly but still fail to refresh remote-backed widgets until the app is foregrounded or battery saving is disabled.
Product note
We should avoid rushing into an in-app prompt asking users to disable battery optimization for Bitkit. That flow is intrusive and likely not appropriate until we have a better battery profile for LDK-node foreground-service event handling. For now, treat this as a known limitation / support note unless we intentionally decide on a product-level workaround.
Follow-up ideas
- Keep widget/background-work logs explicit about current battery-saving settings so support can identify this quickly.
- Document support guidance: if Facts update but remote widgets stay stale and logs show background DNS failures, check device power saving / unrestricted battery settings.
- Consider a docs/FAQ or troubleshooting entry before any in-app battery optimization request.
- Revisit whether Bitkit should request battery optimization exemptions only after the foreground-service battery behavior is improved.
- Display a "Latest Update" date and a refresh button for widgets with stale remote data.
Context
Follow-up from PR #978 testing:
SERVICE_STOP_ACTIONscheduling catch-up, a backgroundfeeds.synonym.torequest returning200 OKwhile Bitkit was stopped, and the laterCATCH_UP_ALARMskipping remote widgets because they were already fresh. NoUnknownHostExceptionappeared inAppWidgetRefreshWorker.UnknownHostExceptionforfeeds.synonym.to/mempool.spaceuntil Bitkit was foregrounded.References:
Current interpretation
On some devices / OS versions, power saving or battery optimization can block background DNS/network access while Bitkit is stopped. The widget catch-up implementation can run correctly but still fail to refresh remote-backed widgets until the app is foregrounded or battery saving is disabled.
Product note
We should avoid rushing into an in-app prompt asking users to disable battery optimization for Bitkit. That flow is intrusive and likely not appropriate until we have a better battery profile for LDK-node foreground-service event handling. For now, treat this as a known limitation / support note unless we intentionally decide on a product-level workaround.
Follow-up ideas