Lockscreen : Fix widgets disabled

Currently, when keyguard widgets are disabled via the DevicePolicyManager,
a default widget if specified via widget_default_package_name/widget_default_class_name
is added on the main screen, and if not successful the default status widget is added.

However in its current state, each cycle of the lockscreen alternates between the two widgets.
Reason is, the default app widget is constantly recycled on screen power cycles, and in such events,
when checkAppWidgetConsistency() fails to add the widget (since the id is no longer valid), it toggles
back to the default status widget, and resets the stored id. Next cycle a new id is allocated and it works
and so on ...

This patchset addresses this issue by not removing the default status widget if not necessary, hence
preserving its id and fixing the toggling issue.

Change-Id: I6b21d18346fed5accc72141097939c92ee9aaa3c
Don't include flags in configuration change if their value hasn't changed.

This makes the check in updateFrom() match the logic in diff().

Change-Id: I3ab4e8460f7fbf985ef55b9514a8aa90d401d486
Allow creating custom dialogs in DialogPreference.

This allows creating non-AlertDialogs while still using the click and
state handling of DialogPreference.

Change-Id: I54fd7d6d6b9f6a49fef1ae95e0178838b3edfa56
Don't start keyguard in an attempt to exit it.

exitKeyguardSecurely() will open the keyguard if it's currently disabled
by an app. As this is unwanted here (the user has either already
bypassed the keyguard or the keyguard isn't secure; otherwise he
couldn't click on a notification entry) and as the lockscreen already is
dismissed a few lines above, don't call exitKeyguardSecurely here.

Change-Id: I5582da350d8826e42f9edcd56845a59965865c8b
JIRA:CYAN-99
Don't let apps disable the SIM PIN entry screen.

As the user (who controls the app behaviour after all) likely doesn't
see the PIN screen as a lock screen (he likely wants telephony) and the
PIN screen is not shown on a timer-driven basis, it should be treated
specially.

Change-Id: I3572a80d4a515d72e3aa4a6e933e980fa4516c2b
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.

Change-Id: I093227f539050a6bad8e6e8d9f533eff7bddd0d6
Properly handle changes in phone audio focus.

Change-Id: I921651684f4369a47aa83e93010266c40be71a41