Suggested changes

Note: these changes might seem view specific but they really apply to both the View framework and Compose on Android, since Compose still runs in an Android root view / window.

1. New registerWindowViewAttachCallback API

Add a new registerWindowViewAttachCallback API or similar to either WindowInspector (which already has WindowInspector.getGlobalWindowViews()) or Application (which has registerActivityLifecycleCallbacks()), e.g. :

WindowInspector.registerWindowViewAttachCallback { rootView ->
  // new window root view attach, do something with rootView
}

The callback would be called synchronously on every call to WindowManager.addView()

Alternatively, although maybe less generic and ideal, a Application.registerDialogLifecycleCallback API could help achieve similar goals (see below on "why").

2. Ability to pull the Window from a root view

When a window is a PhoneWindow then its root view is a DecorView (private class) which holds on to the associated Window. There should be a way to pull the associated Window object (if the view is associated to a phone window object), in order to be able to leverage the Window APIs (most importantly being able to swap out the window callback).

Why

1. New registerWindowViewAttachCallback API

In API 29 the Android Framework added WindowInspector.getGlobalWindowViews() which provides a list of root views, one view per window attached in the current process. This was added (in https://cs.android.com/android/_/android/platform/frameworks/base/+/1761cfac39d5ee17f2e4f8eef485c38a08624533) to help with Android Studio UI inspection and for the Espresso testing library to be able to traverse the view hierarchy for all attached windows at a given point in time.

However, today, there is still no public API for knowing when new window views are added.

This is critical for observability libraries: a root view provides access to the ViewTreeObserver and potentially the associated window, if any (if moving forward with suggested change 2).

Today, developers can already listen to new activity windows and the associated root views by registering a ActivityLifecycleCallbacks on the Application and pulling the window & root view in onCreate().

However, there's absolutely no support for any non activity window, such as Dialog based windows, or direct calls to WindowManager.addView(). Dialog based windows are critical for any sheet implementation, and generally large screens where it's more common to see layered UI with distinct windows.

The recommended approach today would be to write additional code next to every Dialog.show() call or WindowManager.addView() call, which is not reasonable in large codebases where developers might import 3rd party libraries that they don't control that bring their own UI.

One note: for symmetry purposes it'd probably be nice to be told when root views are added AND when they're removed. However, the latter kinda already exists, since you can set an attach state change listener on the root view.

2. Ability to pull the Window from a root view

This one will probably be more controversial: Android offers a public Window class which IIRC is only used for windows created by dialogs and activities. The Window API is useful, especially the ability to set a Window callback (for instance to listen to all touch & key events). Unfortunately, you can only get the Window from a Dialog or Activity instance, and while there is registerActivityLifecycleCallbacks(), there is no dialog equivalent. So the proposal here is either to be able to pull the Window from a view hierarchy (if there's one), i.e. similar to ViewTreeObserver but optional (yeaaah maybe not ideal). Or provide some other way to get the window objects when there is such a window object.

Seriously but why?!

All these asks might sound a little crazy. Here's the thing though, we absolutely need ways to know about new windows if we're to take observability seriously.

I already implemented these APIs using reflection (please don't yell) and they've been critical both for detecting root view leaks in LeakCanary, as well as reporting observability metrics in large codebases.

Here's how I do it today:

• I can get the actually array list of root views by pulling them using reflection: https://github.com/square/curtains/blob/main/curtains/src/main/java/curtains/internal/WindowManagerSpy.kt
• I can then swap out the array list with another array list that's a subclass that will listen to add() and removeAt() calls (ok you can yell a little): https://github.com/square/curtains/blob/main/curtains/src/main/java/curtains/internal/RootViewsSpy.kt
• I can pull out the Window (if any) from a root view that's a decor view using reflection: https://github.com/square/curtains/blob/main/curtains/src/main/java/curtains/internal/WindowSpy.kt

Now, all these crazy hacks allow me to build the nice APIs that we need, which are defined here: https://github.com/square/curtains

Let me show you some real usages that we can't do today using the public APIs:

• LeakCanary: Detect when new root views get eventually detached, to make sure they don't leak: https://github.com/square/leakcanary/blob/e798d5c099c53b6d44356f461133cc80d1367017/object-watcher/object-watcher-android-core/src/main/java/leakcanary/RootViewWatcher.kt#L64
• LeakCanary: use reflection to clear out InputMethodManager view leaks on window detach (granted, the Framework eventually fixed those, yay!)
• Track touch event and their timestamps for all windows to evaluate the true end to end latency of interactions https://github.com/square/papa/blob/26f21379a8efb14b292c1db5188d4a3be6a48872/papa/src/main/java/papa/internal/RealInputTracker.kt#L77
• JankStats offers Window based APIs: JankStats.createAndTrack(window, jankFrameListener) but without a way to get all windows this only captures a subset of the windows which jank can happen.