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
We normally prevent apps from allocating into the "reserved" cache
space, but this change makes an exception for an active camera app,
since the user is probably trying to capture an important memory.
This change only lets the active camera app clear up to half of the
reserved space, since we don't want to completely destroy the
experience of all other apps.
Test: manual app before/during/after active camera session
Bug: 38267830
Change-Id: Ie9e63884fb2638ca881e10b894629eea84601648
Create a BatteryStatsWorker that internalizes the stats collection,
and returns a Future<?> so that uses-cases requiring synchronous
results can still wait on the async task.
Bug: 37645919
Bug: 38296815
Test: manual
Change-Id: I5b935e1877d9a17d2617f01478faa77e8a52a258
It has been discovered that for background values of
AggregatedWakelock, Sync, Job, and partial wakelocks,
the value of getTotalTimeLocked is wrong and often very
negative. getTotalDurationMsLocked, which should provide the exact same
value in all of these cases (since background data is never pooled),
does not have this problem. So while the source of the bug is sought
out, we should use getTotalDurationMsLocked instead of getTotalTimeLocked for
these data.
Bug: 62352334
Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest
Change-Id: I78e84368615578483ab8e9e5f0ee1d067491be08
This forces everyone to go through sdcardfs, instead of letting them
around the back door.
Test: builds, boots
Bug: 38231314, 27992761
Change-Id: I97b24d25599c7f86f9b535689e2f4ecf68261dac
