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
ListView child views with transientState (setHasTransientState(true)) are not
handled correctly when the data set changes, such as when an item is added
or removed. The problem is that the transient views are cached by their
position, but this position is out of sync between the ListView and the adapter
until the ListView layout process is complete.
A better way, which unfortunately only works on ListViews with stable IDs, is
to cache the views by their itemID instead, and to use that ID to determine when
and where to reuse/retrieve a transient view during the ListView layout.
Issue #8254775 View.setHasTransient state has side-effects when deleting content in ListView
Change-Id: I2fc25e71ed6655af30b9c3f47fdf014e9b667616
If the calendar view of the date picker dialog is shown we
do not use a formatted date as the dialog title since the
calendar view shows it, instead we show a static "Set date"
title. However, the initial state of the date picker dialog
on a tablet has a formatted date since the date picker widget
does not do a correct check whether the calendar view is shown
which returns a false negative resulting in a title with a
formatted date being added since the dialog thinks it has no
calendar view.
Change-Id: Ibf4c433b34ab1ee1bc1dc386689664a32283fb6a
- instead of passing the screen size as a constant for computing the
layout size in RTL mode, we just use a real constant. Any value would
work actually, as soon as the value would not be null.
Change-Id: If9f5b38afa88938db36a795bfc8a403ad660726b
When the "delete" pop-up is clicked (and the wrapped text removed), the
creator of the span will receive a notification of the action.
Similarly, if the user modifies (i.e., add/remove a char), the creator of
the span will receive a notification too. The notification will not contain any
information about how the text has been modified.
Bug: 6905960
Change-Id: Ic227b8fd50066699915f69a54f225fb5330867c4
The exposed APIs are slightly simpler than the full APIs used internally.
Only APIs useful to applications are exposed.
Change-Id: Ie03014628d40ad5ef63dedbc52ce3def84429d54
Allow developers to specify shadow properties for text in a
TextAppearance, not just in direct TextView attributes.
Change-Id: I873fbaf2c26683895e1eea2d02b5d9b17ca333d0
