frameworks: add alwaysRequestAudioFocusForCalls overlay

Change-Id: I0e3e5dd0741d295cdb6cbb0867f19a83c3363dc5
Signed-off-by: Roman Birg <roman@cyngn.com>
Remove Application Widget from LockPatternUtils

The application widget option has been removed from Settings, and should
instead be handled by the application granted with the
SET_APPLICATION_WIDGET permission.

This change:
- removes the configuration value from the LockScreenSettings database; and
- removes the producers and consumers of the value.

Change-Id: Ia83e8d713d4455a9c898a8048a256afb7291af0b
SettingsProvider : Add ability to override default volumes

Change-Id: I5e1a5e5a7e872f9ead1700af0da09a3f2efd6e84
Installer: Use nanoTime instead of currentTimeMillis

It is possible for the Installer to timeout even though the elapsed
time of 100,000 ms has not elapsed.  This can happen if the system
clock changes while we are running something from the Installer.

The documentation says not to use currentTimeMillis for determining
timeouts and recommends using nanoTime() instead.

Change-Id: I376d5b0fad8eefcdeabbb7ed89ebd3d1d3c96ba0
Change permission guard on bindBackupAgent()

Bug: 15829193
Change-Id: I6c1c39923b7b1a9f528f97da10913cb7f2d7e8f9
Fix issue #16794553: Duplicate ArrayMap entries in Bundle...

...can lead to launching of un-exported activities

We now validate the array map after unparcelling to make sure there
are no duplicate keys.

And to make up for the performance overhead this introduces, I switched
the parcelling/unparcelling code to write keys as explicit string
objects rather than generic values.  There was no reason to use generic
values since the write method itself only accepts an array map with
String keys.

Change-Id: I57bda9eb79ceaaa9c1b94ad49d9e462b52102149
Do not persist and restore the media button event receiver

Do not persist the media button event receiver.
Do not restore the media button event receiver on behalf of the
  application that registered. Prevents reported vulnerability.

Bug 15428797

Change-Id: I7ca3e7fccb165c55b23f471c00e0ed77436f7dc1
ProximitySensor: check for correct MaxRange value

Use TYPICAL_PROXIMITY_THRESHOLD for devices that returns incorrect mProximitySensor.getMaximumRange() value;

Presto's proximity sensor returns values: 0.0f(near) or 5.0f(far).
mProximitySensor.getMaximumRange() must return proximity sensor's availible range, but it always return 0, so mProximityThreshold is also 0.

So boolean positive = distance >= 0.0f && distance < mProximityThreshold;  positive will never be
true.
The cause of this problem is proprietary sensor.msm8660.so, it must set proper Range and Resolution for proximity sensor.

Change-Id: I0cf81fd20f210115cbd6db10c0070b12f1c57336