Start MountService before performBootDexOpt

This change is to start Mountservice before starting
performBootDexOpt, as in one case, in performBootDexOpt
when system upgrade happens, StorageManager will be started to
get the low threshold of DataDir. But, at this point, as
Mountservice is still not up, StorageManager will end up
having a null object of Mountservice.

Change-Id: If2b5e1b58e7d2a72c6313f196e98a68738295ec6
Be increasingly aggressive about fstrim if it isn't being run

The current heuristics depend on devices being alive at midnight+ in
order to run periodic background fstrim operations.  This unfortunately
means that people who routinely turn their devices off overnight wind
up with their devices *never* running fstrim, and this causes major
performance and disk-life problems.

We now backstop this very-friendly schedule with an increasingly
aggressive one.  If the device goes a defined time without a background
fstrim, we then force the fstrim at the next reboot.  Once the
device hits the midnight+ idle fstrim request time, then we already
aggressively attempt to fstrim at the first available moment
thereafter, even if it's days/weeks later without a reboot.

'Available' here means charging + device idle.  If the device never
becomes idle then we can't do much without rendering an in-use device
inoperable for some number of minutes -- but we have no evidence of
devices ever failing to run fstrim due to this usage pattern.

A new Settings.Global element (type 'long', called
"fstrim_mandatory_interval") is the source of the backstop time.  If
this element is zero or negative, no mandatory boot-time fstrim will
ever be performed.  If the element is not supplied on a given device,
the default backstop is 3 days.

Adds a new string to display in the upgrading dialog when doing
the fstrim.  Note it is too late for this to be localized, but since
this operation can take a long time it is probably better to have
it show *something* even if not localized, rather than just sit there.

Bug 18486922

Change-Id: I5b265ca0a65570fb8931251aa1ac37b530635a2c
Properly recognize repeating wakeup alarms

cherry-pick from lmp-mr1-dev

The code in place was inappropriately treating all recurring alarms
as non-wakeup for purposes of deferral.  Worse, it was overriding the
"this deliverable batch of alarms includes a wakeup alarm" bookkeeping,
so could potentially cause inappropriate deferral of even standalone
wakeup alarms.

Bug 18591317

Change-Id: I2a62ed4badcaeb549c1ac4f086014aa829e45427
(cherry picked from commit 864d42eb96a9127b7d2f10ad11e709c24b4b4304)
Tune delivery and batching of alarms

cherry-pick from lmp-mr1-dev

* Inexact alarms no longer coalesce with exact alarms.  The motivation here
is that exact alarms are far more likely to be wall-clock aligned, and in
general pulling all alarms toward wall-clock alignment is a bad idea.

* Wakeup times are now fuzzed within the target batch's allowed window
rather than being hard pinned at the start of the window.

Bug 18631821

Change-Id: Iefaf34eee3f2a6546abefc27e177ee2fdcff935f
(cherry picked from commit 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0)
Fix bad alarm delivery

The man bent over his hourglass,
A programmer of sorts. The day was green.

They said, "You have a blue hourglass,
You do not fire alarms when they're asked."

The man replied, "Alarms as they're asked
are changed within the blue hourglass."

And they said then, "But fire, you must
Alarms beyond us, yet themselves,

Alarms within the blue hourglass
That trigger exactly when they're asked."

 ---

Fix the delivery-fuzzing semantics that had been introduced in
81f9882b5aadd6a2289c9f521a06a7af5f35ebf0.  That patch turned out
to be incomplete; in particular, alarms scheduled later might require
the validity of an already-scheduled kernel alarm even if they did
not affect the head alarm batch directly, and this was not being
addressed.  For now, roll back the fuzzed delivery logic entirely.
(This is not a full revert because that patch also caused exact alarms
to be considered standalone for batching purposes, and we need to
preserve that new policy.)

Bug 18726690
Bug 18765436

This is a 'git revert' of 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0
*except* that this CL preserves the "exact alarms are treated as
standalone" portion of the original patch.

Change-Id: I54c763775877de5b6eeb5617544aa6100bb17526
Add Google Location Provider

Change-Id: Ibc356a4ec2b33a9b40da4c2c62227fd215768152
Signed-off-by: mv <michvett.mv@gmail.com>
SystemUI : Port forward statusbar brightness control

Brings back the status bar brightness control from cm-10.2/cm-11

