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
base: added national roaming info for Play in Poland

Cherry-picked from OmniROM:
https://gerrit.omnirom.org/#/c/3382/

Users of Play in Poland (MCC 260 MNC 06) can roam on
Plus, T-Mobile, Orange (MNCs 01/02/03)

Change-Id: I8ea62b0ca40bac9ced11802ee8ef583d6392a199
National roaming info for Drei in Austria

3AT roams in T-Mobile AT networks

Change-Id: I915edccf92bcbb088fa25b958eb345c624f61597
National roaming info for yesss! in Austria

Change-Id: I930198d3cb311b23752a8c2f54852ebd48d65b86
National roaming info for 3 in Ireland

Change-Id: I451831f4144b72feac1a38ef1e8693cb947d6d7e
core: added national roaming info for Tesco Mobile in Ireland.

Users of Tesco Mobile in Ireland(MCC 272 MNC 11)
  can roam on O2 Ireland (MNC 02)

Change-Id: Ie0b32d51511c2bbc726c43cdec78332397d1ecb9
core: added national roaming info for Bob in Austria.

Users of Bob in Austria(MCC 232 MNC 11)
  can roam on A1 Austria (MNC 01)

Change-Id: I12dfa3d63643af1026dcfea28a4c9d7acec5f9e9
core: added national roaming info for Spring Mobil in Sweden...

Spring Mobil users in Sweden (MCC 240, MNC 10)
can roam on Sweden 3G (MNC 05) and on Sweden 2G (MNC 24).

Change-Id: Ie27ad3561de32557a1713d4962fcc9ec52a8b7fe
National roaming for Telfort in the Netherlands

Don't roam on KPN.nl (204/08)

Change-Id: I4b7614bcdf679bbcb8822077c32d97117d878a8a
Added Non-Roaming for carrier BSNL in UP East and WEST INDIA

Added No-roaming for BSNL from circle UP East to UP West, India

Change-Id: I45e804da143e844d794cca98652f5fc6ac4e209b
Allow 3 AT (mnc05) to roam on T-Mobile in Austria

Change-Id: Ie1a62db9a48cfaf594ddda7b413299a9b587ddd4
National Roaming: Allow T-Mobile AT (MNC03) to roam on 3 AT (MNC10) in Austria

Change-Id: Ief827259fdcb5bfa13bd643f80a8547a56cc934c
Saunalahti considered non-roaming on Elisa

Change-Id: I51b554cf578c6027d52ad6e111e41d269c1f579f
Tele2 considered non-roaming on T-Mo

Change-Id: Ibb05f277b701861b8716168b54e96f63127e686d
Noverca (MNC07) considered non-romaing on TIM (MNC01)

Change-Id: I473e1f88db0fe0d5e1799f6d6d892649abb7dc74
Virgin Mobile (MNC07) considered non-roaming on Movistar (MNC02)

Change-Id: I46a782aefbe62295d6ce9d3c15a2e25630bdcacc