A restricted Context is a special type of Context that prevents specific features
from being used. For instance, android:onClick, used by View, can be dangerous when
used from within apps widgets. By using a restricted Context to inflate apps widgets,
widgets providers are prevented from using android:onClick.
The bug (1947162) is caused by the fact that sometimes, surfaceChanged() is called after onCompletion().
In surfaceChanged(), start() is called automatically. The fix is to use a flag is avoid calling start()
when onCompletion() has been called already.
On invoking the search UI, the drop down list box with past queries and shortcut items
appears after a few hundreds of milliseconds on screen. This was because we were
displaying the drop down within the onFilterCompleted callback after the list box filtered
the items based on the given query text. While that code path is necessary, for the first
invocation of the search dialog with an empty query we can show the list box before the
text stuff happens. This change does that, issuing an async request to show the drop
down after pending events have been processed.
Without this change, on an average it took 350ms for the code to show the drop down.
With this change, on an average it takes 150ms.
It looks like the drop down list had already been taken down before the
callback fired so it caused a null pointer exception. In this case just
do nothing instead.
Bug 1927858
RelativeLayout, when measured with AT_MOST, was applying the gravity on its
children way too early. This caused the RL to set its measured size to
a value that was larger than necessary. This fixes the issue by deferring
the positioning of the gravity-dependent children until the dimensions
of the layout are known.
* changes:
* new screen resolution support impl. * use full window for activities, and shift & clip the content * refactored the compatibility code, and introdcued Translator class to handle cooridnate translations. * removed a workaround to handle an activity with configChagne=rotation in old implementation. * I'll fix background issue on rotation in next CL.
This fixes a bug in ListView#setItemChecked(int, boolean). Calling the method
twice would cause the checked state to be toggled instead of remaining the
same.
* use full window for activities, and shift & clip the content
* refactored the compatibility code, and introdcued Translator class to handle cooridnate translations.
* removed a workaround to handle an activity with configChagne=rotation in old implementation.
* I'll fix background issue on rotation in next CL.
* removed unnecessary scaling code in SurfaceView, which I forgot to remove when I changed SurfaceView
not to scale the content.
order.
The new implementation uses a dually topologically sorted graph of the child
views. The graph of dependencies is sorted once for the rules that impact the
horizontal axis (toLeftOf, alignRight, etc.) and once for the rules that impact
the vertical axis (above, below, etc.)
Doing so gives the ability to declare dependencies in any order, allows for
partial cycles in the graph (given view1 and view2, view1 can be toRightOf=view2
and view2 can be above=view1) and probably gets rid of most surprising behaviors
of RelativeLayout.
These are all variations of needing to validate ranges on editing operations
coming from the IME, to account for the underlying text changing (usually being
deleted) asynchronously with the IME.
It doesn't make much sense to ellipsize the text entered by the user, so we
just ellipsize the hint. This avoids introducing a new XML attribute/Java API
just for the particular case of ellipsizing the hint.
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
