Skip to content

GitLab

Switch branch/tag
  1. 27 Mar, 2015 1 commit
    • Michael Runge's avatar
      Increase timeout when uncrypting OTA · e0dd9516
      Michael Runge authored 
      Larger OTAs (750 MB tested) are taking 3-4 minutes
to write, due to the O_SYNC needed to ensure that
the data is actually committed to disk prior to
reboot.

Bug: 18750317
Change-Id: Idfab3ffd0276df4548f69a09c72ad6f4a344b6e6
(cherry picked from commit 01c06dfb)
      e0dd9516
  3. 16 Dec, 2014 1 commit
    • Christopher Tate's avatar
      Fix bad alarm delivery · 0ac9664a
      Christopher Tate authored 
      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
81f9882b.  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 81f9882b
*except* that this CL preserves the "exact alarms are treated as
standalone" portion of the original patch.

Change-Id: I54c763775877de5b6eeb5617544aa6100bb17526
      0ac9664a
  5. 12 Dec, 2014 2 commits
    • Christopher Tate's avatar
      Tune delivery and batching of alarms · a6e7e6bf
      Christopher Tate authored 
      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 81f9882b)
      a6e7e6bf
    • Christopher Tate's avatar
      Properly recognize repeating wakeup alarms · 5a995f96
      Christopher Tate authored 
      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 864d42eb)
      5a995f96
  7. 01 Dec, 2014 2 commits
    • Christopher Tate's avatar
      Be increasingly aggressive about fstrim if it isn't being run · 4f868ed4
      Christopher Tate authored 
      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
      4f868ed4
    • padarshr's avatar
      Start MountService before performBootDexOpt · e1eea114
      padarshr authored 
      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
      e1eea114
  9. 20 Nov, 2014 1 commit
    • Geoffrey Borggaard's avatar
      Fix null handling in proxies. · 93edcc13
      Geoffrey Borggaard authored 
      ProxyInfo.getPacFileUrl() can not be null.  It will be equal to
Uri.EMPTY.  Checking for null was causing global proxies to never be
disabled.  Or more accurately, global proxies would be disabled, but
would reappear after a reboot.

ProxyInfo.getExclusionListByString() can be null.  If no
exclusion list was specified, the proxy settings would not be
successfully saved, they would disappear after reboot.

Bug: 18453223
Change-Id: I1c27e5dca5b9664bb7468ea909bff489fa110a07
      93edcc13
  11. 19 Nov, 2014 2 commits
  13. 18 Nov, 2014 2 commits
  15. 12 Nov, 2014 1 commit
    • Jeff Sharkey's avatar
      Recover apps with malformed certificates. · 32a22c44
      Jeff Sharkey authored 
      There was a window of time in Lollipop where we persisted certificates
after they had passed through a decode/encode cycle.  The well-written
OpenSSL library was liberal when decoding (allowing slightly malformed
certs to be parsed), but then strict when encoding, giving us
different bytes for effectively the same certificate.

A related libcore change (0c990ab4a90b8a5492a67b2b728ac9a4a1ccfa1b)
now returns the original bytes verbatim, fixing both pre-Lollipop
installs and installs after that change.

This change recovers any apps that had been installed during the
window of time described above by doing a one-time check to see if
the certs are effectively equal.

Bug: 18228011
Change-Id: Ib82bd6db718d0490d7a26c9c1014b7c8457a7f2d
      32a22c44
  17. 07 Nov, 2014 4 commits
  19. 06 Nov, 2014 1 commit
  21. 28 Oct, 2014 1 commit
    • Jason Monk's avatar
      Add missing passive discovery flag · ba35a77c
      Jason Monk authored 
      MediaProjectionManagerService had an active media callback which
was causing a service to be bound 100% of the time.  Adding a
passive flag makes it only observe events, and allow the service
to only be bound when needed by apps requesting active discovery.

Bug: 18042409
Bug: 17969854
Change-Id: I1bfa6609e2aa507ee2ce227de50f0e5ae951e000
      ba35a77c
  23. 24 Oct, 2014 3 commits
  25. 22 Oct, 2014 2 commits
  27. 21 Oct, 2014 9 commits
  29. 20 Oct, 2014 8 commits