SharedMemory is parcelable and AIDL friendly
and exposes cool things like dropping write permissions
that are useful for shared memory to have.
Also exposes getFileDescriptor() on MemoryFile
since that was necessary to use MemoryFile
with IPC previously and there are a sizeable
number of reflections that access it, so just make
it public.
Test: SharedMemory CTS tests pass
Change-Id: I71a322abf2eb55267d7299a8e41f847339af8b08
Apps with a normal UID are typically isolated enough to not require
socket tagging; we're mostly interested in tracking down internal
UIDs that have lots of code sharing the same UID.
Also fix up everyone doing manual string checks of Build.TYPE, since
we now have first-class fields for those.
Bug: 38126076
Test: builds, boots
Change-Id: I3a40348196bd8459289f2b9355d9783a07f1e7dd
Bug: 29875093
Test: Run dumpsys meminfo -a, verify SwapPss adds up and is non-zero
for dalvik and native.
Change-Id: I79d0b6a59bf5f4e73f75f0b9540ec0fcc9e23b02
Offer to adopt storage devices on FBE devices, but keep it guarded
behind a system property for now, since we still need to work out key
storage details.
Verify that all users are unlocked before moving apps or shared
storage. We only need them to be unlocked; we don't need them to
be actually running.
Have PackageManager dump the set of volumes that it's finished
scanning and loading, since otherwise CTS can get excited and race
too far ahead of it. Add a specific error code to communicate
that users are locked.
Test: cts-tradefed run commandAndExit cts-dev --abi armeabi-v7a -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Bug: 37436961, 29923055, 25861755, 30230655
Change-Id: I749dc3d8148e1a95d8bc4be56665253ef826d3fe
Add a new flag in the DevicePolicyManager so that we can Use
EuiccManager#eraseSubscriptions(PendingIntent) to erase all the carrier data
from eUICC chip if the user choose to "ERASE" from the Android device manager.
Bug: 37277944
Test: E2E
Change-Id: Ia78090a00d956c645725be4fd591e02ded8ec467
Bug: 29875093
Test: Run dumpsys meminfo -a, verify SwapPss adds up and is non-zero
for dalvik and native.
Change-Id: I79d0b6a59bf5f4e73f75f0b9540ec0fcc9e23b02
There are a few AIDL-generated stubs that perform "destroy"
transactions and call "this.destroy()". Previously, this
resolved to the "destroy()" method from their interface on
ART while resolving to Binder.destroy() on the RI, though
this is a subject of a bug report against the JDK,
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021581 .
Resolving to the private Binder.destroy, inaccessible to
the Stub, would lead to throwing IllegalAccessErrror.
As we're changing the method lookup to be closer to RI, see
https://android-review.googlesource.com/413119 ,
we should stay clear of the problematic cases whether we
make a decision to follow the RI precisely or not. Therefore
we rename the Binder.destroy() to Binder.destroyBinder().
Test: Nexus 6P boots.
Bug: 62855082
Change-Id: I43baf76b6f3c681d93b411cecf2bc00fccafecac
Causes too many GCs and related slowdowns.
Verified that assistant launch from holding down home button is now
faster than N.
Test: make and flash
Bug: 62769566
Change-Id: Ib0c1f7a45831b241d3376d1e56db3c6937913b1b
...background processes (CPU, etc)
Add full configuration params for adjusting these settings (some were
already there).
Also... as long as we are doing this...
- Get rid of all of the wakelock stuff. That is completely pointless
now that we aren't even allowing cached processes to hold wake locks.
- This greatly simplifies the code, since we don't need to deal with
two different policies for how we do checks. Instead, we just regularly
check for CPU and the CPU check interval.
- And make the CPU check more aggressive and have much more flexibility
for tuning: there are now 4 different maximum CPU use levels, depending
on how long the process has been in the cached state. This allows us to
be more strict on CPU use the longer it is sitting in the background.
Note that CPU use tracking only happens while the device is not
plugged in to power... I'll leave this for now, but I think in the
future we should think about applying these limits even when plugged
in, because in either case cached apps should really not be doing
much.
Test: manual
Change-Id: I68f4ab68be5f7d5fc4822005107fb60ef07a374d
Wrong description of the "tid" parameter used by getThreadPriority():
the function does not "change" the priority of the thread associated to
"tid".
Defined also the meaning of setting tid parameter to 0.
Test: None
Change-Id: I8552f3b110eaab1aefa51477e82d3e295547be34
Signed-off-by: Alessio Balsini <alessio.balsini@gmail.com>
...can't hide themselves
Tune the policies for when we tell about apps running in the
background after their services have stopped.
- If it ran while the screen was on, the time we require for it
to be running is much shorter (a couple seconds) as well as the
time we tell about it having run (with another tunable for the
minimum time we tell about this).
- If it has only run while the screen is off and stops a sufficient
amount of time before the screen goes on (currently a second) then
we will not show anything when the screen goes on.
- If it stops when the screen turns on, we will make sure the user
sees about it for a short period of time (currently 5 seconds).
Also includes some improved debug output about handler message
queues.
Test: manual
Change-Id: Iab438410d7182b2dfe4f9c1cce7069b26b34834c
