Some clients of ASurfaceControl may not set callbacks. We do not want
to call finalizePendingCallbacks in this case.
Bug: 159231312
Test: build, boot, SurfaceFlinger_test, libsurfaceflinger_unittest
Change-Id: I62dc270302a60274d8d1192d0e35ce3f48721e6c
Previously an application process can be specified to load the updatable
driver and the driver path will be set up correctly via
GraphicsEnvironment.java. For a native process that is not an
application process, there's no way for it to be specificed to load the
updatable driver and hence the driver path is not set up. This patch
provides a way for a native process that runs in an environment, for
example shell, where environment variables can be set, to opt into using
udpatable driver by setting UPDATABLE_GFX_DRIVER to 1.
Bug: b/157832445, b/159240322
Test: ./gapit validate_gpu_profiling --os android
Change-Id: I597535caa5ae0a033c2b8d581bb39b14875ac8fc
Merged-In: I597535caa5ae0a033c2b8d581bb39b14875ac8fc
Idle timer is toggled from the SF code using the following logic:
- If the device policy refresh rate min = max, we turn off the timer.
- If the device policy refresh rate min > the device min,
we turn off the timer.
- Do not toggle the timer if deviceMin == policyMin.
- Timer is on in all other cases.
Bug: 140204874
Bug: 158012424
Bug: 145561154
Test: atest SurfaceFlinger_test
Test: atest libsurfaceflinger_unittest
Test: Select force 90hz through Developer Settings. Toggles timer off.
Test: Low brightness zone. Toggles timer off.
Change-Id: I9858765861a3b13e11c3930be8f77d85dae6c0c0
straightforward replacement to use new funcs from BpfUtils.h
Test: atest libtimeinstate_test - proves it builds, and everything fails like before
'git grep bpf_obj_get_wronly' comes up empty
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Original-Change: https://android-review.googlesource.com/1340915
Merged-In: Id2459eca2a66c257e36ffcfb628150da44f90c81
Change-Id: Id2459eca2a66c257e36ffcfb628150da44f90c81
The current handling of eEarlyWakeup is using 2 frames of timeout
in SurfaceFlinger to know when we are no longer in early offset config.
There are few cases where a transaction is dropped or delayed (usually
caused by the offset change itself) which results in switching back
and forth from early offset to non-early offset. This change adds two
new flags, eExplicitEarlyWakeupStart and eExplicitEarlyWakeupEnd that
will be used by WindowManager to indicate when to enter early offset
and when to exit. With these explicit flags, the timings on transaction
no longer matters and we consistently stay at early offset config for the desired
duration.
Bug: 158127834
Test: Quick switch between apps and verify that offset doesn't change
Test: adb shell /data/nativetest64/libsurfaceflinger_unittest/libsurfaceflinger_unittest
Change-Id: Ie10af30a2d8c0f4f21ac7ffed469a74e1bf8dbc1
Multiple layers may set eTraversalNeeded during Layer->doTransaction.
If a prior layer doesn't wish to wake up SF, setting eTraversalNeeded
may block a later layer from triggering a wake-up. Set
force transaction instead to trigger doTransaction at a later
time.
Bug: 158409746
Test: build, boot, manual, SurfaceFlinger_test,
libsurfaceflinger_unittest
Change-Id: I6a43eb53323073361c5b1ebe87e4ceb8a6d3f120
This change removes the cached state in SF which is not managed
properly. This state is also cached in HWComposer.
More specifically, SF caches the primary display vsync state in
mHWCVsyncState. However executing DisplayDevice->disconnect()
turns off vsync w/o updating the cache. This way if we
process a subsequent hotplug event for the primary display
we can end up a situation where the cached state is "enabled",
but the actual state is "disabled". Then Scheduler won't be
able to turn on HWC VSYNC again.
Test: manually test on a TV which sends two
subsequent hotplug events at boot. Verify that
after applying this change the TV doesn't
run at 1 fps.
Test: atest libsurfaceflinger_unittest
Bug: 156331731
Change-Id: I85e72d8d5ba85f0a5f4b4f27a200c1bde4e0b9f4
If the list of windows being interacted with changes, log the new list
to event log.
Example logs:
06-08 15:47:55.349 4105 4181 I input_interaction: Interaction with windows: ee638df NotificationShade (server),
06-08 15:48:03.917 4105 4181 I input_interaction: Interaction with windows: 399b259 com.google.android.apps.nexuslauncher/com.google.android.apps.nexuslauncher.NexusLauncherActivity (server),
06-08 15:48:10.844 4105 4181 I input_interaction: Interaction with windows: fcc1e60 com.android.systemui.ImageWallpaper (server), 399b259 com.google.android.apps.nexuslauncher/com.google.android.apps.nexuslauncher.NexusLauncherActivity (server),
06-08 15:49:30.091 4105 4181 I input_interaction: Interaction with windows: ee638df NotificationShade (server),
06-08 15:49:31.757 4105 4181 I input_interaction: Interaction with windows: fcc1e60 com.android.systemui.ImageWallpaper (server), 399b259 com.google.android.apps.nexuslauncher/com.google.android.apps.nexuslauncher.NexusLauncherActivity (server),
06-08 15:49:33.293 4105 4181 I input_interaction: Interaction with windows: <none>
Bug: 153092301
Test: adb logcat -b events | grep -i input
Change-Id: Ia4216beb200163e60e05374b6ea363412bff55f3
Merged-In: Ia4216beb200163e60e05374b6ea363412bff55f3
Previously, when the touched window was unresponsive, we skipped adding
the gesture monitors to the touch targets. That means, when an app has
ANR, gesture nav stops working, and the phone feels frozen, until the
ANR dialog comes up.
Another failure mode was a stuck pending event. If there is no focused
window, and we have a pending key event (or any focused event), we will
be waiting for a focused window to appear. That would still prevent
gesture monitors from receiving further touch events.
In this solution, we do not add unresponsive windows to the list of
targets, but we still proceed with handling the event, meaning that the
app won't get a new DOWN when it is unresponsive, but the event would
still go to the gesture monitors.
That change, in isolation, would also break ANR for the case when the
app loses focus. To maintain the ANR functionality, we extend the ANR
detection mechanism to all connections. Now, every connection is
eligible to receive an ANR, even if it's a gesture monitor. We expect
everything in the system to be responsive within reasonable timeouts.
We also change the handling of extended ANR timeouts coming from policy.
Today, the behaviour is as follows:
1. If the policy says "wait longer", then we do nothing and just keep
waiting
2. If the policy says "abort", then we send the cancel events and remove
the window from the window list.
The "abort" approach seems incorrect, because the policy will probably
not register the existing inputchannel/connection with a new window. If
the user does click "close app" when the ANR dialog appears, we will
anyways receive "window removed" event via setInputWindows, and will
clean up the connection that way. So we don't really need to do anything
other than sending "cancel events" to the window.
The policy now for sending events to unresponsive windows becomes:
1. If the unresponsive window is touched, the new touch stream does not
go to the window. It will go to all other places, though.
2. If the unresponsive window receives a focused event, the event still
gets queued for the unresponsive window to handle.
For improved ANR performance, the ANR detection is now done by
introducing a helper data structure, a multiset of the timeout times.
Whenever we send an event to a connection, we will calculate the time
that this event will cause a timeout. We will then add this time to the
multiset of times. When we check for ANR inside dispatchOnce, we will
only access the smallest (soonest) timeout inside the multiset. If the
current time is before this smallest timeout time, then everything is
normal, and we move on. This would cost O(1).
If the time is past the timeout time, it means a connection is
unresponsive. In this case, we take the closest in time unresponsive
entry. That entry already has the connection token, for convenience.
We then raise an ANR on that connection.
The entries are removed from the multiset in several cases:
1. When we receive a 'finished' signal on an entry for a specific
connection
2. When the connection becomes unresponsive and we raise ANR. In that
case, no need to keep checking on the same connection. Once case 1.
applies to that connection, entries from that connection will again
become eligible for being added to the multiset.
3. When we reset and drop everything.
4. When we cannot find a connection for an entry in the multiset, we
will drop all entries from that connection.
If we report ANR for an app, we do not report the second ANR until the
waitQueue becomes healthy first and then becomes clogged again.
If we have a focused application, but no window has focus, then nothing
will happen for pointer events. They will keep going to the touched
window as normal. When we receive the first focused event,
however, we will start a timer. If there is no focused window added by
that time, we will send an ANR for that application. This logic should
be moved into WM later, because from the input perspective, it is
legitimate to have an application without a focused window. This would
also allow WM to remove the "setFocusedApplication" call.
Bug: 143459140
Test: use the test app from the bug. The app sleeps for 10 seconds when
the button is clicked. Click the button, and try to use gesture nav
several times. Observe that gesture nav continues to work even after app
has ANR.
Observe that ANR is reported even after interacting with gesture nav.
Test: Click on the app multiple times (to clog up the queue), and then
wait for a long time, even after the ANR dialog shows up. Then click
"wait" to not close the app. Then click again on the app. Observe that
the anr dialog appears after a while. This indicates that at some point,
the app processed all events, and then became eligible for anr again.
Test: adb shell -t /data/nativetest64/inputflinger_tests/inputflinger_tests
Test: create an app that sets "FLAG_NOT_FOCUSABLE" on its only window.
Launch the app and interact with it by touch. Notice that the app does
not ANR. Then, send the back key to the app (using the back gesture).
Notice that in 5 seconds, we receive an ANR for this app. While the BACK
key is queued up for this app, the gesture nav continues to work and the
notification shade can still be pulled down.
Change-Id: I2c0fd1957cda833f5fbe26368cfcaa6fea6eddaf
Merged-In: I2c0fd1957cda833f5fbe26368cfcaa6fea6eddaf
Currently, mTempTouchState is a class variable, and it is confusing when
it is being modified in functions such as findTouchedWindowAt.
This variable is only used inside findTouchedWindowTargets, so convert
it to a local variable. This will make it easier to keep track of its
contents.
Bug: 142017994
Test: none (this is a cherry-pick)
Change-Id: I8b4f45eadf0ba05e5979de39f78ba81fe79bce31
Merged-In: I8b4f45eadf0ba05e5979de39f78ba81fe79bce31
To modernize the code base and increase readability, use
std::unordered_map instead of KeyedVector inside InputDispatcher. This
helps understand the code flow, and allows some foreach expressions,
thus removing shadow variables.
Bug: 142017994
Test: presubmit
Change-Id: I969fc03dc38e258e9f3d0f2e60c9534515ce2926
Merged-In: I969fc03dc38e258e9f3d0f2e60c9534515ce2926
The function is already static, but it's marked as if part of
InputDispatcher. Make it clearly static by moving out of
InputDispatcher.h
Bug: 142017994
Test: none (this is a cherry pick)
Change-Id: I098e86453b7bb8261e08f7fce671db173e2136b0
Merged-In: I098e86453b7bb8261e08f7fce671db173e2136b0
Averts a rare race condition by which a callback would be moved back a
vsync period inappropriately by rearming the callback-dispatching timer
only when the next-up callback was the one that was cancelled.
This was an analagous problem (but through the cancel() path) to
I0e7e2e3698ed6d1765082db20d9cf25f6e6c2db2
Test: 2 new unit tests
Test: boot to home, inspect for problems
Test: dogfood patch on device
Test: A/B uibench sanity check
Fixes: 154303580
Change-Id: I02b2ba12623ac683d9b1c592fdc35e7c7494261a
-o argument was previously removed in favor of new api and consent
dialog but now it is being reintroduced to go along with limited mode
dumpstate logs that do not require user consent.
This argument is effective only during limited mode but we do not throw
an error if supplied with other arguemnts for backwards compatibility
reasons.
Bug: 142684959
Bug: 136273873
Bug: 139379357
Bug: 138805202
Bug: 142685922
Test: adb bugreport
Test: adb bugreport xyz.zip
Test: adb shell bugreport
Test: atest dumpstate_test
Test: flash android to dut, android-sh, setenforce 1, arc-bugreport
Change-Id: Ib2cadf13c101dd2e957033a7657a647d043f2b72
For legacy compatibility reasons, we allow apps to receive input prior
to submitting their first buffer, and for this reason we check
canReceiveInput() to populate InputWindowInfo#visible, rather than
directly calling isVisible(). However, in the case of layers which
can't receive input (!hasInputInfo()) and are exclusively being used
for occlusion detection we have no such legacy requirement and so we can just
directly check the visibility value. Obviously this doesn't
cause any problems with occlusion detection, since if the layer
isn't being drawn it can't occlude anything. This semantic is
very useful as it allows BufferLayers which no buffer drawn to be used
as ContainerLayers, as we frequently use SurfaceView for.
Bug: 157772682
Test: Existing tests pass.
Change-Id: Iadcd5d8fc4016ee1f88480a50bb3555797830560
First a review of history. In previous releases there was no PID
consideration in occlusion detection. In a recent patch set we
introduced sending InputChannel-less surfaces from SurfaceFlinger
to InputDispatcher for more complete occlusion detection. As part
of this process we introduced the ownerPid check that is modified
in this CL. We added this because otherwise SurfaceView would begin
occluding their parents, and this would be a compatibility break (and
also not very useful). When adding this line we also added the
token == null check. This was to preserve a previous semantic
where windows from the same ownerPid would occlude eachother in
previous releases. There was no known dependence on this semantic,
it was just easier to add the line to preserve the old behavior than
think about changing it. In light of the linked bug, we see a use case
for changing it. On further consideration, it seems not a useful thing
to preserve, as there are no security boundaries within a process
and the ability for an app to truly depend on this behavior is
very small.
Bug: 157772682
Test: Existing tests pass
Change-Id: Ife2a5a9fce35e04bb794d79b3a1b875859deb8dd
There was a case that Media enabled HDR10PLUS in validTypes without
passing any metadata.The patch handles the error to avoid the crash of
SurfaceFlinger.
Bug: 157868992
Test: atest android.mediav2.cts.CodecDecoderSurfaceTest
Change-Id: I57275672ef2fe8079e652094e77a0a50de10c5b9
This change fixes a condition where a configChanged event
will be dropped due to idle timer.
Change-Id: I803f478c261be9fceb3495526576b495d7d0f385
Bug: 155367075
Test: CtsGraphicsTestCases
When calculating layer's refresh rate heuristically, also store
a history of the last refresh rate calculated. We use this list to
determine how consistent is the refresh rate. If the refresh rate is
not consistent, then we keep reporting the last consistent refresh rate
and wait for the refresh rate to stabilize again.
Test: Play at 60fps video in XPlayer
Bug: 157540021
Change-Id: If3b525820d298cc5835dddf73f327501c8a18964
Adds a -L commandline option to indicate a much smaller set of
dumpstate output safe for feedback reports.
Implements output of system logcat, event logs, networking, and dropbox
system server crash/system app crashes only.
Bug: 142684959
Bug: 136273873
Test: atest dumpstate_test
Change-Id: I1d564b949d0a44ff9cc014302d79703294a13d78
Requantizing by resolution / 4 causing the calibration error / min on
calibrated sensors to be too high. Changing to 8 reduces that error
enough to keep sensor accuracy below our thresholds.
Bug: 158451802
Test: Verify that calibration error / min is low
Change-Id: I350980734cc0a46f4f06878371e0d9bd7ce07de0
This avoids a race where we decrement the early offset count in
postComposition() before the transaction applying early offsets has
actually been applied, so we're in early offsets for too few frames.
Bug: 158127834
Test: photos launch
Test: systrace
Change-Id: If7a7d12fa466ee4d163210263b7f02f7a74b3280
This refines the logic added in
I79c66faeaed262acd9c5925fe2202a9fb3f10b7b, which started ignoring
Composer-provided refresh rates on vsync callbacks when the kernel idle
timer is enabled.
This behavior is still correct when SF doesn't think that that refresh
rate has changed, but when we initiate a change, such as when the only
active layer is infrequently updating, then it's okay to rely on the
Composer-provided rate.
Bug: 158141901
Test: atest libsurfaceflinger_unittest, systrace
Change-Id: I16c87005f5cd1ca1810014211d73b4662e7c8c86
