One can set a view to be visited before/after another one for
accessibility but the before/after target views were always added
to the node info for the view regardless if they are included
for accessiilbity. Now the target viwes are reported only if they
should be included for accessibility.
Change-Id: Iba64e6f0ee0dc090c8c3e6a0a940df8c7ecd49d9
The legitimate uses of value to string coercion, including the
interaction between lax attribute formatting and AAPT type inference,
combined with the low likelihood of unintentional coercion and low cost
of most string coercions, makes the value to string coercion violation
overkill.
Bug: 21563086
Change-Id: I7892e776d3e5479fcba507749b074c2abdf1b781
Action modes that are not of type PRIMARY currently go through some
compatibility gymnastics so that the non-typed startActionModeForChild
ViewParent method has an opportunity to process them. Unfortunately, a
lot of apps in the wild use AppCompat, which intercepts these and
presents its own contextual action bar UI.
In practice this now means that the new floating toolbars for
TextViews and similar components don't show up in the majority of
existing apps. While this may be more correct from a compatibility
standpoint, it presents a poor user experience.
Only take the compatibility code path that calls through the older,
untyped startActionModeForChild method when the type is PRIMARY. The
tradeoff is that apps that previously would use parent views to modify
a text selection action mode will now no longer be able to do so.
Change-Id: I8c892a7a84ec36e6a484a5cba0c95281ea6beafb
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
MotioneEvent.BUTTON_SECONDARY is no longer used for M+, instead it will
be BUTTON_STYLUS_PRIMARY.
Bug: 21148238
Change-Id: If08a82e7be57798a2a747d29436e0411c76ef58f
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
