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.
fix notification icons not animating until ticker updates

Change-Id: I0d1cfbcab7a4ccdbf2b6f72d81ff736496979606
fix memory leak in WebViewCore

Change-Id: Ie73d61d7273fd66fb994c0c795ef06396f007631
Allow swiping between notifications and quicksettings screens.

CS3: fix whitespace

Change-Id: If6f28de0bed5d3ffacf1fd7df6763b200d53dddd

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/NotificationPanelView.java
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
improve swipe between pull down animation

this greatly improves both animation and function of swipe between screens
it allows for a hold on the animation and also freezes the notification panel
to do: add fling animation so it keeps spinning?

Change-Id: I04c4332d6f3678eb331f52d90e0db4c3fe414454

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/NotificationPanelView.java
remove leak WaitResult List in startActivityMayWait

Change-Id: If169ef4474a6a38eb2957c806c6e7f8f7ce67783
Signed-off-by: Young-ho Cha <ganadist@gmail.com>
Track stack memory in MemoryInfo.

In /proc/pid/maps the main stack is identified as "[stack]". In Linux 3.4
thread stacks are identified as "[stack:<tid>]" where <tid> is the thread ID of
the thread using that stack. Add support in MemInfo's otherStats to track
memory being used by the stack.

Add sanity check on the length of the otherStats array.
Add detail messages to two null pointer exceptions.

Bug: 8265251

Change-Id: I2b228b147da9bdc5c7a4d825dfc628fcc7923927
Fix a programmatic smooth scroll bug

Bug: smoothScrollToPosition() stops at child view of which height is
higher than list view itself.

Change-Id: I695ca9db4c706aa7f365967dd3916f9a01917346
Signed-off-by: Yongyi Li <yongyi.li.cn@gmail.com>
Remove the fixed-length buffer in DdmHandleNativeHeap.getLeakInfo.

It was possible to overrun this buffer, and even if you did fill
the buffer in a single read and exit the loop, the "string" still
wouldn't be terminated.

Bug: 8468088
Change-Id: Ia19f4d26dfd79e7b63807a7ec9540b932163d246
Framework/base: Added synchronization block to avoid race condition

Fix for the synchronization issue leading to access of an array
Index out of bounds. Issue occurs due to race condition between
removing the activities of a crashed process from history stack
and resuming a separate activity.

Change-Id: I14bb5834e778c15b674248e46fe93b0ce9f37967