This is a follow up CL for I219394178e4172bc47864297f1418e677dba.
As explained in the commit message of I219394178e4172bc47864297f,
IMM#mCurRootView needs to be synchronized with the actual window
focus more precisely to fix Bug 20820914. Hence we should not
clear IMM#mCurRootView in IMM#finishInputLocked() anymore.
Ideally this CL should have been included in the previous CL.
Manually tested following scenarios.
- Repro steps in Bug 6413553. Made sure that IMM#mCurRootView
is cleared after switching back from the current application to
the previous application with back key.
- Test application that calls WebView#showFindDialog(). Made sure
that LatinIME works fine when switching text fields. This is
non-trivial because android.webkit.FindActionModeCallback is
changed in the previous CL I219394178e4172bc47864297f1418e677db.
- Repro steps in Bug 21144633. Made sure that we can enter
recipient's name in the messaging app.
This CL depends on I219394178e4172bc47864297f1418e677dba25e5.
Bug: 20820914
Change-Id: Id6afc8fc64512225578c62557b96c7dc2e969adf
The fake window that was added when View.SYSTEM_UI_FULL_SCREEN was
set consumed all touches, even those going to the SystemUI and not
just those of windows below. The input consumer is now correctly
positioned in the window order to only capture the right touches.
Clicks to the volume panel and the heads up now correctly go to the
right place instead of just unhiding the SystemUI bars.
Bug: 21089476
Change-Id: Ib53dfc0b33b70084ca607d0f044db30b6e6c91d6
Information about the chin is now part of the config.xml instead of the
theme. It is retrieved by WindowManagerService and passed to the clients
as insets. Clients can adjust their behavior in a way that makes it
invisible to the user, that part of the surface doesn't actually exist.
Bug: 19908853
Change-Id: Iedf57bf3c848201b854f91ffeb3b59187d375c1f
Bug: 20170924
Don't pre-allocate buffers if there is a SurfaceView or other
View that has requested transparent regions. This doesn't fully
address the problem of allocating buffers when there's a full
screen SurfaceView but it at least gets back to KitKat levels
of only having 1 wasted buffer instead of 3 (the 1 being
a result of the fact that it will still draw one frame of emptiness
forcing a buffer dequeue).
Change-Id: Ied9553186bc7b111d180b63f87b92bd317cb4b97
...from text nodes in WebView
Add a new explicit API for setting the text style information associated
with a view structure.
Also, how about some documentation!
Change-Id: Ia948b2d66382b973d0d00a67172a281ad55ce592
- Adds an ActionMode.snooze(int) API.
- Clients call this to hide the floating toolbar on DOWN touch event.
- This is called repeatedly as a snooze timeout will re-show the
toolbar.
- ActionMode.snooze(0) will "wake" the toolbar, reshowing it.
- Clients call this to re-show the toolbar on UP touch event.
- This CL also adds code to hide the toolbar when the "content rect"
is changing.
Bug: 20148125
Change-Id: If5a9a15f72c73cad8ca01a4328a58570b3e29f66
Move existing code that previously relied on config_windowIsRound to
use the new Configuration.isScreenRound() method. Also move the system
property override for emulators over to the initial setup of a Display
so that the configuration property is consistent with existing
expectations.
Remove config_windowIsRound from symbols.xml. The symbol now only
exists as a default value redirect for overlays already configured to
supply this value.
Change-Id: I24e6564030a6051c3ac7262868983b43e13eee65
Add round values to the screenLayout field for Configuration
and a convenience method to check roundness.
Plumb this through the DisplayManager, making roundness the property
of a DisplayAdapter. The built-in main display will read the
configuration resource config_mainBuiltInDisplayIsRound to determine
its roundness. Device-specific resource overlays should set this to
true for devices with round primary displays.
By default, this config resource inherits from the existing
config_windowIsRound value currently used by some Android Wear
device configurations.
This change awaits another for aapt/native resources code to make the
resource filtering system aware of this property.
Change-Id: I1daced7ca6d6e172789e7c32bebfd43753bfa2ae
Currently IMM#mCurRootView is always cleared every time when
IMM#finishInputLocked() is called. We have been doing this since
Iad09cf5dbb7f6f156fd39ed243431432e00f8945 so as not to hold the
strong reference to a DecorView so long time (Bug 6413553).
Strictly speaking, the attached window may continue holding
input focus even after IMM#finishInputLocked() is called.
In this state IMM#focusIn() might have unexpectedly rejected
focus-in event but presumably this might not be obvious, or might
not occur at all because in some situations IMM#finishInputLocked()
has never been called even when the attached view loses input
focus.
In order to fix Issue 20820914, however, we need to call
IMM#finishInputLocked() exactly when the attached view loses
input focus. To make it easier to diagnose any unexpected
regressions, this CL only changes the handling of
IMM#mCurRootView, while the next CL Id6afc8fc64512225578c62557b96
plumbs IMM#focusOut() to IMM#finishInputLocked().
Manually tested following scenarios.
- Repro steps in Bug 6413553. Made sure that IMM#mCurRootView
is cleared after switching back from the current application to
the previous application with back key.
- Test application that calls WebView#showFindDialog(). Made sure
that LatinIME works fine when switching text fields. This is
non-trivial because android.webkit.FindActionModeCallback is
changed in this CL.
- Repro steps in Bug 21144633. Made sure that we can enter
recipient's name in the messaging app.
Bug: 20820914
Change-Id: I219394178e4172bc47864297f1418e677dba25e5
