If there is no resource-named default but there is a single factory-
installed browser app, that app is made the titular default.
This also introduces a permission guard on attempts to set the
default browser or the app-link state. These operations are now
contingent on the existing SET_PREFERRED_APPLICATIONS permission.
Bug 21778406
Change-Id: Id099bb9c4141f28917546492657cd2fba472e6b6
The media provider and some other things need to be given storage access.
Also, seems like we should give storage access to the camera app as well.
And add a dump dump command that will dump data about a particular
permission name.
Change-Id: Idaaa9bba2ff4dc95290cf6d17e5df933df91e909
Restricted profiles don't have their own VPN configuration - whatever
is in charge of VPN for our USER_OWNER user will have network traffic
routed to it instead.
Bug: 18419023
Bug: 21188177
Change-Id: I7205d90032461c240048a036606c3a7938d0eda2
In order to reduce the number of binder calls, only install an
audio port callback in a client process if either:
- an audio port related API has been called once
- an audio port listenr has been registered.
Bug: 22045560.
Change-Id: I0e5cf31bec0c986d6f7761891b860ba6fadd2f4c
If you select some text normally while in accessibility mode, it
should be cleared and handles should not show if you initiate text
selection using the accessibility context menu.
Bug: 22071639
Change-Id: I32b966e771ba5715a0ab370e6aa602398e5ec534
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: I62fb25d126dd815aea699b33d580e3afb90f8fd2
...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
Android Keystore cannot offer crypto operations for public keys of
trusted certificate entries (entries without a private key). Prior to
this CL it accidentally tried to do so, causing crypto operations on
these keys to fail.
The fix is for Android Keystore to offer crypto operations only for
public keys for which there is a corresponding private key in the
keystore. Crypto operations on public keys from trusted certificate
entries will be handled by other installed crypto providers. Those
providers don't need a private key to carry out these operations on
public keys.
Bug: 22091725
Bug: 21835320
Change-Id: Ib7d92b067711e4c57128d0db72c08bf288a45ce1
1. Add the permission protection level in the java doc
2. Make some system permissions that are not mean to be
used by third-parties system API.
bug:21402257
Change-Id: Ic0ae8d6ca44dbbbf12848a9164acc0e908c90402
This ensures that theme attribute values that affect the look and
feel of the FloatingToolbar views are the ones specified in the
framework.
The aim is to avoid apps modifying the toolbar's look and feel in
unexpected ways by overriding Theme attributes.
Bug: 21957785
Change-Id: Idd472b4e8511f0a039cd07f98b1fd3ce93ae97fa
