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
The AudioFocus death handler was correctly updating the audio
focus stack when an audio focus client dies, but the death handler
was leaking GREF if unlinkToDeath() is not called.
The fix consists in making sure unlinkToDeath() is always called
by calling it in its finalizer.
Change-Id: I0c5343b4986ab582cadbf171fc53816952dc16f5
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
Revert "Fix bug #5387832 [UI/Visual] Address of the website is not displayed properly(second line of the address is partly shown)"
This reverts commit caa8c06de5f94db69faca35d666c04b82d3f420b
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
This change adds the ANDROID suffix to the all the types and functions
defined by the EGL_ANDROID_blob_cache extension.
Change-Id: I087875b96d9a7053efb9c8d5614f9f765eed799d
* 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
