Age | Commit message (Collapse) | Author |
|
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)
|
|
Change-Id: I6a5657813f61abf9f34bcd67e699b60c50e35769
|
|
|
|
|
|
Bug: 74942037
Merged-In: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3
Change-Id: I2b4bffd685ddcb8899fb427b14c8a0ab937725c3
|
|
Change-Id: I28d7d98dd2f98a088767c01007d0453ecebb8c7b
|
|
|
|
|
|
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
|
|
Change-Id: If615f7a4ac4730f18de19ad8f4be3aafba2cb650
|
|
|
|
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
|
|
Bug: 77473515
Test: run `pm list instrumentation` for several hours,
Test: and no warning appears.
Change-Id: I66a39ddd66731779fdc6e534f827ad524685b3ba
|
|
|
|
Bug: 77287550
Test: no shader compilation when WCG apps start
Change-Id: I45cdefc97c5e9060269060e33d79b40304cfdbbf
|
|
Change-Id: I709277f165baf832a446f373c111df15409352fa
|
|
|
|
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
|
|
|
|
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
|
|
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)
|
|
into pi-dev
|
|
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
|
|
Change-Id: If5a4e90e76d111e1cc415fa2f0ab250ddf5f04c8
|
|
into pi-dev
|
|
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
|
|
Change-Id: I7c5b515f0c34242228b2db5681c76fa15e79d7aa
|
|
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
|
|
|
|
Change-Id: I766c990434e23ba9c195318e386e072bd01515b6
|
|
|
|
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
|
|
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
|
|
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
|
|
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
|
|
|
|
Change-Id: Iabb9257409efa3b4a240109ce91c13b6aa7350c4
|
|
|
|
|
|
Bug: 79578081
Test: bit FrameworksCoreTests:android.os.BinderProxyCountingTest
Change-Id: Ia0d4148d5d9d5b57fe69b86b280fbeb7e68dca2a
|
|
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
|
|
* changes:
surfaceflinger: allow unknown render intents
surfaceflinger: display color setting is a hint
surfaceflinger: compute color mode mappings on hotplug
|
|
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
|
|
Allow render intents that are unknown to SurfaceFlinger.
Bug: 79843697
Bug: 75981986
Test: manual
Change-Id: Ia81436747b1d2fe9f44e749b93a9c1a5a7f1f6cb
|
|
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
|
|
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
|
|
|
|
|
|
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
|
|
|