When using a reference-counted wakelock together with a timeout, we
can end up with an over-released wakelock which causes an app crash.
To mitigate this, only throw based on count of external
acquire/release events.
Bug: 62326550
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.PowerManager_WakeLockTest
Change-Id: I66480cb9798f9404ae3d45a70d68eae136d289de
When we have trouble pushing a saved instance state Bundle out of
a process, log high-level statistics to help narrow down where bloat
is coming from.
Bug: 62409379
Test: builds, boots, stats logged
Change-Id: Iaff01eaf31ff0fd4d0fde3da15e9526dac559af9
Before this change, ZygoteProcess.preloadPackageForAbi returned
as soon as the command was written to the zygote socket and not
after the preload completed. This meant that there was a small
window of time before the server side of the socket polled its FDs
where a second command could be written to the zygote socket. This
would lead to only one of the commands being processed and the
other being dropped. The client side of that socket would then wait
forever for a response and bring down the system once the watchdog
timeout was hit.
Example failure case :
--------------
system_server：send command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(preloadPackage) // the fork command is dropped.
Example of normal operation :
------------------
system_server：send command(preloadPackage)
zygote：poll & process command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(fork)
This change makes preloadPackageForAbi synchronous, which ensures
that each POLLIN event corresponds to precisely one command.
Bug: 62886909
Bug: 13618569
Test: Manual
Contributed-By: yuqianyu@huawei.com
Change-Id: I83faf974c9a70a6ab18323f692c1981784e4c56a
In both battery stats and job scheduler statistics, keep track of
the reason jobs are ending. This can help to identify apps that
are having bad behavior with jobs (in particular, regularly timing
out their job instead of finishing it when done).
Test: manual
Change-Id: Icc12d5e0dc0df1906716e7d995c56d50a9fa148a
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>
