This fallback loading path was for backwards compatibility with devices
being upgraded from pre-Oreo (i.e. pre-Treble) to Oreo or later. Those
devices weren't required to follow a lot of the Treble rules, so linker
namespaces (or binaries compatible with them) couldn't be enforced. This
change removes it so that we can discover issues around loading Vulkan
driver from sphal namespace.
Bug: 156021362
Test: build, flash and boot
Change-Id: I505bdbdb40a06e1d837f1d0b75822b0c60de96c9
To follow the code style, rename ANR -> Anr, because we are about to add
a lot more ANR-related stuff, and we don't want to keep adding new code
that doesn't follow the code style.
Bug: 143459140
Test: build only
Change-Id: I5a97ba4dcd8baa8a34fbb790e68fb63fd3c3ca75
There is a lot of confusion in input tests about the units used for the
timeouts. In a lot of cases, the timeouts are set too short, which
causes failures when they start getting enforced. To avoid this, use
std::chrono::duration for the timeouts.
Ideally, we should convert InputWindowInfo and InputApplicationInfo to
use std::chrono::nanoseconds, but that would be a larger change reserved
for a future release.
Bug: 143459140
Test: atest inputflinger_tests libinput_tests inputflinger_benchmarks
Change-Id: Ie7536e8a042a71b372f03314501e0d635a6ac1d4
Currently, I'm observing some strange behaviour, where calling
setInputWindows twice results in the touchable region becoming empty.
Add this test to R to see what's going on, and potentially bisect on
this.
Bug: 143459140
Test: atest inputflinger_tests
Change-Id: Ia0acef5d4ee4acc29d20174fe44c9f94172ccd96
An input channel specifies the file descriptors used to send input
events to a window in another process. And All of the file descriptors
open in the calling process shall be closed when process terminated.
The server side could receive the socket broken event when the process
terminated, we should do the unregister channel before close the file
descriptor or do it automatically without error if there is no valid
window.
Bug: 133782251
Test: open app and exit by back key or recent apps, check if any
error log occurs.
Change-Id: I59d0084c2c771544e7ee226ce53c574f60c6b988
Layers with geomBufferUsesDisplayInverseTransform set (usually layers
showing a camera preview) were not being rotated correctly on external
displays with hardware composition. Forcing GPU composition avoided
the issue, since BufferLayer.prepareClientLayer() uses the *primary*
display's orientation to create the inverse transformation.
But, the HWC path used each screen's orientation, resulting in a bad
layer rotation when the primary and external displays' orientation
differed. So let's do what the GPU path does.
This, of course, only makes a difference when the primary and secondary
display rotations differ. In our case, we noticed the problem when
running the landscape-oriented CinemaPro app, while our default camera,
which runs in portrait, did not have a problem.
Co-authored-by: Mikael Magnusson <mikael.magnusson@sony.com>
Note: This is an updated version of the change with the same Change-Id
as uploaded to AOSP, as refactoring has continued, and more tests were
added since.
Bug: 155329360
Test: the new unit test fails without the patch
Test: the new unit test passes with the patch
Test: record using Cinema Pro app with an external screen
Reference: I0da22423490a93fe943fd59e6c122aa6aaf30b11
Change-Id: I8b4975a14a0ae42d10e4eeaa66385e72ff00c23d
When input receives a list of windows from surfaceflinger, each window
has a unique id. But when we run tests, all ids are the same. This
causes some unexpected test failures for the cases where we have more
than 1 window per display.
To avoid this issue, mirror the surfaceflinger approach of generating
the ids by keeping a static variable that gets incremented every time we
create a new window
Bug: 143459140
Test: atest inputflinger_tests
Change-Id: I36731e78e16892b4bf48d6eba8db3e4c2684b54d
To match the logic that always queues a buffer if the HWC has a
flipClientTarget request for the current frame, we must also always
dequeue a buffer, even if no client composition is being performed.
This is an port of an (as yet uncommitted) AOSP change with a ChangeId of
I933cbae2f09f81eef6555b1bb1e5991d2c450930, due to the underlying code
having been refactored.
This version also adds and updates unit tests which were added as part
of the refactoring.
Bug: 151698217
Test: libcompositionengine_test
Test: libsurfaceflinger_test
Change-Id: Ia8a1470affb2596b27986cc4153417f48cf4ed1c
Fix the side effect after we split notification_shade window from status
bar.
Bug: 155373298
Test: follow the steps from b/149320322
Change-Id: I3362186b22505d21ec6e0ad779d4a26304ed782c
Merged-In: I3362186b22505d21ec6e0ad779d4a26304ed782c
When the non-kernel idle timer is used, touch boost wasn't being applied
when the device was idle. I moved the code around to ensure touch boost
is applied when the device is idle.
Bug: 154571341
Test: - Wrote a new unit test to confirm correct idle behavior.
- Locally modified a Pixel 4 to use the regular idle timer rather
than the kernel idle timer, and confirmed we now apply touch
boost correctly.
Change-Id: Id998405a4d79f7a89fc0523b6503fe1a3dea8cce
Print frame rate if explicitly set by setFrameRate to dumpsys
Bug: 155676501
Test: adb shell dumpsys SurfaceFlinger
Change-Id: I1016f8a56921f7f465ca50298f49d05b02be585c
Revert submission 10829580-isUidForeground
Reason for revert: In CameraService.cpp, before this change, around "am.isUidActive", there was up to 300 ms retry. After this change, the code could move forward fast without retry, but at "mAppOpsManager->startOpNoThrow" call, for the same reason as uid is not updated fast enough, "mAppOpsManager->startOpNoThrow" could also fail.
This CL does not really fix the root cause, but it changes the timing and now the code fails at "mAppOpsManager->startOpNoThrow" call.
Also the timing change may also cause recent multiple CTS test failures.
Bug: 154570809, 155032617, 154849083
Reverted Changes:
Iffed63293:Add isUidActiveOrForeground() for camera/audio to ...
I3685e0c8d:Add isUidActiveOrForeground() for camera/audio to ...
I51ed1fe78:Add isUidActiveOrForeground for camera/audio to us...
Change-Id: I9fbeb190c5a0ac640ad5be8140fe4aaeb7cfe33d
For easy transition from SchedTune to UtilClamp, direct access to these
cgroups should be abstracted by using task profiles. Replace writepid
commands with new task_profiles command.
Bug: 155419956
Test: change .rc file and confirm task profile is applied
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I3e06e25a75cf79674d8381b3356c64790fd5a597
Merged-In: I3e06e25a75cf79674d8381b3356c64790fd5a597
android::base properties work on host and are generally more concise
than cutils properties.
Also, add libbase to egl_libs_defaults. This does not actually add
another dependency because libbase is already a dependency via
libbacktrace.
Bug: 155436554
Test: atest libEGL_test
Test: build, flash and boot
Change-Id: Ibf66e01ce93524eaa29098ae9c57bc6452133f76
Clean up cutils/properties.h headers as some files were including it and
not using it.
Also update DebugEGLImageTracker to use android::base properties because
it works on host and is generally more concise.
Bug: 155436554
Test: build, flash and boot
Change-Id: I1dc7060cae9811b69aac9bb36b71b69cd6ecba93
When analyzing profiles for dexopt, use the boot image profile format
if the system is configured to profile the boot image.
Test: atest installd_dexopt_test
Bug: 155423653
Change-Id: I83ff959389bafcfce291485f78e1b05d6ca42625
To prevent low-priority refresh rate considerations from overriding the
app frame rate as specified via the new setFrameRate() api, split the
display refresh rate range into "primary" and "app request" ranges. The
primary range includes the low priority considerations, while the app
request range removes two lower priority considerations.
In general, surface flinger will keep the display refresh rate within
the primary range, but layers with frame rate settings via the
setFrameRate() api may cause surface flinger to pick a refresh rate
outside the primary range. Surface flinger will never choose a refresh
rate outside the app request range specified by display manager.
Bug: 148978562
Test: - Added a new unit test to DisplayModeDirectorTest to verify that
display manager strips lower priority considerations when
deciding the app request range.
- Added a new unit test to RefreshRateConfigsTest to verify
RefreshRateConfigs handles the primary vs app request range
correctly.
- Manual test: Confirmed that with the "force 90Hz refresh rate" option
turned on, we don't switch to 60Hz when playing a 60Hz video.
- Manual test: Confirmed that with the "force 90Hz refresh rate" option
turned on, when an app calls setFrameRate(60), we stay at 60Hz.
- Manual test: Modified a Pixel 4 XL to prefer 60Hz in low brightness,
entered low brightness, and confirmed we don't touch boost to 90Hz.
- Manual test: Confirmed that Maps stays at 60Hz on Pixel 4.
- Manual test: Turned on verbose logs in RefreshRateConfigs.cpp,
confirmed they look good.
- Manual test: Inspected dumpsys output, confirmed the primary and
app request refresh rate ranges are printed correctly.
Change-Id: Ib16cc9b6158efa575cdbfbb7a0ad014008a3e5af
If app dequeues too many buffers, then dequeueBuffer will return
INVALID_OPERATION. When ANI is called with a timeout which isn't
UINT64_MAX, ANI shouldn't return VK_ERROR_SURFACE_LOST_KHR.
Bug: 146534593
Bug: 155421312
Test: dEQP-VK.wsi.android.swapchain.acquire.too_many
Test: dEQP-VK.wsi.android.swapchain.acquire.too_many_timeout
Change-Id: Ie8ad8edb4632378247b9cbb715ed6eb7134ababb
Revert submission 10449863-revert-fatvector
Reason for revert: b/149254345
Original change (of introducing FatVector) was reverted as a stop-gap solution to fix the aforementioned bug.
The bug was caused by an ABI lock between Surface's definition (that changed with Region) and lib-imsvt prebuilt.
Enabling this change now as we have re-compiled the prebuilt with the change enabled. Doing that via a revert of the revert.
Reverted Changes:
I8ac66acb8:Revert "hwui: remove FatVector"
Ib60dbf3ef:Revert "libui: rewrite Region with FatVector"
Original changes:
I09dc2fddd:hwui: remove FatVector
I265c6c831:libui: rewrite Region with FatVector
bug: 149254345
Change-Id: I723283a952e0908f595967af0037b0dc1351671b
These logs are critical to understand the operation of the system, and
do not spam (1/hal start or 1/hal request). Most importantly, if a
manifest fails to be read for whatever reason, this is logged (null
manifest case).
Bug: 151696835
Test: boot, and verify logs of successful hal retrivals
Test: boot, and verify logs w/ patch which causes VINTF to fail the
first time, and verify that this causes a single crash which gives us
the ability to still find and detect a critical error, but allows the
system functionality to continue to work.
Change-Id: I0a26b875947878656d6eda03ffebce97ebb6139e
Merged-In: I0a26b875947878656d6eda03ffebce97ebb6139e
See details in TODO.
This hack is either causing a bug or may be preventing us from solving
another bug. Until the more critical bug can be fixed, avoiding
early-boot reads of VINTF manifest files.
Bug: 151696835
Test: run, boot, check manifest logs that HAL services register
Change-Id: Iba34afe451026a30e695d6728b4172007aaf7fbd
Merged-In: Iba34afe451026a30e695d6728b4172007aaf7fbd
We use synchronous transactions and synchronous input commands so that
the caller can block until after the transaction has executed. However
the current implementation blocks all other callers. This isn't required
and could create performance issues or binder exhaustion issues so
this CL modifies the code so only the calling thread will block.
Bug: 154443842
Test: Existing tests pass
Change-Id: I556497b1a48de5add753f4de09227b16ca1fc428
