Allow the NFC process to call Bluetooth APIs.

The NFC process used to be only running as user 0,
and it may be calling into Bluetooth. Most of the
handover code has now moved to a separate process
running as the current user.

Fix the existing checks to take into account the
correct NFC UID, whatever user it is running as.

Bug: 7309141
Change-Id: I953cfb263a28aef7fe1be5880b053425dc359a29
Fix multiuser bug in StatusBarManagerService.

First, do no harm.

Bug:7638210
Change-Id: I113b574a021d601b0c79d65a3b4b72eeb4c667ad
Fix issue #7585876: When changing the font settings, the movie...

...just keeps attempting to load and doesn't play on the TV

Change-Id: Ifcdc969a037a113224632f907d55f60a168dd05a
Only show "charging" if the battery is really charging.

If there's a charge problem (battery health/temperature out
of spec, or low charging current), the lockscreen and status
bar should not indicate that charging is occurring.

(Previously we showed "Charging" and a lightning bolt any
time the device was plugged in.)

Bug: 7509976
Change-Id: I27ec0e2cec1307fbc6ef262dd5181a4db6d3bed0
Add constant for Daydream settings.

Bug: 7480927
Change-Id: I383170c6c543b5ffe81568d273389585498d369b
trigger kernel blocked stack trace on system server watchdog

Bug b/7638530 may be caused by a kernel deadlock when killing
processes under low memory conditions.  Write to /proc/sysrq-trigger
to get a kernel log of blocked tasks before killing the system server.

Bug: 7638530
Change-Id: I60df324ad4affdadbf13650099dc4dfb38722420
Remove unused IExtendedNetworkService

It was used in the cupcake era for docomo.  Is not used anymore.

Bug 7633569

Change-Id: I2ec826fc9a70d261a340957a937ed4c9f8e67c5c
Saving and restoring current page when rotating in lockscreen. (Bug 7568412)

Change-Id: Ia80845d05df04dc2d31a834279096e5ed165a646
Disable adding keyguard widgets until setup is done

Bug: 7504154

Change-Id: I865f0139bb328e6b9b19493e0d8f9f086e2ebc38
Suppress quick settings if setup has not been completed.

The button was already hidden, but there are lots of other
ways to get into QS that should check for USER_SETUP.

Bug: 7638795
Change-Id: Ib6c48fc02e833670768e7dc76e25c38097b88c18
Always report user switched after unfreezing screen.

Change-Id: I58172896892a07e72a3430e56e4d2944d388c7c9
 BluetoothManagerService call should allow SYSTEM_UID

bug 7561429

Change-Id: I1483bfe1361f71c7ae3529ea496b33504b95413e
Maybe fix issue #7596986: Frequent runtime restarts; IAE at...

...android.os.Parcel.nativeAppendFrom(Native Method)

The failing stack trace is:

11-20 20:29:04.365 19154 19170 E AndroidRuntime: java.lang.IllegalArgumentException
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.nativeAppendFrom(Native Method)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.appendFrom(Parcel.java:428)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Bundle.writeToParcel(Bundle.java:1613)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.content.Intent.writeToParcel(Intent.java:6660)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:763)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:230)
11-20 20:29:04.365 19154 19170 E AndroidRuntime:        at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:777)

This is odd because where we do Bundle.writeToParcel(), we are just writing the Parcel
we have with its current length.  There is no way this should be able to fail like this...
unless the Bundle is changed while we are running?

Hm.

It looks like the location manager is holding on to Location objects which have a
Bundle of extras.  It is that Bundle of extras that the crash is happening on.
And the bundle extras can be changed as it operates.  And there are places where
the raw Location object is returned from the location manager, which means the
caller can be olding on to a Location object whose extras can be changed at any
time by other threads in the location manager.

So that seem suspicious.

This change should take care of all these places in the location manager, by
making sure to copy the location object before it goes out of the location
manager.

In addition, add some code to the activity manager to not bring down the entire
system if there is a problem trying to send one of these broadcasts.  There is
no need, we can just skip the broadcast as bad.

Change-Id: I3043c1e06f9d2931a367f831b6a970d71b0d0621
AudioService: improve initial safe volume delay

AudioService relies on a valid mmc in order to enforce the headset
volume limitation or not. There is a timeout to enforce the limitation
if no mcc is configured after boot.
Until this timeout is reached or a valid SIM is detected the headset
volume is not limited.

This change makes that the last known volume limitation state (enforced or
not) is persisted so that next time we boot, last known state is applied until
a new mcc is configured if any. In most cases, the mcc does not change from one
boot to the next and we do the right thing. If teh mcc does change, the correct
policy will be enforced when the mcc is detected or after the timeout.

Also fix a bug where the volume panel was not displayed if the limitation mechanism
is triggered at the first press on VOL+ key.

Bug 7455275.

Change-Id: Id0f2996d893d38c6a14f4f9e4a0e9e3be17ef127
Don't apply transformation fudge when not rotating.

There is this stupid fudge factor applied to window transformations
when doing a screen rotation animation.  We need this when rotating,
but when not rotating it causes very visible artifacts.  Historically
the non-rotation case only happened due to configuration changes, so
wasn't that big a deal.  Now however that we use this when switching
users, it is more annoying.  So get rid of it for such cases.

Change-Id: I6b343866c1bad9b16984b4a629917c2f1bb37b9e
Clean up debug messages

bug 7626174

Change-Id: I65cdcaf2c48a78468b6cef0b8591289435068b24
Only show camera widget to setup users.

And remove misspelled and unused field in KeyguardHostView.

Bug:7645811
Change-Id: I3d6ceae8d25d0af7b504b4c22782611d25462a62
Reduce false swipe-closed gestures in status bar panels.

VelocityTracker is a powerful tool---too powerful, in this
case, because many devices (I'm looking at you, Nexus 7)
have touchscreens that report total garbage on takeoff and
landing.

PanelView now uses its own incredibly crude velocity tracker
called FlingTracker, which implements a short sliding window
of the last 8 motion events (7 intervals) over which touch
velocity is averaged. There's also a little bias toward more
recent touch events so that the overall velocity of small
circular gestures will tend to favor the exit tangent.

The end result is a primitive low-pass filter on touch
velocity that should help us avoid situations where one (or
even two!) stray MotionEvents at the end of a gesture won't
invalidate the overall thrust.

Bug: 7422342
Change-Id: Idae38d1957727e400493324af4eee357ba5baa27
Fix sample code issues

Correct min SDK.
Correct file extension on mandelbrot

Change-Id: I508c22c382f1a930b27d8c5f4414cac3a990a332
Fix rounding error when drawing panel handles.

Bug: 7649037
Change-Id: If8d9fa5f3852729207c31c95cfd68ef54ff47d7d