Framework: StatusBar Ticker (1/2)

Change-Id: I6135297792c7b42172e08e14acd37b252cb00102
Framework: Don't collapse if showing quicksettings

Don't collapse panels if quicksettings are showing
	and notifications are cleared

Change-Id: Ifbf18bd82986634db3331f08f6f3cc55e045683c
Framework: Don't needlessly create shared pref objects

Only one tile is using this.  Create it in that tile.

Change-Id: I67e5dff8f635da212da86a4048eac0da54fcc624
Replacing FloatMath native implementation with calls to Math

On modern versions of Android running in AOT mode
FloatMath is slower than Math. Calls to Math.sqrt(),
etc. are replaced by intrinsics which can be as small
as a single CPU opcode.

When running in interpreted mode the new
implementation is unfortunately slower, but I'm
judging this acceptable and likely to be improved
over time. This change saves a small amount of native
code.

Example timings:

Mako AOSP AOT:

Method: Original / New / Direct call to Math
ceil: 596ns / 146.ns / 111ns
sqrt: 694ns / 56ns / 25ns

Mako AOSP interpreted:

Method: Original / New / Direct call to Math
ceil: 1900ns / 2307ns / 1485ns
sqrt: 1998ns / 2603ns / 1788ns

Other calls Mako AOT:

Method: Original / New
cos: 635ns / 270ns
exp: 566ns / 324ns
floor: 604ns / 150ns
hypot: 631ns / 232ns
pow: 936ns / 643ns
sin: 641ns / 299ns

The advice to use Math directly, in preference to
FloatMath, is still good. FloatMath will be deprecated
separately.

Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: If07fcbd78543d13bc6d75f9743f999860e8d58d7

Conflicts:
	core/jni/AndroidRuntime.cpp
Switch from FloatMath -> Math and Math.hypot where possible

The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.

That said...

Math is faster than FloatMath with AOT compilation.

While making the change, occurances of:

{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))

have been replaced with:

{(float)} Math.hypot(x, y)

Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:

Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().

hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.

Different implementations measured on hammerhead / L:

AOT compiled:

[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials

[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials

[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials

[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials

[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials

[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials

Interpreter:

benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials

Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
Replacing FloatMath native implementation with calls to Math

On modern versions of Android running in AOT mode
FloatMath is slower than Math. Calls to Math.sqrt(),
etc. are replaced by intrinsics which can be as small
as a single CPU opcode.

When running in interpreted mode the new
implementation is unfortunately slower, but I'm
judging this acceptable and likely to be improved
over time. This change saves a small amount of native
code.

Example timings:

Mako AOSP AOT:

Method: Original / New / Direct call to Math
ceil: 596ns / 146.ns / 111ns
sqrt: 694ns / 56ns / 25ns

Mako AOSP interpreted:

Method: Original / New / Direct call to Math
ceil: 1900ns / 2307ns / 1485ns
sqrt: 1998ns / 2603ns / 1788ns

Other calls Mako AOT:

Method: Original / New
cos: 635ns / 270ns
exp: 566ns / 324ns
floor: 604ns / 150ns
hypot: 631ns / 232ns
pow: 936ns / 643ns
sin: 641ns / 299ns

The advice to use Math directly, in preference to
FloatMath, is still good. FloatMath will be deprecated
separately.

Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: If07fcbd78543d13bc6d75f9743f999860e8d58d7

Conflicts:
	core/jni/AndroidRuntime.cpp
Framework: Enable Speaker on Proximity (1/3)

Change-Id: Ie3271d56b7ed6b1201e13ad3ff7a83ece181cf12
Telephony: fix tdsdma asu invalid value

The magic value for invalid asu is "99", not "255". This error is causing the value validity checks to fail incorrectly, fixit.

Change-Id: Ief816eb577ccf371b3c85df1fe9515eb0bfb3f06
Telephony: Set the value of min match according to one property

CTA requires to match 11 phone numbers, so use the value of the property
"persist.env.c.phone.matchnum" to set it 11 in case of CTA tests, but by
default it is 7 without change.

Change-Id: I8cd4105c06c71af1ad242858d8de474459d96ee1
framework:Thread synchronization for UI update

Issue : Framework reboot was observed due to out of sync between
        two threads which inturn causes Null pointer exception
        while updating airplanemode.
Fix : Handled Null pointer exception and the crash is not observed.
CRs-Fixed: 570122

Change-Id: I2e969f6e7726ffcf8648b366ebb54cb2b0afc292
PowerMenu: Fix framework reboot on long pressing power button

Change-Id: Idcf9c82766546150f14ee47b94de7970213cd939