We have a bunch of magic that mounts the correct view of storage
access based on the runtime permissions of an app, but we forgot to
protect the real underlying data sources; oops.
This series of changes just bumps the directory heirarchy one level
to give us /mnt/runtime which we can mask off as 0700 to prevent
people from jumping to the exposed internals.
Also add CTS tests to verify that we're protecting access to
internal mount points like this.
Bug: 22964288
Change-Id: I74dbdcb01d4fabe92166b8043a74c6a1e93c6d5f
BUG: 22957980
If a file was present in the backup but excluded on restore,
it can result in the restored data being corrupted.
Ensure that FullBackup.restoreFile is called with a
null destination, which will result in the file not
being written to disk, but still properly pulled
from the socket.
Change-Id: Iac882a961b76e687654535aec352678486a08c39
When lock task mode is started, we verify that the package is
whitelisted and currently use mCallingPackage as indicator. However,
the calling package is not necessarily identical to the package trying
to lock itself, so lock task mode sometimes fails. Switching over to
using realActivity as package marker.
Bug: 22916291
Change-Id: Ifd4df2d634842c8106b0b0f690bcf1faba0ed5fa
We were always setting the background of the decor view when the
"above anchor" state changed, rather than the background view.
Bug: 22970244
Change-Id: I3cd7202767ee47cb415736bb3c07369801abccd8
Add additional information about the intentions of result codes in
device-owner and profile-owner launch intents, in alignment with
changes made in http://ag/732321.
Bug: 21063241
Change-Id: I0e0a931739cee5f46e8fc7622fe1de49e26dcb0a
An optimization in ImageView nulled out the internal bitmap of a cached
internal BitmapDrawable object created to wrap a bitmap set on the ImageView.
However, apps can get ahold of that cached object via Drawable.getBitmap(),
resulting in having the state of that object they may be using changing out
from under them.
The change is to null out the cached object when getDrawable() is called, to avoid
leaking internal state that we may change.
That way, the app can continue to use that object if they want to, but we are no longer
relying on it internally, and will create a new one when needed.
Issue #22930646 [1P Regression from L] ImageView is blanked out in Activity in Google Express
Change-Id: Ic86cb93be4897b6ba247c1fabcda507e4ba01300
This allows the both the ssid and connection info to be verified when
updating wifi info.
Bug: 22797622
Change-Id: I82d771a299e17469683516c6b1077cb260981812
Add new Activity callback to tell it when its saved state has
been invalidated.
The problem is that delivering the permission result does not go
through a path where the compatibility code can see it first to
mark its fragment manager as no longer having saved state. So this
new callback gives it a place to do that.
Change-Id: I5a4a185d9c746bae1afb5c588aba82c8daccf079
In ag/733689, which was intended to fix this bug, the following lines
were removed:
// Propagate the permissions state as we do want to drop on the floor
// runtime permissions. The update permissions method below will take
// care of removing obsolete permissions and grant install permissions.
ps.getPermissionsState().copyFrom(disabledPs.getPermissionsState());
The intent with these lines seemed to be that we needed to copy
permissions from the application on /data, which is being uninstalled,
over to the copy on /system, which was disabled but is being
reenabled. However, it wasn't functional, because it incorrectly
copied from the copy on /system, not the copy on /data.
Restore this code, copying from newPs (the copy on /data) rather than
disbledPs (the copy on /system), and clarify the comment because we do
*not* want to drop runtime permissions on the floor.
Bug: 22665508
Change-Id: I6bae37e70b6df1043c9a2b49255b985707ba151a
* commit '8eaf18b0ab77184f16870428258650bd12bb2ea5':
Documenting behavior of returning a 0-length array for formats, channels, rates queries for analog devices.
When the device is lost or stolen, it's safer to
fall back to strong authentication (pin, pattern or
password). This disables fingerprint like we do with
trust agents.
Fixes bug 21620081
Change-Id: I7bbe54be3721b2f160b783daeb3acbe434705046
