Hold a decor view through its window, and the window through its screen

[pyricau]

Stacked on #2941. The question this answers: is there always a window when there's a decor view, and if so, should the rule be PhoneWindow.mDecor rather than Activity.mDecor?

Is there always a window?

Yes, for a decor view: every one in the seven real dumps in the repo is pointed at by exactly one PhoneWindow.mDecor (1 of 1 in compose_leak.hprof, 3 of 3 in leak_asynctask_m.hprof, and so on).

Not for a root view, which is the distinction that matters: 14 of the 15 root views in compose_leak.hprof, 9 of the 10 in leak_asynctask_m.hprof and 22 of the 23 in gcroot_unknown_object.hprof have no window anywhere. They're Toast views, PopupWindow.mContentView, TextView$MagnifierViews, Toolbar.mNavButtonView image buttons and fragment roots, each held the ordinary way by whatever made it. So the rule is window → decor view, and the rest need nothing.

Why Activity.mDecor had to go

ActivityThread.handleResumeActivity is the only place that writes it, guarded by if (r.window == null && !a.mFinished && willBeVisible) — so it is set once per ActivityClientRecord, not once per Activity. A screen recreated on a configuration change is resumed, visible, and has a null mDecor for the rest of its life. It also inverted the nesting where it was set: in leak_asynctask_m.hprof a PhoneWindow was drawn under its own DecorView, through DecorView.this$0.

Why the window then needs a rule of its own

A window has 6 to 9 referrers in these dumps. Most are its own inner classes and its decor's, but the external ones — WindowManagerImpl.mParentWindow, ActivityThread$ActivityClientRecord.window, DecorView.mWindow reached from a ViewRootImpl — put 6 of the 16 windows at the top of the tree. Moving the decor view under the window makes that worse than it was, because the hierarchy now floats with it: gcroot_unknown_object.hprof's PhoneWindow went from 14 KB at the root to 3.09 MB there, large-dump.hprof's from 12 KB to 2.14 MB. With Activity.mWindow / Dialog.mWindow owning it, every decor view in every dump is under its window and every window of a screen that is up is under that screen.

The one state check

ActivityWindowRule reads Activity.mDestroyed and Dialog.mDecor, which no other rule here needs. It has to: Activity.mWindow is set in attach and never cleared, and Dialog.mWindow is final, so a destroyed activity and a dismissed dialog go on pointing at a window they have nothing to do with. Owning it regardless took the window of a leaked screen away from whatever else was holding it and turned two leaks into one on the list — the reference that would still have been there after the activity was fixed stopped being reported. HeapLeaksTest covers that, and notes/dominator-tree.md now records it as the test to apply to a new rule.

Conserved

Bytes conserved on all eight dumps, no object joins or leaves the tree, 0 to 16 objects of 34 K to 340 K move. shark-explorer-core:check and shark-explorer-app:check pass.

🤖 Generated with Claude Code

[pyricau]

🤖 Folded into #2941 — the two commits are one change, so they're one PR now. The state read this branch had is gone: ActivityWindowRule asks ActivityThread.mActivities whether the framework is still running the screen instead of reading Activity.mDestroyed.