IssueTracker

Do you mind providing code samples and then I can look into it further.

Sure, something like this: (make sure to run it on a device below R)

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContentView(Button(this).apply {
            setText("Hello world")
            setOnClickListener {
                addOverlayView()
            }
        })
    }

    fun addOverlayView() {
        val view = MyCustomView(applicationContext).apply {
            updateWindowSizeClass()
        }
        val params = WindowManager.LayoutParams(
            WindowManager.LayoutParams.WRAP_CONTENT,
            WindowManager.LayoutParams.WRAP_CONTENT,
            WindowManager.LayoutParams.TYPE_APPLICATION_SUB_PANEL,
            WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE,
            PixelFormat.TRANSLUCENT
        ).apply { token =
            window.decorView.getRootView().windowToken
        }
        val windowManager = getSystemService(WINDOW_SERVICE) as WindowManager
        windowManager.addView(view, params)
    }
}

class MyCustomView(context: Context) : TextView(context) {
    fun updateWindowSizeClass() {
        val metrics = WindowMetricsCalculator.getOrCreate().computeCurrentWindowMetrics(context)
        setText("Width = ${metrics.bounds.width()} height = ${metrics.bounds.height()}")
    }
}

This works above R, but below R it crashes with:

java.lang.IllegalArgumentException: Context android.app.Application@20b1a86 is not a UiContext

An application Context is not a UI Context so it isn't guaranteed to work. We could add stricter enforcement but that would make it so that the method throws when using an application context.

An application Context is not a UI Context because it is not associated with a Display. Therefore creating UI with it is not recommended.

Sorry if I wasn't clear, but we don't control the callers here, it is common (and supported) for developers to create views with an application context. The question is what should the window size we provide in Compose be in this case. And whatever logic we decide to do there (e.g root view size, default display size) probably makes more sense to implement inside window metrics calculator instead of crashing, so we can be consistent in the fallback behavior across applications and libraries.

Otherwise we would have to basically rely on the implementation detail that the WM library tries to unwrap the context, so we would do it first to see if we can do it safely, and only if so call the WM API

Curious if you have any thoughts as to this, as there is still a 'window' somewhere in the app that is meaningful for UI decisions based on window size

There are no correct window metrics that you can get from the Application Context. There is some parts leftover for compatibility reasons but for new code paths one should not use the Application Context to create Views. For example, there is no default display size because Context#getDisplay will crash. You will not get a correct result going forward when using Context.getSystemService(WindowManager::class.java).getDefaultDisplay().

as there is still a 'window' somewhere in the app that is meaningful for UI decisions based on window size

Where is the window?

Also, in your example above why not use the Activity as the Context?

There are no correct window metrics that you can get from the Application Context

Above R it seems to work fine, since it uses WindowManager#getCurrentWindowMetrics, but I guess there is nothing else we can use below R

You will not get a correct result going forward when using Context.getSystemService(WindowManager::class.java).getDefaultDisplay().

Right, but it's a better approximation than crashing, we need to provide our consumers with some value here. We would only need to do this below R, if the context is not a UI context anyway.

Where is the window?

The same entity that WindowManager#getCurrentWindowMetrics returns above R for an applicationContext, not sure how this is calculated but it seems to map to the current activity inside the application.

Also, in your example above why not use the Activity as the Context?

My example is a bit contrived, in reality this is a common pattern internally. We tried to land a change that calculates default window metrics from the context, and this crashed in multiple tests because the applicationContext was being used, and it's not feasible to update all these existing applicationContext usages that work fine outside of calculating window size.

In any case if there is no desire to avoid this crash at the window library layer, we'll have to land some workaround instead for Compose

Above R it seems to work fine, since it uses WindowManager#getCurrentWindowMetrics, but I guess there is nothing else we can use below R

Not crashing isn't the same as working fine. WindowManager#getCurrentWindowMetrics would be incorrect in a multi display environment.

Right, but it's a better approximation than crashing, we need to provide our consumers with some value here. We would only need to do this below R, if the context is not a UI context anyway.

I don't agree since he default display is the phone's display which can be different from a 42" 4k monitor. And like I said, a non UI context should not be used.

The same entity that WindowManager#getCurrentWindowMetrics returns above R for an applicationContext, not sure how this is calculated but it seems to map to the current activity inside the application.

The problem is when you are in a multi display environment and that is when it would break.

My example is a bit contrived, in reality this is a common pattern internally. We tried to land a change that calculates default window metrics from the context, and this crashed in multiple tests because the applicationContext was being used, and it's not feasible to update all these existing applicationContext usages that work fine outside of calculating window size.

Why are you all using the Application Context instead of a proper UI Context?

Not crashing isn't the same as working fine. WindowManager#getCurrentWindowMetrics would be incorrect in a multi display environment.

Isn't this what is normally used by WindowMetricsCalculator above R?

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:window/window/src/main/java/androidx/window/layout/util/WindowMetricsCompatHelper.kt;l=88

On a UI Context it is correct, on a non-UI Context it is incorrect.

Discussed more offline, filed b/360934048 as a feature request for WM library to support applicationContext

Note we'll also need to address the performance regression with the original change: b/360151053

Filed a bug for the performance issue, which was rootcaused to insets calculation in WindowMetricsCalculator - since we don't need insets in what we are trying to provide, for now we can just fork the bounds logic, and unify with window library when these blocking issues are resolved

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3278834

Re-land adding WindowInfo#containerSize

Re-land adding WindowInfo#containerSize

Temporarily using a forked subset of WindowMetricsCalculator to avoid performance issues with inset calculations (that we don't need).

Bug: b/369334429
Fixes: b/360343819
Test: ComposeViewTest
Test: WindowInfoCompositionLocalTest
Relnote: "Adds WindowInfo#containerSize to provide the current window's content container size. This can be retrieved using LocalWindowInfo."
Change-Id: I277673b5576f15f60bc82eeb9d9424c5144a3c25

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3290009

Re-re-land adding WindowInfo#containerSize

Re-re-land adding WindowInfo#containerSize

Temporarily using a forked subset of WindowMetricsCalculator to avoid some extra performance issues with inset calculations (that we don't need).

Bug: b/369334429
Fixes: b/360343819
Test: ComposeViewTest
Test: WindowInfoCompositionLocalTest
Relnote: "Adds WindowInfo#containerSize to provide the current window's content container size. This can be retrieved using LocalWindowInfo."
Change-Id: Idc38c705655c9181022161927275318fba86bed8

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.ui:ui:1.8.0-alpha04
• androidx.compose.ui:ui-android:1.8.0-alpha04
• androidx.compose.ui:ui-jvmstubs:1.8.0-alpha04
• androidx.compose.ui:ui-linuxx64stubs:1.8.0-alpha04