Fix some IME transition issues
- Add InsetsSource#getVisibleFrame to check if the launching task needs to disable fixed rotation: As CL[1] disables fixed rotation when IME surface exists for fixing IME janky when IME receiving different orientations. Even the CL used StartingData#hasImeSurface to forecast if needs to disable fixed rotation, it may hit some timing cases that StartingData not yet be prepared when launching the task next time quickly. Add InsetsSource#getVisibleFrame to prevent this edge case happen since this value will be updated when app client requests relayout. - Consolide DC#isImeAttachedToApp() check: When recents animation started, will check whether the task has to hide soft-keyboard when it's not able to attach IME surface through DC#isImeAttachedToApp. Since this method only checks the layering target window states but not check if the IME surface has actually attached to the app. it might have potential issue that IME may state persistents when switching between tasks if we don't check if the actual IME container surface. Consolide DC#isImeSurfaceAttachedOnApp check to ensure hiding keyboard in RecentsAnimationController as the above potential case. (Also renamed the original DC#isImeAttachedToApp as DC#shouldImeAttachedToApp to make it easier understand the difference within the new isImeAttachedToApp.) [1]: Idfdf129adbfbee6634d8a27aa78da1f631bd213b Fix: 160451808 Bug: 184020899 Test: manual as below steps 1) launching the app with focusing IME in portrait mode. 2) swiping out to launcher 3) rotate the device in landscape 4) tapping the shortcut to launch the app again 5) repeat 1-4, see if IME surface will mess up to see both portrait and landcape surface. Change-Id: I966ab69f260f828b6e96b3479a36467181288504
Loading
Please register or sign in to comment