1. The number picker no longer shows up and down arrows, it
has only three touch targets which are the currently selected number
in the middle with a lesser one above and greater below, now what
you touch is what you get, flingability and long press are still
supported.
2. Removed the restriction for a View with an AccessibilityNodeProvider
to not have any concrete children. If the View has a provider, then
this provider is responsible for creating the AccessibilityNodeInfos
for all its descendants, concrete and virtual. The number picker is
a good example for such a case - it has a concrete input view and
two virtual buttons as its children. This is a safe change since
this behavior has not been released.
3. This patch also fixes bug where the number picker is stretched too
much in the Theme theme.
bug:6177794
bug:5728294
Change-Id: I5fb370fe0b864a156f5f2aaf2de5f55f6b6d4e84
Store enforcement state of specific permissions, allowing them to be
selectively enforced. Currently supports READ_EXTERNAL_STORAGE, which
by default isn't enforced, but enforcement can be enabled at runtime.
Bug: 6131916
Change-Id: I4bcc215a2eb5e6507d6257b577311cbd13c77acf
New class lets you make an options bundle defining a custom animation,
as an alternative to Activity.overridePendingTransition().
Change-Id: I8e209bf52398a98ab9f1bcafa1ec0a580dae57c0
The VPN user ID is defined in android_filesystem_config.h as 1016. Add
it to android.os.Process so it can be referred to in Java code.
Change-Id: If3da3765747afda4e5e0761e289c45eebc7cddd5
This CL simply enables DisplayList property functionality. The code for
this feature is already there, but it's been disabled by default pending further
testing and analysis. This change sets these build-type flags to true
so that all hw-accelerated apps will now use DisplayList properties by default.
In particular, this feature enables a fast-path for changes that affect the
handful of View properties involved in animations (alpha, translationX, etc.).
Setting these properties now gets propagated to the native DisplayList associated
with the View, avoiding costly recreation of the SDK-level DisplayList and
also enabling faster invalidation of the view hierarchy.
Change-Id: Ic99c8f28fa9183f2e54e9e4860b333eb9c540f7c
1. The number picker no longer shows up and down arrows, it
has only three touch targets which are the currently selected number
in the middle with a lesser one above and greater below, now what
you touch is what you get, flingability and long press are still
supported.
2. Removed the restriction for a View with an AccessibilityNodeProvider
to not have any concrete children. If the View has a provider, then
this provider is responsible for creating the AccessibilityNodeInfos
for all its descendants, concrete and virtual. The number picker is
a good example for such a case - it has a concrete input view and
two virtual buttons as its children. This is a safe change since
this behavior has not been released.
3. This patch also fixes bug where the number picker is stretched too
much in the Theme theme.
bug:6177794
bug:5728294
Change-Id: Id8c0b3549174b9599f971d6e3086ca427cfbaa39
* Because the user directory probably won't exist, the renameTo
in previous code fails silently
Bug: 6188815
Change-Id: I6afd1bad9bbd1a36de7e93d9e02ed7172b1ed370
Starting several animations will place separate events onto the
animation queue, which may cause the active animations to get
processed more than once in any frame when one of those start messages
is processed.
This change moves the logic of starting pending animations into
the animation frame processing itself. Now when a start event is
processed, it only calls the animation frame logic if there are
unstarted animations pending.
Issue #6172602 Inconsistent animation callbacks
Change-Id: I3a546f0c849f42b2dd998f099fcdfafd7d780ad9
StrictMode posts a message to estimate how long the main thread was
blocked during a violation. Currently, any pending messages are
counted against the violation. To avoid this, switch to using
postAtFrontOfQueue().
Bug: 6119289
Change-Id: I94530632ca678b78b75a698cf9193641b102be9a
Subtype controls (3G-vs-4G) aren't exposed in the UI, so tracking
data with that granularity creates unnecessary overhead. For example,
some GSM networks can regularly flap between two subtypes.
Bug: 6118868
Change-Id: Id098891dba52336d00d0f96632a7924e228b4713
DisplayList properties are still disabled default (flags in View.java
and DisplayListRenderer.h). When they are enabled, and when a View has
a DisplayList, invalidations due to property changes are now optimized
to avoid causing DisplayList recreation. This eliminates the drawing step
of invalidation (due to changes in these properties), only requiring
issuing the previously-created DisplayList to the GL renderer. Invalidation
is slightly faster (less overhead as we walk up the hierarchy), getDisplayList()
is potentially much faster (going down to ~0ms), depending on the complexity
of the View being redrawn and the size of the invalidated hierarchy.
Change-Id: I57587d5b810c3595bdd72a6c52349c2a3d1bdf25
