Perform app op check in addition to the permisison check for all four
paltform components - activities, content providers, broadcast receivers,
services - if they are guarded by a permssion that has an associated app
op. This ensures that legacy apps will behave correctly if the permission
of the caller has been revoked, i.e. the app op for that permission was
disabled.
bug:22199666
Change-Id: Ia22d1c38d58b3cd6aabdc655cb7c7bddd85da7a2
Just forgot to add the request to the active set.
Also eradicate a bunch of old cruft that has been replaced
by the final APIs, and improve voice interaction test to
sit fully on top of the final APIs and have a test for
command request.
Change-Id: Ieff7a6165ebf2a4c5fb80c1ebd020511a2ae63ee
1. Mark the installer permissions as not revocable.
2. Make the permission result dispatch more robust to handle installer death.
bug:22012614
Change-Id: Idee30ca884b87ccf97ba1bb878d4c49912e474b8
The order of finalization between the parcel and the UsageEvents
objects is not defined. In the bad case, the parcel will be
finalized first and destroy its native pointer, after which the
UsageEvents object will recycle it, putting it back into one of
the Parcel pools. This will violate the pool invariant.
Bug: 22088355
Change-Id: Ifbe7822990cdfc31855d6742dcdea9d9dd0daf1b
Bug 22174959
According to FragmentTransaction's reference, replace()
should be equivalent to remove()'ing every fragment in
a given container and then adding the specified fragment
to replace those that were removed.
Commit ee76efb74b broke
this intended behavior in the framework.
This patch makes it so that the removal loop doesn't
end prematurely. It also fixes an issue where the
replace operation would remove fragments regardless
of their container after encountering the first fragment
with a matching container ID.
Relevant issues:
http://b.android.com/43265http://b.android.com/52112http://b.android.com/53393http://b.android.com/68856http://b.android.com/70803
Change-Id: Ica4691746ab8979ed974a998e85324e4feacc5e3
Signed-off-by: Eddie Ringle <eddie.ringle@gmail.com>
When a device or profile owner disables screen capture, we also want to
block context data being collected for the assist structure.
Bug: 21797707
Change-Id: Ib8716c6dd71d538a027c04e1e907c87e2afa0ac8
...into account when calculating the position information
Actually what we need here is the full transformation matrix, if it
is available. And that means actually computing the location of
views on the screen requires doing this all through transformations,
so the AssistVisualizer has been changed to do this (while still
also keeping the old mechanism for comparison to verify that things
are working correctly).
Also added new properties for elevation and alpha.
And optimized the parcelling of AssistStructure to not write things
that aren't needed; this reduces the parcelled size by about half.
Change-Id: I50b0dd2e6599c74701a5d188617a3eff64b07d03
The new option "--track-allocation" is to work with the new
allocation tracker in ART.
Bug:20037135
Change-Id: Ic5f8945ab4c1f167c27b05ad0d11d04bac680c1f
Otherwise after the Device Owner is gone, runtime
permissions might still be auto granted/denied.
I understand that there are many other policies that
we don't reset after the device/profile owner goes
away (e.g. keyguard enabled/disabled). At least now
we have a single method when we could clear the
ones that we care about.
Bug: 21889278
Change-Id: I6997655e6ef6d474bd25ae1c323eca5b17944b16
