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
Revert "SystemUI: Add global reboot option"

This reverts commit 1c329ea7629816c841bc2235650df6efb35c581a.
Revert "appops: Fix an off-by-one error that causes the location icon to stay on"

This reverts commit 3653d9aae7bf1e632034341114dc5e250878580e.
core: Fix typos in AOSP EN resources

Change-Id: I40220888c2fbe87629d17fc52046e554388de3ee
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)
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

Conflicts:
	services/core/java/com/android/server/AlarmManagerService.java
SystemUI: Update WiFi indicator drawable sizes

Resize both the activity arrows and the signal strength indicators so
that both are properly centered and overlay correctly for all screen
densities.

Change-Id: I7e95adcdc110995504534a58eb0df42ba132bc97
Bluetooth-Wipower: Enable dynamic logging for A4WP

This helps to enable wipower dynamic parameters intercepted
at host to be logged via adb/command line.

Change-Id: Ibd79f4d56c99a43eab1146f4ae20155ac439cd8f
CRs=fixed: 754356
Bluetooth: Adds check to verify Bluetooth adapter state

This checks whether bluetooth is turned ON or not in BLE
start scan process.BLE scan apis are called from applications
so need to check if BT adapter state is ON to avoid Bluetooth
crash

CRs-fixed: 649274
Change-Id: Ic075e1560bba2cabbfac2e1477932f9ad3144067
Bluetooth: Change userhandle to current from ALL

Change to a user handle to indicate the current
user of the device instead of ALL to avoid the
force close error in bluetooth.

Change-Id: I72e5feba6616a48ef8590b6965ec1d94f27b7dca
CRs-fixed: 742926
Bluetooth: Enforce BT state check during GATT close/disconnect

Enforce BT state check when BLE Apps call into GATT to handle scenarios in which
delayed call from BLE App to disconnect/close comes after the BT is OFF

CRs-Fixed: 759852
Change-Id: Iaf7004cdd4fe52e64c48838f6ed918e1d25f5a1e
Bluetooth: Sync Bluetooth Adapter and Manager Service.

BluetoothAdapter has timeout of 8 sec whereas waittime of
Bluetooth Manager Service has timeout of 3 seconds, case
if remote does not responds to service level  disconnection
then Mangaer Service times out after 3 sec.
During multiuser switch new process is created hence
previous process cannot block ON thus one process is waiting
for timout and other process tries to Turn BT ON leading to
crash.
Fix involve is to have Adapter and Manager service
have same timeout during user switch.

CRs-Fixed: 761698

Change-Id: Ib1590fb2a41f748f36c58ae9ca8916cf68befc82
Correct the lockscreen carrier text alignment and text color

In AOSP the text is left aligned, not centered, and the text color is white, not grey

Change-Id: Ie9c77761d3440336ae57abed24c8403bda06be3e
SystemUI: fix MediaProjection cast crash

Clicking on the "cast" icon of an app using the MediaProjection API will
crash as the code assume that it is a device.

java.lang.ClassCastException: android.media.projection.MediaProjectionInfo cannot be cast to android.media.MediaRouter$RouteInfo
	at com.android.systemui.statusbar.policy.CastControllerImpl.startCasting(CastControllerImpl.java:177)
	at com.android.systemui.qs.tiles.CastTile$CastDetailAdapter.onDetailItemClick(CastTile.java:237)
	at com.android.systemui.qs.QSDetailItems$1.onClick(QSDetailItems.java:177)
	at android.view.View.performClick(View.java:4756)
	at android.view.View$PerformClick.run(View.java:19749)
	at android.os.Handler.handleCallback(Handler.java:739)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:135)
	at android.app.ActivityThread.main(ActivityThread.java:5221)
	at java.lang.reflect.Method.invoke(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:372)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:898)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:693)

Change-Id: Icfdf745c03da7bd1bbb228e06005f55324c1b8fa
Merge tag 'android-5.0.2_r1' into lollipop

Android 5.0.2 release 1
AlarmManagerService: Underp upstream merge

Signed-off-by: BigBrother1984 <carlosavignano@aospa.co>