For modern apps targeting M SDK and up the external storage state
is deterined by granted permissions. For apps targeting older SDK
the storage access is determined by app ops correspning to the
storage permissions as the latter are always granted.
When app ops change we do not remount as we kill the app process
in both cases enabling and disabling an app op since legacy code
is not prepared for dynamic behavior where an operation that failed
may next succeed. Hence, we remount when we start the app.
For modern apps we don't kill the app process on a permission
grant, therefore we synchronously remount the app storage.
bug:22104923
Change-Id: I601c19c764a74c2d15bea6630d0f5fdc52bf6a5a
We can now stream the AssistStructure across processes, avoiding
IPC size limitations for large structures. There is also a new
API that gets called on the VoiceInteractionSession if there is
a failure retrieving the assist data.
Also fix issue #22351981: Runtime restart due to ANR in system server,
getting rid of a deadlock.
And also tweak object lifecycles to try to avoid keeping around
in an app the previous AssistStructure after we request a new one.
Change-Id: Ifb136a0d31a14e56a8db6b90768d9fc65557a17f
It ends up that MediaProvider is persisting MTP storage IDs in its
database, so we need to make sure we generate stable IDs over time,
otherwise we can end up looking into a black hole.
Bug: 22256092
Change-Id: I6a75c239aac1b71fd5f6df0df69b24971079a086
Users can try migrating primary storage while the current location
is missing/unmounted. Fail gracefully instead of runtime restarting.
Bug: 21927076
Change-Id: I40645f8ccea05154e7cbacd188f6cba5f4dbbdc4
Many things can happen while a private volume is ejected, so we need
to reconcile newly mounted volumes against known state.
First, user IDs can be recycled, so we store the serial number in the
extended attributes of the /data/user/[id] directory inode. Since a
serial number is always unique, we can quickly determine if a user
directory "10" really belongs to the current user "10". When we
detect a mismatched serial number, we destroy all data belonging to
that user. Gracefully handles upgrade case and assumes current serial
number is valid when none is defined.
Second, we destroy apps that we find no record of, either due to
uninstallation while the volume was unmounted, or reinstallation on
another volume.
When mounting a volume, ensure that data directories exist for all
current users. Similarly, create data directories on all mounted
volumes when creating a user. When forgetting a volume, gracefully
uninstall any apps that had been installed on that volume.
Bug: 20674082, 20275572
Change-Id: I4e3448837f7c03daf00d71681ebdc96e3d8b9cc9
Request benchmarking of devices once per week during normal fstrim
maintenance window. Tunable parameter gives us the ability to change
frequency through global setting.
Track individual benchmark and trim results for each volume, and
use scrubbed volume identifier (based on adoptiong age) when logging
stats to drop box. Track last benchmark and trim time for each
volume separately.
Bug: 21831325
Change-Id: I53b3ed788f7820c2e5bceb2840339f5b4aada3f0
Issue #22209630: Only allow whitelisted apps to put apps on the temp whitelist
We now check whether the calling app is a system uid or in the whitelist
and, if not, throw an exception.
Issue #22225665: Alarm still goes off in idle mode (doze)
Fix a bug where we were not clearing the calling identity when coming
through the dump command to the service, and as a result when we would
eventually call out to the alarm manager it wouldn't do what we want.
This was only broken when being controlled by the shell.
Also adjust the network policy manager service's handling of device
idle transitions to only toggle the device idle state, which gets rid
of the long delay we have coming out of idle mode. And add in a bit
of logging around going in/out of idle mode to try to understand where
things may be slow in the future.
Change-Id: I4a41f790e9b0bb31330314b94111557d479f2ba5
For now we are just recording the power usage and not using it
to calculate battery power usage or app blame. If it looks like
it is accurate, we'll adopt the values from the kernel instead of
estimating ourselves.
Bug:21498425
Change-Id: I6617e3c0ff279a65f4ff84472082f36fe4beb336
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
If the profile owner sets ALLOW_PARENT_APP_LINKING:
ACTION_VIEW, scheme http/https intents sent from the work profile
can be resolved by personal apps if they specify a host.
BUG:21701782
Change-Id: I372e2405345539eac9d6b4fb08def6bf84da14a6
When we forget a private partition, ask vold to also forget the key
for that partition GUID. This means we need to track both the
filesystem UUID and the partition GUID for a private volume.
Bug: 21782268
Change-Id: Icda1cbb65539d61dacc663428daf3d1a2e4c313e
The doze wake lock is an internal implementation detail with no
power impact. However the draw wake lock is much more interesting
to track because it's essentially like a special purpose partial
wake lock which may be acquired while dozing.
Bug: 21949905
Change-Id: Iedd5f366eb010a47a9691374c5cd3d85ea68173d
Doze wake locks don't actually hold the CPU awake, so we should record them
separately from full wakelocks, which is what we did before.
Bug:21949905
Change-Id: Ib4db3399069e0ad11f1f0dc6925a87ad0ad21ff9
Rework how we record active transitions in battery stats to be
more general, and add an API that others can call in to
DeviceIdleController to request that we go out of idle mode.
use this for VOICE_SEARCH_HANDS_FREE.
Change-Id: Ie58de60e63036a4142881283835961fbcceec892
We used to give 50% of the cpu time of each app to any app holding a wakelock
while the screen is off.
Since we switched to the new kernel module for measuring app's cpu time, this distribution
was lost.
Bug:21876567
Change-Id: I42c294547f63d150d9929271ca0e27fedaaa9d77
This is an attempt to speed up getting out of device idle. It groups
uid firewall rules in these child chains so we can attach/detach a whole
chain instead of individual uid rules.
BUG:21446713
Change-Id: Ie8f392da2deabe7cc86a9ecf4ed080163861d41e
Looks like we were losing some power calculations from the CPU side of Bluetooth and
WiFi if there was no controller activity ocurring.
Also add finer breakdown of power to BatteryStats dumpsys for WiFi and Bluetooth.
Change-Id: Ic3ce3e4e3b854f17f9a32fd4bdc47a8ea74ca439
