Skip to content

Instantly share code, notes, and snippets.

Created Dec 19, 2014
Embed
What would you like to do?
full_log
#
##
# logging platform/build
##
#
commit b73e5c9fe67a085e87eadb1b92fb8b2b5bcb5e42
Author: The Android Automerger <android-build@android.com>
Date: Tue Dec 16 13:11:28 2014 -0800
LRX22G
commit a03817158db9bc34b41ce8f9a2f1e850fec49144
Author: The Android Automerger <android-build@google.com>
Date: Thu Dec 11 18:03:20 2014 -0800
"LRX22F"
commit 071a8d63ea243ecb7d164d90a3aac081a026a8fe
Author: Dianne Hackborn <hackbod@google.com>
Date: Thu Dec 11 14:04:55 2014 -0800
DO NOT MERGE. Bump version to 5.0.2.
Change-Id: Ia6426dd03ac3b51061429b7da36e317bd3503775
commit 81683e003e0ded78c766795fc93a627e0925d810
Author: The Android Automerger <android-build@google.com>
Date: Wed Dec 10 17:48:55 2014 -0800
"LRX22E"
commit d782ef934f3b35d404c3cd8d673b0bb2a0f5c4ec
Author: The Android Automerger <android-build@google.com>
Date: Mon Dec 1 11:40:37 2014 -0800
"LRX22D"
#
##
# logging platform/cts
##
#
commit ba1a08f56956c89679cd9a64f336ecae5ea9eabd
Author: Nicholas Sauer <nicksauer@google.com>
Date: Thu Dec 11 15:45:43 2014 -0800
DO NOT MERGE. Bump CTS Versions.
Cts version to 5.0_r2
Cts Verifier version to 5.0_r2
BuildVersionTest expected VERSION_RELEASE. Add 5.0, 5.0.1 and 5.0.2.
Change-Id: I0f6e8689d1a07e457c3c7e9b9ff311a054182bd5
#
##
# logging device/asus/grouper
##
#
commit c331a05164246a18c1fff9d9d127c2d1e2c99d74
Author: Iliyan Malchev <malchev@google.com>
Date: Wed Dec 10 12:07:43 2014 -0800
grouper: update prebuilt kernel
6ff7a51 Revert "tegra3_android_defconfig: switch to SLUB"
b/18596108 GFXBench3 TRex test report unsupported on LRX22D
Change-Id: Icfecff7f5eef1d09cd56c846ea8ea0e4b7720c6d
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit c173623f911a551a901ceb63f592b874cdac8b1c
Author: Iliyan Malchev <malchev@google.com>
Date: Wed Nov 26 15:10:46 2014 -0800
grouper: emulate sdcard using 4 threads
This overrides the default of 2 threads.
Change-Id: Ie15b6a02499c5f9f25766c537d1b5a39d312a608
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit bf43d836eb4c522dc8ef448cdba661c538ba4ca8
Author: Iliyan Malchev <malchev@google.com>
Date: Thu Nov 27 10:16:38 2014 -0800
grouper: update prebuilt kernel and power hal
prebuilt kernel
770b156 cpufreq: sysfs knobs for disabling hotplug during UI interaction
power hal:
-- lock at least 2 cores for 3s when interactive
-- when not interactive, revert to defaults.
Change-Id: I7b8993b801b9772c98a0e8ef210957f341f2f5c4
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit 5de1d7573d26175ffcef9e03221e412c7b1ea9f8
Author: Iliyan Malchev <malchev@google.com>
Date: Wed Nov 26 01:04:01 2014 -0800
grouper: power hal: improve interactive loads
-- ignore set_interactive(0) mode sets
-- decrease cpu load from 85% to 75% before ramping up; this way a core's
frequency will be maxed out more aggressively
-- increase the hold time at max freq from 30ms to 500ms before beinning to
ramp down; this way a core will stay longer at the maximum frequency, once
there
-- increase timer sampling rate from 20ms to 50ms; this way cpufreq ramdown
will be slower
Change-Id: I5d7e387f96db3601a2ab95fbac71359c7b3e81ba
Signed-off-by: Iliyan Malchev <malchev@google.com>
#
##
# logging device/asus/tilapia
##
#
commit 0f2198a0fdd01438291b6527b5c4c2c8296ecde8
Author: Iliyan Malchev <malchev@google.com>
Date: Thu Nov 27 11:03:11 2014 -0800
tilapia: emulate sdcard using 4 threads
This overrides the default of 2 threads.
Change-Id: I8693043c1f1dce27c6606aab31f57176d870a759
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit e9e2ed58d155234df4abca3900da5247b326c488
Author: Iliyan Malchev <malchev@google.com>
Date: Thu Nov 27 10:59:01 2014 -0800
tilapia: chown and chmod core_lock_{count,period} sysfs files
Change-Id: I6713a1bed0e17f58ccc28c45751271b8591f964b
Signed-off-by: Iliyan Malchev <malchev@google.com>
#
##
# logging device/generic/mini-emulator-armv7-a-neon
##
#
commit 61eed4d252e5a5c02ae7cc592ed83356e00fd8b0
Author: leozwang <leozwang@google.com>
Date: Sun Nov 9 21:56:34 2014 -0800
Trim fingerprint.
Bug: 18216223
Change-Id: I4fb5f65f0686655ba9b23cd6ba70ac3965eb628e
#
##
# logging platform/external/chromium_org
##
#
commit d5b9196447ceed40362c34019cdb1a23101c59ec
Author: Bart Sears <bsears@google.com>
Date: Thu Dec 11 17:31:26 2014 -0800
Update volantis workaround to cover L MR0.5 (5.0.2)
BUG: 18725105
Change-Id: I384fde4c9b36c948e995841469b1061da763584d
#
##
# logging platform/frameworks/base
##
#
commit 0ac9664a9ee2e6d1d3b68fe00c264ad94fe98966
Author: Christopher Tate <ctate@google.com>
Date: Tue Dec 16 12:14:06 2014 -0800
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
commit a6e7e6bf5923f427785d6946ac050ba4e4052dc5
Author: Christopher Tate <ctate@google.com>
Date: Thu Dec 4 18:27:16 2014 -0800
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)
commit 5a995f968ca0e5c9701e36f0240b4708ea69c78d
Author: Christopher Tate <ctate@google.com>
Date: Tue Dec 2 11:48:53 2014 -0800
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)
commit 4f868ed4f5f6da09c5c535a50ef6ab308303e070
Author: Christopher Tate <ctate@google.com>
Date: Fri Nov 21 13:54:45 2014 -0800
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
commit e1eea114d0827b6c99fc85d5548c013918c60844
Author: padarshr <padarshr@codeaurora.org>
Date: Wed Nov 5 16:54:50 2014 +0530
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment