Summary
Untested hypothesis, filed so it does not evaporate — split out of #1318 review, deliberately uncoupled from that fix.
--settle may not observe a fully expanded quick-settings shade at all: the same run-condemnation rule that #1318 works around in the divergence layer strips every node of an expanded shade from both diff sides, so opening or closing the shade could look like "nothing changed" to the settle loop.
Mechanism (verified as a mechanism, not as a settle symptom)
collectAndroidSystemChromeRunIndexes (src/core/snapshot-chrome.ts) condemns an entire contiguous same-package run when any node in it carries a status/nav marker. Live on emulator-5556 (Pixel 9 Pro XL API 37), a full-cover expanded shade is a single systemui run:
- run root
com.android.systemui:id/legacy_window_root, 95 nodes, one run
- exactly 4 marker-bearing nodes (
clock, mobile_combo, mobile_signal, wifi_signal) — the status-bar icons the expanded shade hosts inside its own window
- result:
collectSettleChromeRefs(nodes, <app>) returns all 95 refs as chrome
The run rule assumes the status bar is its own window — true collapsed, false expanded. That part is established (it is the same finding #1318 is built on). What is not established is whether this actually degrades settle in practice.
Why it might be fine (do not "fix" this reflexively)
The 4 markers are literally clock/signal/wifi — the canonical churn --settle exists to ignore. Stripping the shade run may well be desirable: a naive "spare runs that hold actionable content" change would let a ticking clock hold settle awake, which is exactly the regression the run rule was written to prevent. #1318 deliberately did not touch the shared classifier for this reason — settle and divergence genuinely disagree about these 95 nodes and both are correct.
So this issue is a question, not a defect report: is settle-blindness to an expanded shade a real problem worth solving, and if so, at which layer?
What would settle it
Raise a persistent shade mid---settle (adb shell cmd statusbar expand-settings) and check whether the settle loop observes the change or reports quiet. If it reports quiet, decide whether that is acceptable (chrome churn ignored, as designed) or whether a covering surface should break quiet.
Context
Summary
Untested hypothesis, filed so it does not evaporate — split out of #1318 review, deliberately uncoupled from that fix.
--settlemay not observe a fully expanded quick-settings shade at all: the same run-condemnation rule that #1318 works around in the divergence layer strips every node of an expanded shade from both diff sides, so opening or closing the shade could look like "nothing changed" to the settle loop.Mechanism (verified as a mechanism, not as a settle symptom)
collectAndroidSystemChromeRunIndexes(src/core/snapshot-chrome.ts) condemns an entire contiguous same-package run when any node in it carries a status/nav marker. Live on emulator-5556 (Pixel 9 Pro XL API 37), a full-cover expanded shade is a single systemui run:com.android.systemui:id/legacy_window_root, 95 nodes, one runclock,mobile_combo,mobile_signal,wifi_signal) — the status-bar icons the expanded shade hosts inside its own windowcollectSettleChromeRefs(nodes, <app>)returns all 95 refs as chromeThe run rule assumes the status bar is its own window — true collapsed, false expanded. That part is established (it is the same finding #1318 is built on). What is not established is whether this actually degrades settle in practice.
Why it might be fine (do not "fix" this reflexively)
The 4 markers are literally clock/signal/wifi — the canonical churn
--settleexists to ignore. Stripping the shade run may well be desirable: a naive "spare runs that hold actionable content" change would let a ticking clock hold settle awake, which is exactly the regression the run rule was written to prevent. #1318 deliberately did not touch the shared classifier for this reason — settle and divergence genuinely disagree about these 95 nodes and both are correct.So this issue is a question, not a defect report: is settle-blindness to an expanded shade a real problem worth solving, and if so, at which layer?
What would settle it
Raise a persistent shade mid-
--settle(adb shell cmd statusbar expand-settings) and check whether the settle loop observes the change or reports quiet. If it reports quiet, decide whether that is acceptable (chrome churn ignored, as designed) or whether a covering surface should break quiet.Context
--settleunchanged by construction.systemSurfaceOnlycapture carve-out).