1. 02 Sep, 2018 2 commits
  2. 27 Jun, 2018 1 commit
    • Eran Messeri's avatar
      AOSP builds do not support Device ID attestation · d62837ea
      Eran Messeri authored
      AOSP builds have different product & brand values than the ones flashed
      onto the device's Keymaster in the factory.
      As a result, Device ID attestation will not work on them correctly
      because there is a mismatch between the values sent to Keymaster by the
      platform and the values Keymaster is expecting to attest to.
      
      Mark AOSP builds as not having this feature since it would affect all
      AOSP builds on all devices.
      
      Bug: 110361822
      Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
      Change-Id: I55e7c68b3e082af465c19cf18aeeeecffc4eb356
      (cherry picked from commit 4260ee9282f9666821dbdb4e7dda6c65f605a6b2)
      d62837ea
  3. 08 Jun, 2018 1 commit
  4. 07 Jun, 2018 5 commits
  5. 06 Jun, 2018 5 commits
  6. 05 Jun, 2018 2 commits
  7. 04 Jun, 2018 1 commit
  8. 03 Jun, 2018 1 commit
  9. 02 Jun, 2018 2 commits
    • TreeHugger Robot's avatar
    • chaviw's avatar
      Use correct StateSet for LayerVector compare. · 738df02b
      chaviw authored
      Currently LayerVector compare function was using the current StateSet.
      This is incorect since the LayerVector may be created with the intention
      of sorting the layers by drawing state. Instead, create the LayerVector
      with a specified StateSet so the compare function always uses the
      correct state.
      
      This fixes an issue where the layers were getting added and sorted by
      current state z order but the caller expected the order to be by drawing
      state z order.
      
      Change-Id: I7afef556fa72f687bcfeb0a642465488cc72f40b
      Fixes: 80516823
      Test: No longer flicker when IME closes. Logs show correct z order.
      Merged-In: I7afef556fa72f687bcfeb0a642465488cc72f40b
      738df02b
  10. 01 Jun, 2018 2 commits
  11. 31 May, 2018 5 commits
    • Bowgo Tsai's avatar
      Otadexopt: removing bootdevice from /dev/block/bootdevice/by-name/* · 1572f9b6
      Bowgo Tsai authored
      We should switch to use /dev/block/by-name/<partition> because there is
      no requirement to have a single 'bootdevice' for Android. The symlink is
      created in the following change:
      
        https://android-review.googlesource.com/c/platform/system/core/+/674989
      
      Bug: 80466341
      Bug: 78613232
      Test: m -j otapreopt_chroot
      Test: Successful go/manual_ab_ota on walleye
      
      Change-Id: I26fbf67e72cc2ee93909e95b0254ba1602e6ae8e
      Merged-In: I26fbf67e72cc2ee93909e95b0254ba1602e6ae8e
      (cherry picked from commit 19d2d08bfbc3840a93762011d6a2763bd37be05a)
      1572f9b6
    • TreeHugger Robot's avatar
    • Jorim Jaggi's avatar
      Push existing pending state when deferring transaction · dba3273a
      Jorim Jaggi authored
      Otherwise the information from another transaction that happened
      before deferring the transaction could have been deferred as well.
      To fix that, we push the currently pending state if the
      transaction is deferred.
      
      Furthermore, we need to modify the behavior how flags are applied.
      Imagine the following sequence of events
      - Surface is hidden flags=hidden
      - t1 doesn't modify the flags (0/0) but sets some other properties.
      flags=hidden mask=0. mCurrentState gets pushed onto mPendingState
      before t2 sets (0/hidden) (flags/mask) flags=0 mask=hidden, to
      show the surface. Furthemore, we defer this transaction.
      mCurrentState gets pushed onto mPendingState.
      - At this point, mCurrentState.flags = 0 (shown), but
      mDrawingState.flags = hidden
      - doTransaction happens. c (the state to promote to drawing state)
      = mCurrentState => c.flags = 0 (shown)
      Since t1 isn't deferred, the 0th element of mPendingState gets
      popped and applied to c. Since mask=0, c.flags = 0 still.
      - c gets promoted to mDrawingState and BOOM the
      surface was shown even though the barrier of the transaction
      showing hasn't opened yet.
      
      Looking closer at the logic it makes sense to just apply the mask
      when modifying the current state, and then just pushing it like
      all other attributes.
      
      Test: go/wm-smoke
      Bug: 78611607
      Change-Id: Ia100532189ef7f59f8939c59db9b6292b41e8e77
      dba3273a
    • android-build-team Robot's avatar
      Snap for 4813226 from 88fbd425 to pi-release · 45d6f0af
      android-build-team Robot authored
      Change-Id: If5a4e90e76d111e1cc415fa2f0ab250ddf5f04c8
      45d6f0af
    • TreeHugger Robot's avatar
  12. 30 May, 2018 3 commits
  13. 29 May, 2018 1 commit
  14. 27 May, 2018 1 commit
  15. 25 May, 2018 5 commits
    • Chia-I Wu's avatar
      ca175ee1
    • Steven Moreland's avatar
      surfaceflinger: fix race condition · 9339952b
      Steven Moreland authored
      surfaceflinger only has one thread.
      
      main thread is:
      a). startHidlServices
      b). do a getService
      c). getService receives notification on binder thread and returns
      d). binder ServiceManager register SF service
      
      Then, started by a).
      hwbinder thread is (DisplayService's, when it receives a transaction):
      e). binder ServiceManager get SF service ( (d) must happen first! )
      
      Normally, (e) never happens because nothing calls into DisplayService
      until later. However, on a particular QCOM device (b/80061790),
      surfaceflinger restarts at just the right time that this sequence happens:
      (a) (b) (e)
      
      then (c) is blocked since (e) is on a binder thread).
      
      Test: QCOM device no longer enters this deadlock
      Test: boot up on Pixel device
      Test: (sanity) check to make sure surface flinger has one hwbinder thread
      Test: (sanity) make sure Pixel device surface flinger doesn't register an
          allocator when it isn't supposed to.
      
      As a follow-up, the return values from these various services will be
      checked.
      
      Bug: 80061790
      Change-Id: I254d70951ee9508790c940240bcd1da5af746dd3
      9339952b
    • Peiyong Lin's avatar
      [RenderEngine] Add inverse tone mapper. · 9a1b6556
      Peiyong Lin authored
      This patch inverse the tone mapping process from hardware composer to make sure
      we have minimum brightness change when HDR video is being played.
      
      BUG: 73825729
      Test: Build, flash, watch Youtube HDR
      Change-Id: I6dd73d520d316e2ae4a890211b7282053d9b8568
      9a1b6556
    • Jorim Jaggi's avatar
      Keep early vsync-offsets for at least two frames after transaction · 90535218
      Jorim Jaggi authored
      Imagine the following sequence, in which vsync-sf is usually 4ms
      behind vsync-app.
      - Vsync-app fires. The app sends a transaction with early wakeup.
      - Vsync-sf fires immediately after early wakeup is received,
      before the regular 4ms delay.
      - Vsync-sf resets itself to vsync-app+4ms as the transaction was
      handled.
      - Repeat 1, but now the app was a bit delayed and sends the early
      wakeup late, such that the time used to do GL comp isn't enough to
      avoid jank.
      
      To fix this, we apply a low pass filter for transaction-caused
      early wake and keep it early for at least 2 frames.
      
      Test: Open/close apps, inspect systraces and verify wake-up times
      Bug: 78611607
      Change-Id: I74b0d88a4d95ca5b6d24950e14e3d6a9379f2714
      90535218
    • David Sehr's avatar
      Disable dex2oatd for release background compiles · 31419e7a
      David Sehr authored
      Use dex2oat rather than dex2oatd for release versions of
      userdebug builds to get more soak time.
      
      Bug: 73769503
      Test: adb shell cmd package bg-dexopt-job
      Change-Id: Id66777e8e49885cf4579d41364d10808df49b63e
      31419e7a
  16. 24 May, 2018 3 commits