The existing action bar overlay decor layouts hit a case in
RelativeLayout that causes two measure passes for the main content. As
this can be expensive, stick the bar and the content overlay into
their own sub-layout and switch things to use a FrameLayout at the top
level instead.
Be explicit about the layout_width/height on ActionBar-containing
decor layouts as the older decor layouts are.
Change-Id: I4330f0f25841dd8058b94a320f93bf67fb56bf17
The new NFC Extras access control allows us to run these tests
without a vendor specific certificate.
Change-Id: I9425e08e557214cf6a74276622402c5682bbaef4
This fixes a bug where NfcExecutionEnvironment.close() would NPE
if you called it on a different EE to the one you opened. We now
always return the same EE in the same contet.
Change-Id: I949998dc2ee738527ee281cae46ae50ea6950a2c
This updated tablet layouts to support showing album art and transport
control views in PIN, pattern and password screens of lock screen.
It also allows the addition of a background protect asset and
the ability to show the system wallpaper on layouts that define a
transport_bg_protect view.
Also updated layout to use new ICS-style buttons on lock screen and
fixed bug with "forgot pattern" button where we were showing the
emergency call icon.
To avoid problems with leading ones in the mono-space clock font,
we now right-justify status text on tablet and remove the AM/PM
indicator.
Status font size adjusted by UX.
Added background protection drop shadow to transport control.
Fixed portrait mode to be right-justified when transport is showing.
Change-Id: I790292fc39f4588f87adc9d9241706817ae6baab
Showing a congratulations screen after choosing face unlock backup lock
Once a backup lock has been chosen, it sends an intent to show a
congratulations screen. The moveTempGallery function has been moved
inside this new activity so it is no longer needed in LockPatternUtils.
Change-Id: I66868e6e3391b8b740f618fe633047ce388f55ca
-add videoeditor maximum prefetch YUV frames in media_profiles.xml to limit the total memory usage.
Change-Id: I41ffbc192fcce4c7635e5b0a1f2835852e5ee509
* commit '6200a4b7eb07507055af93ec1a054640a39b9751':
DO NOT MERGE Cherry pick from ics-mr1 - Bug 5275928 - Don't try to open an overflow menu under invalid circumstances.
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
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
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
