AutographComposeHosts

The set of views whose content belongs to a Compose capture pipeline, so the native pipeline can stay off it.

Both pipelines hit-test the same accessibility tree — that is the whole point of walking it — so a tap inside a ComposeUIViewController is visible to both. Without a boundary the two would each report it and every Compose tap would be counted twice. autograph-compose registers its host view; containsAny lets the native side drop any tap whose hit path crosses one.

This is a static condition, not a race. The alternative — "did the Compose pipeline already report this tap?" — would make the outcome depend on which recognizer fired first. Asking instead "does this tap land under Compose-owned content?" has one answer regardless of ordering, and it holds even when the Compose side declines to report the tap at all.

That last part is the privacy-relevant one. The invariant is content under a Compose host belongs to the Compose pipeline exclusively — not content the Compose pipeline reported. A hybrid app can run Compose with autocapture off and the native pipeline on; if registration were conditional on the Compose autocapture flag, the native walk would descend into Compose's bridged tree and capture elements the developer excluded with Modifier.autographIgnore(). Registration must therefore happen whenever a Compose host exists, independent of that flag.

Process-global by design. "This view hosts Compose" is a fact about the view, not about a tracker, and the two sides have no other place to meet: the Compose host registers from inside a composition and the native pipeline consults it from a gesture recognizer, with no shared owner to thread an instance through.

The ref-counted, weak, pointer-personality bookkeeping lives in WeakViewRegistry; this holds its own instance, separate from AutographIgnoredViews's, deliberately (see there). Main thread only.