Fix ringer mode being unneededly changed by setting ringer mode volume
to 0.

When having set the ringer mode to silent on a device with vibrator and
calling setStreamVolume() for the ringer stream again (e.g. in one of
the volume control dialogs in the settings app), the ringer mode is set
to vibrate, although there's no reason to do so.

Fix that by remembering the last non-normal (that is, either silent or
vibrate) ringer mode and using that when setting the stream volume to 0.

Change-Id: I27f1c75a0fef52bd63ac20f4101042808ce2c458
JIRA: CYAN-1403
Merge "Fix ringer mode being unneededly changed by setting ringer mode volume to 0." into jb4.2
Frameworks: speed up statubar/notification drawer

a lot user complain about slow statusbar pull down introduced
with jb 4.2....this speed it up

thanks to IceColdJelly

Change-Id: Iae108f5680b25ea995168a505a30e06bef0185d3
[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
Profiles: Fix turning bluetooth on/off when its in intermediate state

Change-Id: I09213c987580f47a6c3618edb469edabda96230c
Frameworks: fix aapt warnings

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

Change-Id: I374cc93364c88b8b29c88345deccf297234ff624
Resolve LocationManager + ActivityManager conflict

LocationManagerService was serially stuffing the same Location into
multiple Intents, which it would immediately hand off to
ActivityManagerService, running as a different thread in the same
process. LocationManager would continue to work with that Location
while ActivityManagerService worked with a Parceled version of it.

However, Location.mExtras is also a Bundle, and both
ActivityManagerService and LocationManagerService ended up working
with references to the same Bundle. ActivityManagerService needs
it in Parceled form (ie mParceledData != null), but
LocationManagerService was triggering Bundle.unparcel() when
referencing the data contained within.

As a result, LocationManagerService was able to trigger NPE (or
worse) in ActivityManagerService by manipulating the mExtras
member of a Location that was in the process of being reported to
listeners.

To resolve this issue, I copy-construct a new Location to report to
each listener. This should prevent ActivityManagerService and
LocationManagerService from referencing the same Bundle data, as
Location's copy constructor also copyconstructs the mExtras member,
rather than simply share references.

Bug: 7518371
Change-Id: Ib2334e0375612441ba6bbee0bde6c1f18b01f6d2
Profiles: Add a profile picker activity

Patchset 2: Add CM Copyright
Patchset 3+4: Rebase
Patchset 5: Some optimizations

Change-Id: Ic8281e4c6fef6d2f4c56fc01acfe6e54b4c8f51c
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
Use sticky broadcast to convey torch state (1/2).

It doesn't really make sense to store the (non-persistent) state of the
torch in a (persistent) setting. As the torch is sending a broadcast
anyway, make that broadcast sticky and use it to convey the state.

Also unify the torch constants (actions, extras, activity names) at a
common place.

Change-Id: If845bef27cc79990794aa748dce18cfea3bac1f5
AssetRedirectionManager: Accept redirections only for whitelisted resource types

Change-Id: Idf1ea739a81719b6a196f0114c9fc3b7c7ff428c
fix merge