Fix flickering music control widget under certain conditions.

In case the active audio player abandons audio focus while the playback
state is still set to 'playing', the transport control can start
flickering in the keyguard.
In that case, the transport control is removed from the keyguard host
because it has no listener anymore, but later is re-added due to
isMusicPlaying() still returning true. Re-adding it leads to it
re-registering with audio service, which clears the display due to
nothing being connected, which leads to the detachment listener being
called again, which in turn closes the loop.

While this may be a sign of a buggy player app (it should stop its
playback prior to abandoning audio focus), this situation still should
be handled gracefully. Fix the problem by simply reporting no music
being played while no remote control client is connected.

Change-Id: Id6834d38bc6faa3b6455ac66b413443f85606785
Speed up notification pullup & pulldown

based on an idea by Mr.Nigma @xda:
http://forum.xda-developers.com/showthread.php?t=2267307

Change-Id: I61213058b5cedddf90e974713af05c038e3af039
Frameworks: a bit taste of android 4.3

most changes are under seems to be under the hood and are
not mergeable due that we have no code...... UI changes
are minor....but our lovely Roboto font is pimped up on the
new android version. So here we go

cheers

Change-Id: I139bcdeaefe5125ba8974fc88423c62d62b1b429
increase touch sensitivity

Change-Id: I77e6aeca3667808e630dc142a2e561d3ddddef80
Fix infinite recursive loop

There is an apparent recursive loop at IntProperty.java
in method set(Object, Integer)

This method unconditionally invokes itself. This would seem
to indicate an infinite recursive loop that will result in a stack overflow.

This was brought over from out original JB branch.  Somehow, this got
overlooked, and never made it into JB42.

Change-Id: I344f7d774d4a9c688dda1e10f796def0f503d037
Another optimization of glyph cache uploads

Previously, cache textures were updated whenever mCurrentCacheTexuture was changed.
Since updating cache textures needs glTexSubImage2D call, frequent changing
of mCurrentCacheTexture (which can easily happen when an app uses lots of unique glyphs
even with precaching) caused many glTexSubImage2D calls and bad framerates.
This patch optimized isssueDrawCommand function. Consequently, changing mCurrentCacheTexture doesn't
cause glTexSubImage2D call any more and it will improve font rendering performance.

Change-Id: Id19d959fa0e69eeb2a39f83a57e311d7394586b2
Signed-off-by: Sangkyu Lee <geteuid@gmail.com>
A tiny optimalization

Change-Id: Ib2cb773ffe5cb579c2b46bd0e6a5a3f2c55d190d
New clear all recent apps, icons, cause it looks better.
Decrease lag generated by autorotation on

There are different issues from what I understand:

1) Discarding of events too close to each others is broken
as mAccelerationTimestampNanos is conditionned by isAccelerating()
on TF101 no events are discarded anymore, and so it creates an update every ~50ms
filing up the android notification message queue quite a bit for nothing and so generating lag.
2) isAccelerating seems incorrect to me too, the code means more that it's accelerating "out of range" and should be discarded in that case.

=> Discard the sample if outOfRange and don't condition the update of mAccelerationTimestampNanos that way next time we come back "too soon"
the sample will be properly discarded.

3) with events being discarded properly on the WindowOrientationListener
the SensorManager can now update every 20ms instead of 50ms
but that is definitely overkill.
=> add SystemProperty sensor.loop.minms with a default value of 50ms to throttle the notifications.
That way the thread sleeps properly instead of sending events as fast as it can.

(increasing up to 100ms can be ok depending if you want faster response or not.)
This can be positionned on a per device prop too.

4) Add 2 SystemProperties:
one on the SystemSensor side: sensor.magnitude.threshold with a default 0 value(doesn't change the behavior)
one on the WindowOrientationListener: orientation.magnitude.threshold with a 200 (0.2G) default value
These allows to discard the sample if it is too close to STANDARD_GRAVITY (ie not accelerating much)
These can be set on a per device or use the default values.
On the TF101 200 works most of the time. But weirdly when docked the reported gravity seems to have an additionnal offsert of -0.2
maybe some magnetic interference from the dock...

For the moment the 0.2G threshold is positionned on the Orientation code.
Once the cpp sensor poll crazy loop is solved it could be better to use the sensor.magnitude.threshold instead.

That should take care of most of the lag generated by autorotation.

PatchSet2: position default SystemProperties values to do nothing.

Change-Id: I093227f539050a6bad8e6e8d9f533eff7bddd0d6
bootanimation: performance enhancements

This patch implements two simple performance enhancements, which
might benefit devices. They are completely opt-in by setting
the following variables.

  * TARGET_BOOTANIMATION_PRELOAD: will preload the bootanimation
    zip to memory; this is handy on devices where the storage
    might be slow. By preloading it, we get quick access to the
    zip file, and the animation doesn't stutter.

  * TARGET_BOOTANIMATION_TEXTURE_CACHE: allows maintainers to
    force texture cache on/off.

Also fixes the sign warnings related to int / size_t comparison

Change-Id: Ie92d1b0aa90b43ba39c368a2a33657a60c3a64b5
remove leak WaitResult List in startActivityMayWait

Change-Id: If169ef4474a6a38eb2957c806c6e7f8f7ce67783
Signed-off-by: Young-ho Cha <ganadist@gmail.com>