* commit '6200a4b7eb07507055af93ec1a054640a39b9751':
DO NOT MERGE Cherry pick from ics-mr1 - Bug 5275928 - Don't try to open an overflow menu under invalid circumstances.
When audio effects are enabled, a noise can be heard at the
beginning of the new song when skipping to next song in music app.
This is because some effects (especially virtualizer) have a tail.
This tail was not played when previous song was stopped because effects were
not processed when no tracks were present on a given session. This is to
reduce CPU load when effects are enabled but no audio is playing.
The tail was then rendered when the new song was started.
Added a delay before stopping effect process after all tracks have been removed from a session.
Issue 5584880.
Change-Id: I815e0f7441f9302e8dfe413dc269a94e4cc6fd95
Traceview showed approximately 10% of total parse time inside the
synthetic 'trampoline' methods generated to provide inner classes
with access to their outer class's private fields. The bottleneck
in this particular case is in XmlBlock and its inner class Parser.
Making the bottlneck outer-class members and methods package-scope
instead of private removes that 10% overhead being spent within
these access trampolines.
Traceview tends to overemphasize the significance of very small
methods such as these trampolines. That said, the measured speed
gain on the ParseLargeXmlResFg op due to this patch is between
5% and 6%.
Change-Id: Ia0e3ae5408d1f9992b46e6e30dd2407090379b07
We were not passing the length of the UTF-16 string to
String16::setTo. As a result, it was copying the contents of
the text up to the first null it found.
First problem, these strings are not typically null terminated!
Second problem, if the string contained a null character, then
we might truncate it. However, we only truncated the string
when the copy constructor was invoked (say, when we called
get() on the cache) but not in internalTextCopy() (before
adding the key to the cache).
As a result of the second problem, we would first search
the cache for a key that matched a partially copied truncated
string (potentially reading uninitialized memory that followed it).
Finding none, we would add the entry to the cache using
the correct key.
If the cache already had a value associated with the correct key,
then the put would fail, returning false. Charging ever onwards,
we would add the size of the entry to the cache size.
Proceeding in this manner, it was possible for the cache to
believe it had less remaining space than it really did. At that
point, it was possible for the cache to evict all entries and
yet still not think it had room to add a new one, so it would
continue trying to make space indefinitely.
Bug: 5576812
Change-Id: I05251594f6b2da0a5dc09f7200f04fe9100ec766
This came up from bug #5601885: Memory increase (leak?) in system_server
Stingray MR1
This isn't *really* a leak in the system process -- it is a leak in an
application process that is causing the system process to keep around
a bunch of ActivityRecord objects longer than it should, until that app
process is ultimately killed.
Unfortunately these days leaking an ActivityRecord also often means
leaking a thumbnail, which is a big slab of memory.
So make the activity manager better about this, using a weak reference
from the handle the object has so we can still clean away most of the
state associated with the ActivityRecord even if the client side leaks
its own reference.
Change-Id: Idbab45e09749cdfb54899203da7981e7b3576e25
* Don't call context.getResources() redundantly when unnecessary;
similarly for Resources.getCompatibilityInfo()
* During bitmap creation, don't bother clearing to 0: it's unnecessary
because now that the raw bits are stored in a VM-side byte array, it
was cleared at initialization time. Also, don't use the sanity-
checking public entry point to erase to a color, because we know
that we're by definition in a "legal" path to erase to the initial
contents and don't need to incur the overhead of the (inappropriate)
sanity checking.
Change-Id: Idaca4d64fdecefd5d51337646ead32e1db510e02
...LoadedApk.ServiceDispatcher.connected , LoadedApk.forgetServiceDispatcher
Don't be stupid if we receive a new binding to a ServiceConnection after it
has already been unbound.
Change-Id: I85a49de97372bf9af55542a89031f0b7a2ac8fbb
Send CONNECT_OTHER_PROFILE to Device profile for low priority hfp and a2dp
incoming connect. In the case when HFP autoconnect is off but a2dp autoconnect
is on, if HF autoconnect to HFP, phone will reject HFP but connect a2dp.
Before this fix, phone reject HFP. A2dp will not get connected unless the HF do
media auto-connect, which most carkits do not do.
Also do similar change for incoming a2dp connection
bug 5091838
Change-Id: Ife1815f527bcd94e0d9ffc645028484fa9c49a43
When destroy is called shortly after creation, RS tries to set a surface on a partially destroyed context.
Change-Id: I7a382a701efde3264e5cd9b9a9b428ade5eb4a9a
If it's configured with a defined network but can't create a network state tracker
for it, it would NPE and restart the framework whenever a default network
disconnects.
bug:5603268
Change-Id: I816c4f522d766e0353a713623f6635b03395b01e
The package name is now required when using the
NFC extras APIs so the context is stored away
and used to derive the package name to be sent
to the NfcService.
Bug: 4515759
Change-Id: I1a3aba3fc026e0090a914b0686fc4b8dec25b927
