- New screen on app op to record the last time each app has
caused the screen to be turned on.
- New battery stats event that tells us the reason the screen
has been asked to turn on.
- Propagate out power manager API to specify the reason a caller
is asking to have the screen turned on.
Note that currently the window flag to turn the screen on bypasses
much of this because it is being handled in the window manager by
just directly telling the power manager to turn the screen on. To
make this better we need a new API where it can specify who it is
calling the API for.
Change-Id: I667e56cb1f80508d054da004db667efbcc22e971
We now place whoever is receiving the MMS on the temporary
whitelist while doing so, so they can get network access to
download it.
There was also an issue that needed to be fixed where we
were no longer updating the list of allowed uids while
dozing based on their proc states... we now do that.
Also did a bit of optimization of the temp white list update
path do the network policy manager, instead of going through
a broadcast we now directly call in to the network policy
manager. This also allows us to have a synchronous version
of updating the list, so we can know the app has network access
before we tell it to do anything.
Finally added battery stats events for things going on and off
the whitelist so we can diagnose the behavior there.
Change-Id: Ic7fe010af680034d9f8cb014bb135b2addef7455
Give more details about why we failed to create storage paths, and
search for underlying volumes using canonical paths.
Bug: 22135060
Change-Id: I75d3584403ece310438b05f5b9fe72d94c9096c6
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
countInstancesOfClasses allows passing multiple classes unlike
countInstanceOfClass. This provides a speedup since we dont traverse
the heap multiple times.
Changed ActivityThread.dumpMemInfo to do a GC since countInstancesOfClass
no longer does GC before counting.
https://code.google.com/p/android/issues/detail?id=177552
Change-Id: Ia85684f40cf59a52aa71a8479c711a994651209b
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
