fix: refresh widgets after idle#978
Conversation
efea229 to
295079f
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 295079f67e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Testing notes: Prerequisite: add all OS widgets and lock the phone for a few (15+) minutes. a) Bitkit running in bg
b) Bitkit not running in background (foreground service stopped from the persistent Bitkit notification)
Also noticed this after force shutdown the app - OS widgets loose the content, until tapped on. (however force shutdown warns that this action may cause app misbehavior). Screen_Recording_20260601_162003_One.UI.Home.mp4 |
Resolved in de12165 |
|
Starting review |

Fixes #975
Motivation
Description
AppWidgetRefreshReceiverthat enqueues a one-shot widget catch-up whenIntent.ACTION_USER_PRESENTorPowerManager.ACTION_DEVICE_IDLE_MODE_CHANGEDidle exit occurs while the app process is alive.AppWidgetRefreshAlarmReceiverscheduled withAlarmManager.setAndAllowWhileIdleso overdue widget catch-up can start the app process after long idle even if Bitkit was reclaimed.LightningNodeServicestops so existing OS widgets are covered after app updates and after stopping Bitkit from the persistent notification.enqueueCatchUpone-time WorkManager path toAppWidgetRefreshWorkerandhasActiveWidgets/cancel logic so catch-up runs only when OS widgets are installed and catch-up work is cancelled when no widgets remain.Context.alarmManager,Context.powerManager, and changelog fragmentchangelog.d/next/978.fixed.md.Preview
N/A
QA Notes
Manual Tests
regression:ADB → force the device into idle/Doze with the commands below → exit idle and unlock: logcat showsEnqueued widget refresh for 'device_idle_exit'orEnqueued widget refresh for 'user_present', thenRefreshing data for widget types: ...; the home-screen widget updates without waiting for the 15-minute periodic WorkManager window.regression:Bitkit running with background payments enabled → stop Bitkit from the persistent notification → lock for 15+ minutes → unlock and check OS widgets: widgets refresh without opening Bitkit.Enqueued widget refresh for 'debug_catch_up', thenRefreshing data for widget types: ....The original stale-widget condition is: an actual Android home-screen widget exists, the app has previously started, Android enters idle/Doze and defers the 15-minute periodic WorkManager refresh, then the user unlocks/exits idle before the periodic job is allowed to run. On
master, the same forced-idle/unidle flow has no widget catch-up receiver path, so the widget can stay on cached data until the next periodic refresh is eventually allowed. This PR should enqueue immediate one-time catch-up work on idle exit, unlock, app foreground, app startup, and Bitkit service stop, and it schedules an explicit alarm catch-up path for the case where the app process was reclaimed during a long idle period.Force the idle condition without waiting 15+ minutes:
Optional temporary patch for a no-lock, no-wait adb trigger. Apply in one command, rebuild with
./gradlew installDevDebug, open Bitkit once, then runadb shell am broadcast -a to.bitkit.dev.DEBUG_WIDGET_CATCH_UP -p to.bitkit.dev.Clean up the temporary patch after testing:
Automated Checks
git diff --checkwas run and produced no whitespace errors.git apply --check../gradlew compileDevDebugKotlinpassed locally../gradlew testDevDebugUnitTestpassed locally../gradlew detektpassed locally.Codex Task