Some apps have managed to hit this edge case in monkey runs. In
layoutChildren an attempt to findFocus() fails when items are
focusable. When ListView attempts to restore focus to this view,
bad things happen.
Change-Id: Ie8bb1bab847898e342c16fbe3ff1a6153d6f69df
These markers will be used to group the GL commands by View in the
OpenGL ES debugging tool. This will help correlate individual GL
calls to higher level components like Views.
Change-Id: I73607ba2e7224a80ac32527968261ee008f049c6
When a view is becoming VISIBLE or INVISIBLE in a container with a
LayoutTransition, animations run to fade the view in and out and also
to run 'changing' animations on the view's other siblings. This logic
also cancels any running 'changin' animations to account for new ones
running.
However, in the specific case of INVISIBLE changes, there will be no
layout changes in the container - layout has already accounted for that
view (unlike in the case of GONE views); the visibility is just a matter of
drawing the view (or not). Therefore, we're canceling 'changing' animations
that should continue running and not replacing them with any other animations,
since new animations would only be started on layout chnages which are not
forthcoming.
One artifact seen from this bug is that the navigation bar buttons sometimes
disappear when changing orientation. This is because the menu button may
toggle between VISIBLE and INVISIBLE, causing animations on the other
buttons to get canceled, which leaves those views in a completely wrong
state.
The right thing to do is to avoid canceling in-process 'changing' animations
and to skip the logic of setting up new 'changing' animations which won't fire
anyway.
There is some minor API work in here because we did not previously have the
necessary information in LayoutTransition to know whether a view was being
hidden or shown to/from the INVISIBLE state.
Issue #5911213: LayoutTransitions ending in an odd state
Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
Bug 5556478
Launcher pre-populates its all apps and widget pages with their
content, which includes text. The layout calls some onMeasure methods
that trigger TextView's registerForPreDraw(), which in turns adds a
listener in the ViewTreeObserver.
However, some of these pages may never be actually displayed, leaving
the listeners in the list since onDraw() is never called.
As a result, every frame displayed by launcher is slowned down by this
array copy of 6-18 listeners.
The problem is not Launcher specific since other applications may use
a similar caching mechanism.
The solution is to unsubscribe the listener in onPreDraw.
The drawback is that several successive calls to registerForPreDraw() will
add/remove the some listener object. However, these calls are rare and are
relatively cheap since we're just adding the object in and out of an
ArrayList which should not need to change its size.
Change-Id: Ifb65655a27e302d31a2ad622d18f839aec99689e
This new test is required since the suggestion popup is now triggered by a
Runnable. We have to make sure there is still at least one SuggestionSpan
at that position.
Change-Id: I5c84ba0ca412f51a0201bee5c2e63b5bd3717338
Bug 5916225
Duplicates were removed when received from SpellChecker, in a way
that could move the top candidates lower in the list.
Moved that code to the part that creates the actual suggestion list,
to make it more generic. The order of the first SuggestionSpan is
guaranteed to be respected.
Also mentionned non null suggestions and fixed a problem in SuggestionSpan
constructor.
Change-Id: Iaa3b1b84ae512451e439e5c5e63448c2a19145b5
is reset.
As per platform guidelines, when launching a sharing activity the Intent
flag FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET should be used.
Change-Id: I30bd3d20eb75aee7943b681dc2d9c7f44a04e919
1. The selector wheel was throwing an exception if a client requires that it
wraps its selector wheel if the number of values is less that the number
of values shown in the wheel. While wrapping makes no sense if the all
possible values are already shown, we should not throw an exception,
rather to ignore the request.
bug:5911190
Change-Id: Icd90cd39f66d9f39939801752bf1eb1eef8fe757
Bug introduced in recent refactoring
https://android-git.corp.google.com/g/#/c/158896/
Do not move cursor when selectAllOnFocus and focus just happened.
The didTouchFocusSelect() condition was not copied over from ArrowKeyMM.
Change-Id: Id01d225c436ae3dd97c5d77d5dac5d0690d7de76
Using a runnable to schedule the action, interrupted by any other
touch event, enabling a catch of a double tap to trigger text selection
instead.
Change-Id: I21f8b9fdfad0036d6970f5dbfe6d72dd3eff35a1
When text can indeed be selected, we should always initiate
a text selection on long press. When the WordIterator fails
(for instance if the text is entirely made of punctuation
characters, maybe also with foreign languages), we select
one character.
Change-Id: I842507f7cbaed9a924d3176ea8ed6586f3548366
Bug 5749557
Not clear how we can get an AOOB in that case.
tmp will always have the right length, and indeed the stack
trace attached to that bug shows a correct size of 10.
However, there is an index issue when we build the new
completion array. i is not the correct index to use.
Note however that the original buildDropDown method mentioned
is no longer present in the file. I tried to backtrack, but
the use of arraycopy always seemed correct.
Change-Id: Idf749c74b38923b5d18596c8e8f6ea887cc897d6
Similar to what is done in GestureDetector
Removed all gesture constants. Only one one them is used on MOVE
(added an early exit test), the 2 others on UP or DOWN where
performance is not such an issue.
Change-Id: Icd58ead5078f94f86786f934ddf81aa5ec9bf549
-> This prevents collection widgets from flashing loading
views when they are updated with new content
Change-Id: I1241ff9a09edfd990ad03f76449d18b9359246b4
AccessibilityEvent and AccessibilityNodeInfo have a property className which is set to the source
Java class. This is problematic since leads to leaking private classes which would allow an
accessibility service to load classes from other packages. This is strongly undesirable since
not trusted code can be loaded, and hence executed, in the accessibility service. To address
that the class name is set to the most concrete framework class extended by the info/event
source.
bug:5878943
Change-Id: I7b3114ece8772ea2773f5151e21b8a6f2006882a
Stop selection mode after Edit/Copy while in extracted mode.
The selection mode was started by a long press in the ExtractedEditText.
Selection Copy in the menu simply sends the id to the context menu.
SelectionMode is not stopped in the underlying text since it was not
started there. Stop it directly in the ExtractedEditText.
Cut and paste do stop the mode because the text is modified.
Change-Id: Id7dbfa99de404c4eb85ced9627c99af4895ac628
TextView uses a sub-display list to 'cache' the rendering of its
text. This saves time when drawing an editable text, where the blinking
cursor forces a re-draw twice per second, which creates pauses during
scrolling.
Added a sub-display list invalidation when an appearance span is
modified/added/removed.
Also added an invalidation of the display list when selection range
is changed.
Change-Id: I41e8068a12902b8a745c5bb77de8c77def76a270
