summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-06-26AOSP builds do not support Device ID attestationandroid-wear-9.0.0_r9android-wear-9.0.0_r8android-wear-9.0.0_r7android-wear-9.0.0_r6android-wear-9.0.0_r5android-wear-9.0.0_r4android-wear-9.0.0_r34android-wear-9.0.0_r33android-wear-9.0.0_r32android-wear-9.0.0_r31android-wear-9.0.0_r30android-wear-9.0.0_r3android-wear-9.0.0_r29android-wear-9.0.0_r28android-wear-9.0.0_r27android-wear-9.0.0_r26android-wear-9.0.0_r25android-wear-9.0.0_r24android-wear-9.0.0_r23android-wear-9.0.0_r22android-wear-9.0.0_r21android-wear-9.0.0_r20android-wear-9.0.0_r2android-wear-9.0.0_r19android-wear-9.0.0_r18android-wear-9.0.0_r17android-wear-9.0.0_r16android-wear-9.0.0_r15android-wear-9.0.0_r14android-wear-9.0.0_r13android-wear-9.0.0_r12android-wear-9.0.0_r11android-wear-9.0.0_r10android-wear-9.0.0_r1android-cts-9.0_r4android-cts-9.0_r3android-cts-9.0_r2android-cts-9.0_r1android-9.0.0_r9android-9.0.0_r8android-9.0.0_r7android-9.0.0_r6android-9.0.0_r5android-9.0.0_r3android-9.0.0_r2android-9.0.0_r18android-9.0.0_r17android-9.0.0_r10android-9.0.0_r1pie-s2-releasepie-release-2pie-releasepie-r2-s2-releasepie-r2-s1-releasepie-r2-releaseEran Messeri
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)
2018-06-08Snap for 4829593 from ba88c2e9bcfb8665ef8fe55eab3b3d0895d0592c to pi-releaseandroid-build-team Robot
Change-Id: I6a5657813f61abf9f34bcd67e699b60c50e35769
2018-06-07Merge "Camera: update tonemap curve images" into pi-devpie-devTreeHugger Robot
2018-06-07Merge "libbinder: fix using destroyed mutex warning." into pi-devYabin Cui
2018-06-07Camera: update tonemap curve imagesYin-Chia Yeh
Bug: 74942037 Merged-In: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3 Change-Id: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3
2018-06-07Snap for 4826885 from b46d5b2d82b021db41a72f4c3eb9250f8a839e04 to pi-releaseandroid-build-team Robot
Change-Id: I28d7d98dd2f98a088767c01007d0453ecebb8c7b
2018-06-06Merge "surfaceflinger: prime shader cache for P3 conversion" into pi-devChia-I Wu
2018-06-06Merge "surfaceflinger: force client composition for Y410" into pi-devChia-I Wu
2018-06-06surfaceflinger: force client composition for Y410Chia-I Wu
When the pixel format is Y410 masquerading as RGBA_1010102, always force client composition. Bug: 80509363 Test: no effect on Pixel devices Change-Id: I31996eeda1559b0557a5acb53d593fd4f395ccaf Merged-In: I31996eeda1559b0557a5acb53d593fd4f395ccaf
2018-06-06Snap for 4824048 from 3e273065386bde56c4c7710de2ceb585a5eb4784 to pi-releaseandroid-build-team Robot
Change-Id: If615f7a4ac4730f18de19ad8f4be3aafba2cb650
2018-06-06Merge "[SurfaceFlinger] Respect HDR data space." into pi-devPeiyong Lin
2018-06-05[SurfaceFlinger] Respect HDR data space.Peiyong Lin
Respect HDR data space when there is no legacy HDR support. Previously we only cared about HDR data space when it is supported, however, on Pixel 2 there is no HDR mode support. This patch makes sure that when HDR mode is not supported, we fall back to Display P3 color mode correctly. BUG: 80404330 Test: Build, flash and watch Youtube HDR Change-Id: I7d27711fe4d33268e5ebbd14fce0975f9e642e84 Merged-In: I7d27711fe4d33268e5ebbd14fce0975f9e642e84
2018-06-05libbinder: fix using destroyed mutex warning.Yabin Cui
Bug: 77473515 Test: run `pm list instrumentation` for several hours, Test: and no warning appears. Change-Id: I66a39ddd66731779fdc6e534f827ad524685b3ba
2018-06-05Merge "SF: Add workaround to release screenshot buffer" into pi-devTreeHugger Robot
2018-06-04surfaceflinger: prime shader cache for P3 conversionChia-I Wu
Bug: 77287550 Test: no shader compilation when WCG apps start Change-Id: I45cdefc97c5e9060269060e33d79b40304cfdbbf
2018-06-03Snap for 4818534 from 4f80b867b3433ddc16d416809c7e9cd5d6deb88b to pi-releaseandroid-build-team Robot
Change-Id: I709277f165baf832a446f373c111df15409352fa
2018-06-02Merge "Use correct StateSet for LayerVector compare." into pi-devTreeHugger Robot
2018-06-01Use correct StateSet for LayerVector compare.chaviw
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
2018-06-01Merge "Push existing pending state when deferring transaction" into pi-devJorim Jaggi
2018-05-31SF: Add workaround to release screenshot bufferDan Stoza
Works around driver behavior to force the [E]GL driver to fully release the screenshot buffer immediately after the screenshot is complete rather than deferring until the next instance of client composition. Bug: b/77935566 Test: Manual, inspect 'dumpsys SurfaceFlinger' after launching an app and then returning home (which causes a screenshot for overview) Change-Id: I4f33d89f3ff3020707a9f556a1fcfe34bc9b7adb
2018-05-31Otadexopt: removing bootdevice from /dev/block/bootdevice/by-name/*Bowgo Tsai
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)
2018-05-31Merge "Keep early vsync-offsets for at least two frames after transaction" ↵TreeHugger Robot
into pi-dev
2018-05-31Push existing pending state when deferring transactionJorim Jaggi
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
2018-05-31Snap for 4813226 from 88fbd425a85fbba6365976ca9b056c719f7685a5 to pi-releaseandroid-build-team Robot
Change-Id: If5a4e90e76d111e1cc415fa2f0ab250ddf5f04c8
2018-05-30Merge "surfaceflinger: RenderIntent::COLORIMETRIC is no longer mandatory" ↵TreeHugger Robot
into pi-dev
2018-05-30surfaceflinger: RenderIntent::COLORIMETRIC is no longer mandatoryChia-I Wu
RenderIntent::COLORIMETRIC is mandatory only for SDR color modes. For HDR color modes, RenderIntent::TONE_MAP_COLORIMETRIC is mandatory. Bug: 80030364 Test: HDR videos Change-Id: I70d96ac66d069218d789dded330169284a61bde1
2018-05-30Snap for 4810559 from 31b85c2326ea082733a848d47b630f44c7888549 to pi-releaseandroid-build-team Robot
Change-Id: I7c5b515f0c34242228b2db5681c76fa15e79d7aa
2018-05-29Fix cleanup of swapchain images in the shared caseChris Forbes
Previously we'd fail to call DestroyImage for images in the shared swapchain. We only need to skip cancelBuffer. Bug: b/78779994 Test: dEQP-VK.wsi.android.* Change-Id: Ic95887fb76a8ab5d01e6e3aaa3f63dddc697ea4c
2018-05-29Merge "surfaceflinger: fix race condition" into pi-devTreeHugger Robot
2018-05-27Snap for 4807121 from ca175ee15a529cca0eb2bc8372e552d4ad255fc0 to pi-releaseandroid-build-team Robot
Change-Id: I766c990434e23ba9c195318e386e072bd01515b6
2018-05-25Merge "[RenderEngine] Add inverse tone mapper." into pi-devChia-I Wu
2018-05-25surfaceflinger: fix race conditionSteven Moreland
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
2018-05-25[RenderEngine] Add inverse tone mapper.Peiyong Lin
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
2018-05-25Keep early vsync-offsets for at least two frames after transactionJorim Jaggi
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
2018-05-24Disable dex2oatd for release background compilesDavid Sehr
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
2018-05-24Merge "Log Binder Proxy Limit reached only once" into pi-devTreeHugger Robot
2018-05-24Snap for 4801384 from db83ea84ab10d097e692edfe32972eeea7312fd9 to pi-releaseandroid-build-team Robot
Change-Id: Iabb9257409efa3b4a240109ce91c13b6aa7350c4
2018-05-24Merge "Adding a file to use for excluding features from aosp" into pi-devTreeHugger Robot
2018-05-24Merge "Need GSI to support landscape LCM" into pi-devTreeHugger Robot
2018-05-23Log Binder Proxy Limit reached only onceMichael Wachenschwanz
Bug: 79578081 Test: bit FrameworksCoreTests:android.os.BinderProxyCountingTest Change-Id: Ia0d4148d5d9d5b57fe69b86b280fbeb7e68dca2a
2018-05-23Adding a file to use for excluding features from aospSuprabh Shukla
android.hardware.location.network is incorrectly getting included in aosp targets without a valid location provider. Adding this xml to include in aosp target configurations. Test: lunch aosp_taimen-userdebug; build and flash Then atest android.app.cts.SystemFeaturesTest Bug: 33380753 Change-Id: I4f4d189bd605b8d4798dbd7640ac56cbec28c618
2018-05-23Merge changes from topic "color-vendor-intents" into pi-devChia-I Wu
* changes: surfaceflinger: allow unknown render intents surfaceflinger: display color setting is a hint surfaceflinger: compute color mode mappings on hotplug
2018-05-23Need GSI to support landscape LCMIris Chang
When device uses landscape LCM, the nature of the screen shows that the device is a portrait device. After we flash with GSI, there is vendor solution for landscape LCM used at portrait device. As the result, the screen displays landscape layout and orientation while device is at portrait orientation. In addition, the sensor coordinate system mismatches with android coordinate system. We suggest Google can add config to handle the case "portrait device uses landscape LCM or landscape device uses portrait LCM". Bug: 69691076 Test: We verified following test cases for this patch on Android O-MR1. 1. Make sure homescreen is normal 2. Rotate device and make sure screen is normal 3. Grab screen shot and check if screen shot is normal 4. Connect to Wi-Fi display and make sure WFD screen is normal Test: Tested 1, 2 and 3 on Pixel 2. Test: artifially setup 90 degree rotation on Pixel and make sure that screenshots are aligned to the screen. Change-Id: Ib42c9a216e8a6fe465139d6eece152fb1765b422
2018-05-23surfaceflinger: allow unknown render intentsChia-I Wu
Allow render intents that are unknown to SurfaceFlinger. Bug: 79843697 Bug: 75981986 Test: manual Change-Id: Ia81436747b1d2fe9f44e749b93a9c1a5a7f1f6cb
2018-05-23surfaceflinger: display color setting is a hintChia-I Wu
Display color setting is merely a hint. Check the active render intent before applying the legacy sRGB color matrix. Bug: 79843697 Test: manual Change-Id: I73b45cbf2274a56037ce0439470f1baafffa8914
2018-05-23surfaceflinger: compute color mode mappings on hotplugChia-I Wu
Populuate DisplayDevice::mColorModes when a DisplayDevice is created. DisplayDevice::mColorModes is a map from any possible Dataspace/RenderIntent to supported Dataspace/ColorMode/RenderIntent. This makes sure we never ask the composer to use an unsupported Dataspace/ColorMode/RenderIntent combination. The map is populated on hotplug because we don't want to compute the mapping on the fly at each frame. Bug: 79843697 Bug: 75981986 Test: manual under sRGB, P3, HDR Change-Id: I967d09b1e8d31ea631b202db1799a7a2a0c5ee3f Merged-In: I967d09b1e8d31ea631b202db1799a7a2a0c5ee3f
2018-05-23Merge "Atrace: Add the debug.atrace.user_initiated property." into pi-devTreeHugger Robot
2018-05-23Merge "surfaceflinger: layer dataspace is not a state" into pi-devChia-I Wu
2018-05-23Atrace: Add the debug.atrace.user_initiated property.Carmen Jackson
This will ensure that, when we're tracing, the debug.atrace.user_initiated tracing property will be set to 1. We can then reliably use that property to determine whether an atrace trace is in progress. Previously, we were using the debug.atrace.tags.enableflags property, which is only set to a value when a userspace tracepoint is being traced. Bug: 79998861 Test: Took traces of only the 'sync' tag and verified with logging that Traceur was representing the trace state correctly when entering and exiting the app. Test: Took a trace using the default category list and saw other userspace tracepoints in the output (such as activityStart). Change-Id: Iaf807f14ee65dc14e85d3d8d2ba489fcf742e3cc
2018-05-23Merge "surfaceflinger: initialize DisplayDevice data members" into pi-devChia-I Wu