This is a workaround for a touch mode issue.
Touch mode is propagated lazily to windows. This causes problems in
the following scenario:
- Type something in the AutoCompleteTextView and get some results
- Move down with the d-pad to select an item in the list
- Move up with the d-pad until the selection disappears
- Type more text in the AutoCompleteTextView *using the soft keyboard*
and get new results; you are now in touch mode
- The selection comes back on the first item in the list, even though
the list is supposed to be in touch mode
Using the soft keyboard triggers the touch mode change but that change
is propagated to our window only after the first list layout, therefore
after the list attempts to resurrect the selection.
The trick to work around this issue is to pretend the list is in touch
mode when we know that the selection should not appear, that is when
we know the user moved the selection away from the list.
This boolean is set to true whenever we explicitely hide the list's
selection and reset to false whenver we know the user moved the
selection back to the list.
When this boolean is true, isInTouchMode() returns true, otherwise it
returns super.isInTouchMode().
When debugging a problem with the search dialog drop-down
sometimes not showing up, I saw that the mAttachCount variable
in AutoCompleteTextView could get a negative value because
onDetachedFromWindow() was called multiple times. This lead to
the drop-down not being displayed on filtering.
Instead of the private attach count in ACTV, this change
uses View.getWindowVisibility().
This change adds the ability to specify an arbitrary view for a tab
indicator. It also adds support for specifying a drawable to use as
the divider between tab views.
When a "ghost" stroke was showing, events would be intercepted in ListView. This patch modifies the logic used to detect when to still events: either the current stroke is a gesture, or the previous stroke was a gesture.
* changes:
Fix int to string mapping of exported properties. The value generated by the mapping in a @ViewDebug.ExportedProperty annotation was always overriden by the resolveId attribute.
Prevents the gestures window from leaking. This change does exactly what was
done for the filter popup window: the popup is dismissed in onSaveInstanceState()
as it is the only place that is executed early enough to avoid the dreaded
window leak error.
* changes:
Fix a bug in AppSecurityPermissions where it wouldn't display permissions used by an app if it uses a shared user id. Remove the else clause and always get the list of requested permissions first before adding the permissions obtained via the shared user id. Also change an if condition and comments for better readability
Only update the popup window when it is shown. This avoids throwing an NPE in PopupWindow.
A PopupWindow is only aware of its content view after being shown.
If the list is opaque and its background is not, then we want to fill a solid rect where the dividers should be when they are skipped for non-selectable items. When the list is opaque and the background is also opaque, there is no need to draw something in lieu of the dividers since the background will do it for us.
Remove the else clause and always get the list of requested permissions first before adding the permissions obtained via
the shared user id.
Also change an if condition and comments for better readability
having the wrong version. I made the loader print a message to
the log for this, and made the calling code disable gestures
for the listview instead of crashing.
* changes:
Fixes#1853550. Prevent NPE when calling the PopupWindow() and PopupWindow(int, int) constructors. Instead, throw an IllegalStateException when trying to show a popup with no content view.
* changes:
Fixes 1844680. Interrupted scrolling could lead to rendering artifacts. The ListView was invalidating itself in opaque mode but before the drawing could happen, it was getting rid of its scrolling cache, thus becoming translucent again.
