framework-res: Remove gingerbread scrolls
Fix misspelling of getLteSignalStrenght.

Change to getLteSignalStrength.

Change-Id: Ie2acec9e01af0e64a61902383f06729a7cee1975
Update tethering profile for specific operators

Update or add tethering profiles in config.xml.
And also add MOBILE_DUN to config_tether_upstream_types

FR-ORG,SFR
ES-VDF,ORG,Movistar
IT-VDF,TIM
GR-VDF
US-TMO
CA-Rogers,Fido
Isreal-ORG,PC HOT Mobile
HK-CSL,Hutchison
AU-Telstra

Change-Id: Ic3501263679785362bc50a5a4ea3751e7f0c7b21
Signed-off-by: Seonju Oh <seonju.oh@lge.com>
Signed-off-by: Sungmin Choi <sungmin.choi@lge.com>
Fix wrong log information in DevicePolicyManagerService

When user reset password their password,
if password doesn't match target quality of device,
DPM print a log why can't reset password.
however log message isn't correct information.
in log context, it have to exist current quality
and target quality. this patch can help print correct log.

Change-Id: I5c8fb1c77ddbe1bdbc76e35038c897e2e8efb077
Adding matching @deprecated.

Bug: 8657266
Change-Id: Idbd22dc647f11441d15da12eb23723539768cf4c
Correct a small doc error

Change-Id: I2adcc169193452549e55ac10958f0e28216aeb15
Avoid NullPointerException in getHandler()

mAttachInfo may be set to null by other threads while running
getHandler().

This fix assigns mAttachInfo to a local variable. Checking null pointer
and getting a member variable are executed through the local variable.
This local variable is constant. So NullPointerException doesn't occur
even if mAttachInfo is set to null while running getHandler().

Change-Id: I4013dfb7951bd864628868ed58f8c4f5b7cbd1d3
Someone's IDE chose the wrong Date.

Part 1 of the mystery of the java.sql.Date in preloaded-classes solved.

Change-Id: I33fffec1f86e34167a76afc839d9f4ce31fa31f7
Fix documentation of requestCode parameter.

It's not correct to state requestCode is 'currently not used'. It can be
used to differentiate multiple PendingIntents since a number of Android
versions now. Also, the introduction block of the PendingIntent
documentation explicitly states this as a possible use:
"If you truly need multiple distinct PendingIntent objects active at the same
time [...], then you will need to ensure there is something that is different
about them to associate them with different PendingIntents. This may be
any of the Intent attributes considered by Intent.filterEquals, or
different request code integers supplied [...]"

So fix the documentation inconsistency to make the possible use
immediately clear.

Change-Id: Ia65d7a5ab12c2c3ee1aa1c5107e5ea8fd937b765
[1/2] Add triggers to change profile based on AP

Add data structure mWifiTriggers to store triggers per profile.
Add network change listener to switch to profile

Change-Id: I97e360d7783d3b0e2bbd70fe7a9a866d8c0fa7cd
[2/2] Add bluetooth triggers to profiles

Change-Id: I374cc93364c88b8b29c88345deccf297234ff624
Profiles: Fix turning bluetooth on/off when its in intermediate state

Change-Id: I09213c987580f47a6c3618edb469edabda96230c