IssueTracker

First of all thanks for this detailed issue.

This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.

The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.

Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.

Just to be sure, it is dangerous to replace Compose TextField with Android View EditText as a workaround for this issue.

Compose 1.7 has a bug that causes ANR when the focus is on EditText. https://issuetracker.google.com/issues/369354336

Another View-related bug in Compose 1.7 is that an Android View is focused by calling FocusManager.clearFocus(). https://issuetracker.google.com/issues/374031296

Perhaps there is a lack of testing of Compose 1.7 in combination with Android View. There is also a possibility that there are other fatal bugs related to View.

In other words, the only options for apps targeting the Japanese market that require POBox support are to continue using Compose 1.6 or to use EditText in combination with various workarounds.

Project: platform/frameworks/support
Branch: androidx-main
Author: Halil Ozercan <halilibo@google.com>
Link:      https://android-review.googlesource.com/3317256

Fix POBox keyboard issue

Fix POBox keyboard issue 
 
Fix: 373743376 
Fix: 329209241 
Test: NullableInputConnectionWrapperTest 
Change-Id: I94e0e598274fb88b255f977f9fbd50dfbbb1ecb1

Many thanks again for this report. Especially for giving us a huge clue in terms of what could be going wrong. The fix is now merged and I will ask for a cherry-pick into a stable release.

Yes, this fix is planned to be included in a future 1.7.x release.

Thanks for the fix. Sorry to follow up on this. is it possible for you to share specific release version/date for the stable version? We are waiting on this to decide on our direction.

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