fix: refresh widgets after idle

[ovitrif]

Fixes #975

Description

This PR:

1. Refactors Android widget refresh scheduling into one AppWidgetRefreshScheduler entry point.
2. Keeps periodic WorkManager refresh as the primary 15-minute best-effort engine, with a sparse inexact idle alarm for app-not-running catch-up and a 30-minute native widget fallback.
3. Restores scheduling from app startup, foreground, widget enable/update/configuration, boot, package replacement, and the foreground-service stop action.
4. Updates the worker to refresh only active widget types, track per-type attempt/success freshness, skip fresh remote-backed types, and retry stale/failed types independently.
5. Treats Facts as local cached rotation, so a Facts update is not counted as proof that remote-backed widgets refreshed.
6. Removes runtime-only user-present/idle-mode receiver registration and avoids tying widget refresh to LightningNodeService.onDestroy.

Preview

Before Idle	After Idle

QA Notes

Manual Tests

• 1. Android launcher → install the PR dev build → add Price, Headlines, Blocks, Facts, and Weather OS widgets → open Bitkit once → stop Bitkit from the persistent notification → keep Wi-Fi/data on → unplug USB/power → lock the phone and leave it untouched for 30+ minutes → unlock without opening Bitkit: remote-backed widgets update without launching the app.
  Result: Real idle wait from 19:15 to 20:43 on June 2, 2026: Price changed from $67.443 to $67.314, Blocks changed from 952,132 to 952,138, News changed headline, and Facts rotated locally. Weather stayed at $0.28, which is valid when the fee estimate itself has not changed.
• 3. Logs: device logs after the real wait show Bitkit widget update notifications after unlock, successful widget update records, and a later catch-up alarm/worker pass that saw all active widget types and skipped remote-backed types as fresh.
• 4. negative: Android quick settings → disable Wi-Fi/data → repeat the idle test: remote-backed widgets may stay stale while offline; Facts may still rotate from local cached facts only.
• 5. negative: Android Settings → Apps → Bitkit → Force stop → return to launcher: Android 15 may disable widget updates/pending intents until the user launches or interacts with Bitkit again; this is expected platform behavior.

Automated Checks

• Unit tests added: cover widget freshness policy, scheduler cancel/schedule behavior, boot/package/alarm receiver delegation, and worker attempt/success handling in app/src/test/java/to/bitkit/appwidget/.
• Unit test modified: covers the foreground-service stop action scheduling widget catch-up before shutdown in app/src/test/java/to/bitkit/androidServices/LightningNodeServiceTest.kt.
• git diff --check passed locally.
• ./gradlew compileDevDebugKotlin passed locally.
• ./gradlew testDevDebugUnitTest passed locally.
• ./gradlew detekt passed locally.

[piotr-iohk]

Testing again after recent updates...

[ovitrif]

Testing again after recent updates...

@piotr-iohk Pls use latest commit, after squashing all prevs:
ee47435

note that your comment was right before the squashing push and I will add new dev mode setting to clear logs; so I can test this and other OS widgets PRs easier without having to clear logs.

[ovitrif]

PS. Can still have an issue for this 🙏🏻 , I am not discouraging that.

Yeah, that's for the sake of documenting it somewhere - so it is not only in our collective knowledge 👍

Issue filed:

• Document battery-saving limitation for remote OS widget refresh #992

[jvsena42]

Tested on physical Mi Note 11

1. Fresh app
2. Set Block widgets OS and in-app
3. Finish app by notificatoin
4. disable wifi and block app
5. On middle for 12 minutes
6. unlock phone
7. turn on wifi
8. Both widgets updated

Screen_recording_20260605_105739.mp4

[piotr-iohk]

Tested again latest head (before squash) on Samsung S22 / Android 16, power savings off, 30+ min idle after stop-from-notification. Price/Blocks/weather updated without opening app. Headlines may remain unchanged within 30 min by design (60 min interval).