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
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
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
Drive the menu button off of the currently focused window. That is, after all,
the one that is going to receive the menu key event.
Change-Id: I61cac1e274602e5ea53402ab15bd63a9cd89e9cd
When encountering non-monotonic stats rows, recover remaining data by
clamping to 0. In particular, this avoids edge-case where persisting
threshold checks would never trigger. Also recover when tethering
snapshots are missing.
Bug: 5600785, 5433871, 5600678
Change-Id: I1871954ce3955cc4ac8846f9841bae0066176ffe
LayoutTransition was making an incorrect assumption that there could
only be one transition animation on a child of a transitioning container.
But if multiple children are added/removed to/from that container, there would
be multiple calls to set up changing animations for each existing child
of that container. This meant that the child would have multiple, new
OnLayoutChangeListeners added to it as part of the setup process.
Meanwhile, we would cache only the latest listener in a hashmap that used
the child as a key for the listener. Then when we cleaned up the hashmap later,
we would remove only the latest listener from the child, leaving the rest there
for eternity.
The fix is to skip the setup entirely for children that already have listeners
set on them; they must, if that's the case, already have been set up and are
already listening for layout changes. Setting up the animation is redundant,
and adding another listener is a leak.
issue #5588509: memory leak in systemui
Change-Id: Ie2192593d84702be7243c18760dfdb3a027b761c
Bug: 5601629
References tend to always be equal to the things they are referencing,
use copies instead.
Change-Id: I0827878e91ef1fa6e0abe2d6499d55f4a211d890
A build with the wimax network type defined but wimax disabled
causes an NPE in ConnectivityService's constructor.
bug:5237167
Change-Id: I929eac217e1afa0e61346fdbc3e96a7d3ad09a54
LayoutTransition was making an incorrect assumption that there could
only be one transition animation on a child of a transitioning container.
But if multiple children are added/removed to/from that container, there would
be multiple calls to set up changing animations for each existing child
of that container. This meant that the child would have multiple, new
OnLayoutChangeListeners added to it as part of the setup process.
Meanwhile, we would cache only the latest listener in a hashmap that used
the child as a key for the listener. Then when we cleaned up the hashmap later,
we would remove only the latest listener from the child, leaving the rest there
for eternity.
The fix is to skip the setup entirely for children that already have listeners
set on them; they must, if that's the case, already have been set up and are
already listening for layout changes. Setting up the animation is redundant,
and adding another listener is a leak.
issue #5588509: memory leak in systemui
Change-Id: I2c9f312cc2bcf4f2d08ac6b5d8f8e495aa4f3597
-> On the Xoom, this change gets us back up to 60 fps. The
change is really more of a workaround for the fact that we don't
have vsync, and we ought to be able to change it back once we do.
Change-Id: I80888f18887bf5f2fed72c19641ed430ef6dbfcf
This does not happen on high end gfx devices. This happens
only if only one EGL context is initialized in the current
process.
Change-Id: Ibd1737efdf84eef8a84108b05795440d1ae9964e