Move idmap to frameworks/base [2/2]

idmap depends on libandroidfw, so it should go in frameworks/base.
This follows AOSP which moved idmap to frameworks/base back in
February of 2014.

Change-Id: Ice308a5299a69fd1fbc084a7c76a317c7dec3689
frameworks: allow LockPatternView to be rotated

When displaying this view and rotating the screen, mLockPatternUtils has
the potential to be null, but the save and restore instance state
methods depend on it to be initialized. Work around this by checking if
it's null.

Change-Id: I351bd63fefbcb92fffe20dca6a0381a20ac796ea
Signed-off-by: Roman Birg <roman@cyngn.com>
frameworks: add ongoing notification while collecting bug report

Change-Id: I644da7046b3cbbd0ec601f0e35dfbad6adf4dcf5
Signed-off-by: Roman Birg <roman@cyngn.com>
SystemUI: don't show eq tile while casting

Change-Id: I00ae770b572535be9dca61760ad11e5f84fba63d
Signed-off-by: Roman Birg <roman@cyngn.com>
Use hidden API to validate APK chains

Bug: 13678484
Change-Id: I28dedab74b0e24d47ab9f2190298156c909e9d54
tether: tethering chooses wrong upstream when mobile_dun is required

When mobile_dun is required, the default mobile type will
be deleted from upstream list, this makes wifi become
the highest priority upstream even whne wifi is not available.

Change-Id: I2c12f6cd6d52331220dce900609ad072f9ec3fbc
CRs-fixed: 671675
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