Android Dynamic Widgets re-render inconsistently on light/dark scheme change

[V3RON]

Summary

Android Dynamic Widgets do not reliably re-render when the system light/dark scheme changes. The reload is triggered every time, but the widget only re-fetches its bundle and re-renders on some toggles. Reproduced on origin/main (24accaf), so this predates #261 and #262.

Environment

• Pixel_8_API_35 emulator, example app, AndroidClientDemoWidget pinned, Metro serving the widget bundle (verified with a 200 on the bundle URL).
• Toggled with adb shell cmd uimode night yes|no, 15 s between toggles, home screen screenshot after each.

Observation

Toggle	App state	Expected scheme	Observed scheme	Re-render (metro fetch in logcat)
no → yes	background	dark	light	no
yes → no	background	light	light	yes
no → yes	background	dark	light	no
yes → no	background	light	light	no
no → yes	foreground	dark	dark	yes
yes → no	foreground	light	dark	no

On every toggle logcat shows VoltraWidgetManager: reloadClientWidgets followed by VoltraWidgetReceiver: Triggered update on registered widget 'AndroidClientDemoWidget' (1 instances), so the configuration callback and the Glance update() call both run. Only two of the six toggles produced a VoltraClientGlanceWidget: [perf] metro fetch line and a changed scheme: / time: row on the widget. Payload-driven widgets were unaffected throughout.

Likely cause

VoltraClientGlanceWidget.provideGlance does the bundle fetch and evaluation, and Content builds the env (including colorScheme) from context.resources.configuration. When Glance already has a live session for the widget, update() recomposes provideContent without re-running provideGlance, and the session's context can still carry the previous configuration, so the env is rebuilt with the stale scheme. Whether a session is alive at the moment of the toggle depends on timing, which matches the intermittent pattern above.

Suggested direction

Force a fresh composition on scheme change rather than relying on update() alone, for example by keying the composition on the night-mode bit (Glance state or a props revision, the way runtime props updates already do via advanceDynamicWidgetPropsRevision), or by reading the scheme from a freshly obtained application configuration instead of the session context.

Found while smoke testing #261 and #262; not introduced by them.

[V3RON]

Confirmed from the code. The scheme reload path (VoltraModule → WidgetOrchestrator.reloadClientWidgets → VoltraWidgetReceiver.triggerGlanceUpdate) only calls widget.update(). The props path goes through DynamicWidgetGlanceUpdateCoordinator, which first bumps dynamicWidgetPropsRevisionKey in Glance state and then calls update().

That difference matters because of how Glance handles update() on a live session: it doesn't restart provideGlance, it re-reads the widget's preferences and re-provides LocalState. LocalState is a compositionLocalOf with structural equality, so if the preferences haven't changed, nothing in Content() is invalidated and the widget keeps the env it rendered last time. When no session is alive, provideGlance runs fresh and the scheme is correct, which is why it works on some toggles and not others.

Fix: make the scheme reload bump an observed state key before update(), either by routing clientWidgetGlanceUpdateTrigger through triggerDynamicWidgetGlanceUpdate, or by adding a separate env-revision key that Content() reads. Worth an orchestrator test that asserts the bump happens before update().

---

Generated by Claude Code