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
cyborg strikes back
Frameworks: fix quick peek

only react on a real swipe to avoid accidental show up
on pressing an action on eg ActionBar

as well the pass trough of mPieTop never worked. Not the
problem due that pie is overlaying this part

reduce the settings value write a bit....we need to
be as fast as possible here due that this method is
called on every touch event

PatchSet: minor code correction

Change-Id: Iced268ad043b753d93375439d7835d8570b7649c

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
Add 2G/3G option to profile connections (1/2)

Change-Id: I55d0768c9eeecb7dcce97c6d6390e339d678d0c4
Go back to AOSP normal mouse pointer

due our default dpi the circle is hard to see

This reverts commit 94fb81670217a7fd713490e035faece7317502ab.