This is the 3rd trial to fix Bug 20820914.
In followig CLs, we have tried to address a input session
leak when the focused view is detached from the focused
window by relying on IMM#focusOut() but failed because of
regressions like Bug 21508503.
- Ib4bd70ce0305a6bde6a929bcc6ad20a2b8402a97
- I219394178e4172bc47864297f1418e677dba25e5
- Id6afc8fc64512225578c62557b96c7dc2e969adf
- Ib1b037594ebbb4ad4cf2d59e21c7a8ca9d8dc930
- I2228ae0c48ad3d9e0b55875f0dcb5ef8c55b0c5f
What we have learned from Bug 21508503 was that re-enabling
IMM#focusOut() probably requires much more work than we
thought. Also relying on IMM#focusOut() might be overkill
because the situation in Bug 20820914 is really special where
the focused view is detached from the focused window hence
we should be able to be fix the issue more conservatively
by closing input session when and only when the focused
view is detached from the focused view, rather than
re-enabling IMM#focusOut() globally.
Bug: 20820914
Change-Id: Iaf3fe2c065b5bf91e49a729ba46262114bb6da88
Added some new callbacks that can be used to more precisely trigger
certain behaviors that need to happen around the time the device
is put to sleep and locked.
Fixed an issue where the going to sleep signal might be sent too
early on devices that don't support ambient mode due to the extra
wakefulness change between DOZING and ASLEEP. We are now track
the early / late interactive change work separately from the rest.
Bug: 21375811
Change-Id: I95387195e216ae92a6e45485bd1bd362e41aa45a
This reverts commit 41bb4953da.
Ib1b037594ebbb4ad4cf2d59e21c7a8ca9d8dc930 caused Bug 21508503.
Since it looks like a timing issue, many other applications
could be affected potentially.
Bug 21508503 implies that re-enabling IMM#focusOut() globally
requires much more work than we thought. Probably the memory
leak found in Bug 20820914 should be addressed in a more
conservative way at the moment, e.g., by plumbing events from
ViewGroup to IMMS.
Bug: 21508503
Bug: 20820914
Change-Id: I2228ae0c48ad3d9e0b55875f0dcb5ef8c55b0c5f
This CL checks for the return value for Rect.intersect() for whether
there is actually an intersection before taking the return intersected
rect. In the case of no intersection (Rect.intersect() returns false),
an empty rect will be used as the intersection.
bug: 7368679
Change-Id: Ib874345210c8f62550627544d717e958d46cfe13
Changes to the data provided to AssistStructure:
* Text foreground color is correct even if the view has not yet been
painted.
* Text background color is now always 1 (TEXT_COLOR_UNDEFINED) for a
TextView, as it has no separate concept of background color.
* Switch now reports the text size/color/style of the label text
(usually user visible) rather than the on/off text on the button
itself (usually hidden in Material, and not usually revelant when
visible).
Bug: 21080375
Change-Id: I7e15f68d89510a76cab76031c2c8ca6ca3f32435
This includes the fix for the broken dialog windows. The outsets will
only be calculated and applied if the window is full screen, since
they don't make much sense otherwise.
This reverts commit 4bb6b751fb.
Change-Id: I977a85a78c990c1840784dc0be0dddd5a6d84e6b
Button press events now occur in onGenericMotionEvent. This CL update the
button press detection code in GestureDetector to recognize the gestures
within onGenericMotionEvent rather than in onTouchEvent.
Bug: 21148238
Change-Id: I6729668ed9bb600d8bf5e42e5ba9d8201b642d68
Button press events now occur in onGenericMotionEvent. This CL updates
the button press detection code in View to recognize the gesture within
onGenericMotionEvent rather than in onTouchEvent.
Bug: 21148238
Change-Id: I6b5d6d6840e7cb6d3dabf8b138828ae862db8ed4
Previously we were only partially transforming the focus rect into
window coordinates, so it was offset when the window was panned (for
example, when the IME was showing).
Bug: 20113389
Change-Id: I41f5ed20cb1404232b7042d37ca2fc725f9ee476
Historically we have been doing nothing in IMM#focusOut().
Problem of ignoring IMM#focusOut() may not be obvious as
long as IMM#focusIn() is called immediately after
IMM#focusOut(). In some particular situations, however,
IMM can fall into an inconsistent state where the software
keyboard continues to be shown even when there is no text
input field.
As reported in b.android.com/171190 or Bug 20820914, we
can easily reproduce that inconsistent state by removing
a focused EditText from the parent view while the IME still
keeps an active connection to the EditText.
This CL tries to address such a situation by staring using
IMM#focusOut() as another trigger to check IME focus.
Note that this CL has no effect if IMM#focusOut was called
after the current window losed the focus. It is supposed to
be taken care of in subsequent CLs for Bug 20612313.
This CL depends on Id6afc8fc64512225578c62557b96c7dc2e969adf.
Bug: 20612313
Change-Id: Ib1b037594ebbb4ad4cf2d59e21c7a8ca9d8dc930
When we update drawable visibility has changed to be part of
View.onVisibilityChanged instead of an overload of
setVisibility. While this covers more cases that we were previously
missing, it also means that we now set drawable visibility from the
View constructor via the call chain view.setFlags to
view.onVisibilityChanged to drawable.setVisibility, resulting in us
passing a 'this' pointer all over before the object is fully
initialized. (i.e. a Bad Thing.)
In general we've gotten away with playing fast and loose with this
sort of thing as a part of view inflation - calling various non-final
setters that may invoke callbacks as needed rather than initializing
view fields directly. Unfortunately it also means that we can cause a
lot of hard to trace bugs and in the long run we should try to clean
up as much of it as we can.
In this case, some apps were expecting inflation to have finished
completely before any drawable visibility changed. If a view's
visibility changes but it's not attached to a window, does it make a
callback?
The fix: no. We won't dispatch onVisibilityChanged to detached views,
but we will dispatch it when a view becomes attached.
Also fix a bug where we could end up telling a view its visibility
changed to (INVISIBLE | GONE), which just doesn't make any sense.
Bug 20103422
Change-Id: Ifba54c36114e85cf64869afcca766c30d601a16c
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