Change-Id: Icc04e7da3286e9925f8b90528c1e022b33d33e9d
Allow translucent navigation bar in landscape mode.

From CM
http://review.cyanogenmod.org/#/c/68196/

Includes:

d547e9d Fix glitch appearing when using translucent system bars in
landscape.

    Before: http://i.imgur.com/zJCjCvx.png
    After: http://i.imgur.com/v563Shz.png

c157db0 Fix translucent navigation bar layout on tablets in landscape.

    The status bar blocker view was visible and stretched over the whole
    navigation bar, even though it's not even needed on tablets, as the
    status bar never extends into the navigation bar there. Fix that by
    hiding the blocker view, but keep it in the layout in oder to not
    clutter the code with null checks.

    Also cleanup unneeded method override.

8d1f863 Only show status bar blocker view if nav bar is translucent.

    It's the background drawable of the translucent nav bar that makes
the
    blocker view necessary (as the background creates a visual 'gap'
between
    status bar and visual start of the nav bar), so if the nav bar isn't
    translucent, there's no need for the view.

Signed-off-by: Evan Anderson <evananderson@aospa.co>
Change-Id: I5388f3f8a34533624619714bacfba52f95fc6d85

//
Some Changes for "plain" AOSP (mv)
//

Conflicts:

packages/SystemUI/src/com/android/systemui/statusbar/phone/BarTransitions.java

packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarTransitions.java

packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java

Signed-off-by: mv <michvett.mv@gmail.com>

Conflicts:

packages/SystemUI/src/com/android/systemui/statusbar/phone/BarTransitions.java

packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarTransitions.java

packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java

packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
Navigation bar custom height

Conflicts:

policy/src/com/android/internal/policy/impl/PhoneWindowManager.java

Signed-off-by: mv <michvett.mv@gmail.com>

Conflicts:
	core/java/android/provider/Settings.java

Conflicts:
	packages/SystemUI/res/layout/navigation_bar.xml

policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
Revert "SystemUI : Port forward statusbar brightness control"

This reverts commit 62fca5c7c70483a115cad8d69ce48d6d69e3a037.
Revert "Allow translucent navigation bar in landscape mode."

This reverts commit 77aeed41232ecc0ffc585ff1574a55b1195038c9.
[3/3] AudioEffect: Add a stereo widener effect

Change-Id: Iab2035c5601394b060e7e77e85ad85aca6e4c89f
[3/3] AudioFX: Add center frequency param to bassboost

Change-Id: I49da8e5ab24502d0de5c09b7fc9f4b8a51bead60
Audio_Effects: Add @hide to some fields and methods

Signed-off-by: mv <michvett.mv@gmail.com>
base: audiofx: harden against offload effects

Hack for now to allow using DSPManager for offload effects

-offload effect equalizer has only 5 bands but DSPManager has hardcoded 6
-offload effect bassboost doesnt support center freq

Change-Id: I9ad661221654415b2be3ed18f8cf31453d6df637
(cherry picked from commit 0191323bd51704bec2a9d81d53eb554e229814cd)
SystemUI: add quick settings pull down with one finger

Logic is currently set to use 1/3 of right hand side of the statusbar to
trigger a quick settings quick pull down, quickly.

Change-Id: I3f536496f724f07d2419a5b2db5fa8f8261609e7
Signed-off-by: Roman Birg <roman@cyngn.com>
Add clear all recents action to recents panel

Change-Id: I2243ebc83abc483e78b112900a653d7e61edc5ba
input: Forward-port support for chained input filters

 * Original code by Jens Doll for Pie controls
 * Needed now to support the gesture sensor

Change-Id: I0b86d70f9a040ba5953e1820e9818df0f10091ee
[2/2] framework/base: Add EdgeGesture service.

Based on code of PieService.

Conflicts:
	Android.mk
	core/res/res/values/config.xml
	core/res/res/values/dimens.xml
	core/res/res/values/symbols.xml
	services/java/com/android/server/SystemServer.java

Change-Id: I053737e36340a5ec6814b21eb87575f9689c7e88

Conflicts:
	core/res/res/values/symbols.xml
	services/java/com/android/server/SystemServer.java
PhoneWindowManager: add ability to use EdgeGestureService for system gestures.

Update: Default to enabled

Conflicts:
	core/java/android/provider/Settings.java
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java

Change-Id: Id4e2c0d82f771cd1c20e9196fb6db347494cca69