The rendering code optimizes by rejecting drawing operations that
lie outside of the bounds of their views. This works in most
situations, but breaks down when containers have called
setClipChildren(false), because we reject drawing that is outside
of that container, but which should be drawn anyway.
Fix is to pass in the value of that flag to the DisplayList drawing
routines which take that flag into account when deciding whether
to quickReject any particular operation.
Issue #8659277 animation clipping
Change-Id: Ief568e4db01b533a97b3c5ea5ad777c03c0eea71
Fix for bug 8656899 API REVIEW:
android.util.PropertyValueModel/ValueModel,
android.widget.ValueEditor etc
Revert the change that added this API to remove it outright.
This reverts commit 989709a973
Change-Id: I9018cd8dadb1b1a54ad8749c816bd02bb7e7a38b
- in AbsListView, force setScrollbarPosition() when RTL properties change
- in FastScroller, invalidate the correct rectangle when in RTL mode and in STATE_EXIT
Change-Id: Ie9fe4f826e179eb993e443d10e171b9dda3b6f3f
Adding features which round out the animation APIs (missing
getters, etc.). Also fix doc typos.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I063736848ba26e6d6c809b15fc3a103c74222f46
In single line mode, changing the text from LTR to RTL (or vice versa)
affects the alignment, which in turn means that bringTextIntoView is
needed to update the scrolling. A registerForPredraw should be done to
make this happen, but it was missing. This patch tests explicitly for
direction changes in this case, and schedules a predraw if so.
Change-Id: I16e0e23141c244dc8adc00ea8306dfe4c9bf487d
Several conditions can cause an AbsListView's data set observer to be
removed and nulled out. If for some reason the view receives duplicate
onDetachedFromWindow events this could cause AbsListView to attempt to
unregister a null observer. Skip this unregister process if this
happens.
Bug 7088152
Change-Id: Ib0c630d1ee598640512023e4ef158f01e3ed474d
1) Make the box with the permission really go away when a
permission is revoked, not just invisible.
2) Change the order of the buttons, making the negative
button the "revoke" button, and the positive button "ok".
Change-Id: I73694583cbd014d3820f8df6c6b770caae299499
Add UI support for revoking optional permissions. When the user
taps on an optional permission, two new boxes will appear:
[Cancel] | [Revoke]
Selecting [Revoke] will revoke the permission from the app.
The [Cancel] / [Revoke] options are only shown for apps which support
optional permissions.
Bug: 8332307
Change-Id: I27e374773747737e3a6d7f48ea1448a0178e3393
Check for file:// Uris inside Intents, ClipData, Notifications and
RemoteViews when StrictMode option is enabled.
Also introduces Intent.prepareToLeaveProcess() to uniformly handle
Intents about to leave an app process.
Bug: 8529070
Change-Id: I8efb43877cbc5f21eb029fc6492b3ee1415059ef
Modify isDisplayablePermission to display a permission if the
app update will grant a new optional permission to the app.
Change-Id: Ic647826b0c48f9f7ec8e4f69b90197211f83278d
Add optional permission support to isDisplayablePermission.
A permission is displayable if it's required, or was previously
granted to the app.
Currently, this change is a no-op. The package parser code
does not currently honor <uses-permission android:required="false"> in
the application's manifest, and assumes a permission is always required.
This change sets the ground for future optional permissions work.
Change-Id: I2ec4a49adbfab9980e116ed43354f16bdeaa301d
The earlier patch 3cf7b3c59 introduced a stability regression. Perform
the appropriate bounds checking alongside the fix it implements.
Bug 8264185
Change-Id: I943d6c05bacdd777f89243fdac97788b16639dc6
- remove the ICU related methods and update the methods using the "reserved" argument
- update to CTS in another CL too
Change-Id: I5509736568c342d9d17bfeafc17951117ab5d3cc
- fix start/override mechanism
- take care of RTL compatibility mode (pre JB-MR1)
- fix where reset of drawables resolution needs to happen
Change-Id: I55a69487a0eedee14c4be7006ee0abad085200ad
This is the other part of a fix with transient state. A layout container
may be out of sync with its adapter during a data change. When the transient
state views are managed by their positions, and these positions may not match
between the container and the adapter, then the views will not be updated
correctly on the screen (though the underlying data will still be correct).
An earlier fix addressed the problem when the adapter has stable IDs (managing
the transient views by their IDs instead of their positions). This fix addresses
the other part of the problem, simply avoiding managing via positions during
a data change.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: I0fe1692a1507a042180f8a14a8ef2d0c6946a061
