After the system user is split out, all users are more or less the same.
We combine the generic user and secondary user create method to reflect
this concept. This also fixes the bug the newly created Primary user
from lock screen contains secondary user restrictions.
Bug: 19913735
Change-Id: Iff8802cd46401081bb444317becaf6ecab934e1e
- 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
