dalvik sysprop settings in these mk files are changed to optional ones
using the new 'a ?= b' syntax, to better express the intent that these
provides safe default values which will be used when they are set in
a product-specific mk file.
This is also in preparation for
I9c073a21c8257987cf2378012cadaeeeb698a4fb, which when lands will
prohibit duplicated sysprop assignments.
Bug: 117892318
Bug: 158735147
Test: m
Exempt-From-Owner-Approval: cherry-pick from internal
Merged-In: Ia3528c0c2f9715ff10b85b549d739c9263ab6a7e
(cherry picked from commit 04f86d1cff)
Change-Id: Ia3528c0c2f9715ff10b85b549d739c9263ab6a7e
When DisplayManager sets the DisplayConfigsSpecs with a policy
that the appRequestRange is broader than the primaryRange,
it means that an app can choose a refresh rate from the
appRequestRange and not from the primaryRange only if that app
explicitly specified a frame rate using setFrameRate API. However,
to avoid cases where we switch the refresh rate back and forth from
the two ranges, we are allowing only applications that their window
is focused from WindowManager's perspective to select refresh rate out
the primaryRange. This matches the behavior of an application that sets
the preferredDisplayModeId.
Bug: 144307188
Bug: 159940172
Test: adb shell /data/nativetest64/libsurfaceflinger_unittest/libsurfaceflinger_unittest
Test: YouTube in PIP mode while device is restricted by primaryRange
Change-Id: I26a9690210bb5771bd8aae2bff301031617f7c8f
Bug: 158431662
Test: enable the tracepoint on user build
Change-Id: I0808d8fe6a8416534fbec5a273d668700f0f7129
Merged-In: I0808d8fe6a8416534fbec5a273d668700f0f7129
There seems to be an additional underlying bug that causes the framework
to send a spurious authentication denial, but this is still an
improvement.
Bug: http://b/159061108
Test: treehugger
Change-Id: I7028292fbde157f02cc35c3a37ab5c49d68eaae6
When multiple auth requests come in (e.g. if someone connects over TCP
and USB, or if we send a USB request, and then kill adb and try again),
we need to know the ID assigned to the request to disambiguate.
Bug: http://b/159061108
Test: manual
Change-Id: I68cf2335c5958decf29e58ed9132735577a7e074
In the linked bug, there are traces documenting cases where
the user observes jank while deferred transactions are in play.
We can see several cases where the client gets stuck for a long
time on dequeueBuffer. Around these times we can also see cases where
latchBuffer aborts early due to the !allTransactionsSignaled condition.
We expect all the transactions to be signalled at this point, because
before handlePageFlip we expect to reach handleTransactionLocked,
which should call notifyAvailableFrames, marking the sync points
available based on the head frame number. However if we study the trace
we also see there is an onMessageInvalidate, which contains
a handlePageFlip but does NOT contain the handleTransaction before it
which we would expect. However we know if onMessageInvalidate calls
handlePageFlip (via handleMessageInvalidate) then it must have called
handleMessageTransaction, as these two lines are right next to
eachother. We can thus conclude that we see the problem because
handleMessageTransaction didn't call handleTransaction due to
runHandleTransaction evaluating to false. This makes sense in the
context of recent changes. Previously deferred transactions would set
the transaction flags continuously while they were pending, so the
server would always perform transactions when waking up, and we wouldn't
get in this condition. However, setting the transaction flags
always triggers a wake up! But we don't actually want to wake up until
the frame actually arrives, so first we tried setting the transaction
flags without triggering a wake up. But we found this could prevent
other people from triggering wakeups, so a recent CL modified it to
set mForceTraversal instead. Intending to force that we call
doTransaction from handleMessageInvalidate regardless of whether a
new transaction has arrived (because we need to check if an old
transaction is now ready). However, it didn't quite work because of this
early abort due to runHandleTransaction.
Bug: 159677043
Test: Existing tests pass
Change-Id: I84f2a9cca2ebb3f59d30924efdb39c917f47111b
Currently, in order to detect occlusion input, all buffered layers
would update input info into InputFlinger, so the window may contain
null token, we should check if id is also identical to prevent get the
wrong result
Bug: 159349058
Test: Enable show tap, open bubble and watch logs.
Change-Id: I8412812e9b100988ab380ad64366f2548e50d9e5
Fixes an issue where drawing state could be accessed from a binder
thread. The function also mixed current state with drawing state
incorrectly. The function now only retrieves drawing state.
Bug: 150226608
Test: Steps in bug doesn't repro
Test: atest sffakehwc_test
Merged-In: I04daedcb9a890083cc710bab30b295e14b9872ae
Change-Id: I04daedcb9a890083cc710bab30b295e14b9872ae
Fixes an issue where drawing state could be accessed from a binder
thread. The function also mixed current state with drawing state
incorrectly. The function now only retrieves drawing state.
Bug: 150226608
Test: Steps in bug doesn't repro
Test: atest sffakehwc_test
Merged-In: I5537c53e8214e2785473839d71fd483d1a3219b6
Change-Id: I04daedcb9a890083cc710bab30b295e14b9872ae
Currently, in order to detect occlusion input, all buffered layers
would update input info into InputFlinger, so the window may contain
null token, we should check if id is also identical to prevent get the
wrong result.
Bug: 159349058
Test: Enable show tap, open bubble and watch logs.
Change-Id: Ia1841ba51bce00fc9901fdf7324e8e31d9737082
