full_log

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