Rename Gralloc0Allocator to Gralloc0Hal and make it inherit from
AllocatorHal. Do the same to Gralloc1Allocator. Add GrallocLoader
to load either of Gralloc[01]Hal and create a IAllocator instance.
Test: boots and VTS
Change-Id: I09ae680c0086ca9e73e412a34d7cd2f3665d3bc2
Convert the default impl into a static library,
android.hardware.graphics.allocator@2.0-passthrough.
Test: boots and VTS
Change-Id: I8ec8b30766462ecb3fb789af7c6dbb3c088ccf57
Add a header-only library
android.hardware.graphics.allocator@2.0-hal that can be used by
implementations. An imlpementation can
class VendorHal : public AllocatorHal { ... };
auto allocator = std::make_unique<Allocator>();
allocator->init(std::make_unique<VendorHal>(...));
Or, if vendor extensions are to be added to the IAllocator,
class AlocatorHalExt : public AllocatorHal { ... };
class VendorHal : public AllocatorHalExt { ... };
class AllocatorExt : public AllocatorImpl<IAllocatorExt, AllocatorHalExt> { ... };
auto allocator = std::make_unique<AllocatorExt>();
allocator->init(std::make_unique<VendorHal>(...));
Test: builds
Change-Id: I7cb7a4888316b871e5c49d96524b1642fc708f2d
Move libgralloc1-adapter from 2.0/default/ to
2.0/utils/gralloc1-adapter/. Fix build issues after the move.
Test: builds
Change-Id: I674fe60c724a4ffc1540c796b92209a1dbf36438
The interface lib has been in VNDK-SP because
android.hardware.graphics.mapper@1.0 was using it. However, since the
dependency has gone [1], there is no need keep it in VNDK-SP. The
VNDK-SP set should be kept as small as possible because libs in VNDK-SP
are subject to double-loading.
Unmark the 'support_system_process' property to exclude the lib from
VNDK-SP.
This commit re-lands I8722c1ac15ddf56a627a12a0c649b4d734e5e5cd because
it was reverted during O-MR1 push to AOSP-master.
Bug: 69480083
Test: walleye boots to the UI
Change-Id: I0af8115dceb9711c6c451ffaeedda6c823ec2905
Merged-In: I8722c1ac15ddf56a627a12a0c649b4d734e5e5cd
(cherry picked from commit ec44d18dbe)
There is no cap defined for PRESENT_OR_VALIDATE_DISPLAY in HIDL so
it must always work. Make sure it does not call HWC2 presentDisplay
when the underlying HWC2 does not support
HWC2_CAPABILITY_SKIP_VALIDATE.
Bug: 70407085
Test: boots
Change-Id: I54a4400e09e669c5064f05739f595ed978dcc713
Removing whenever I see these in code reviews.
Test: none
Merged-In: I4322f533a837d55618ec2ed2125e8966ace9d61d
Change-Id: I4322f533a837d55618ec2ed2125e8966ace9d61d
FB (framebuffer) HAL has been replaced by HWC HAL for 5+ years, but
we still support the legacy path in SurfaceFlinger. Devices using
the legacy path cannot be Treblized.
This change allows such devices to use HIDL IComposer, by adding
support for FB HAL in the default implementation.
Test: boots hikey960
Change-Id: Ie9050bbcaac0fd5b134786f4f9f0f5075f4ebd0c
After initialization or onRefresh, we want to make sure
validateDisplay is called before presentDisplay.
Bug: 67505273
Test: manual
Change-Id: Id876d9251586aaaf552ca82c52f8f902af364251
The hardware composer service has a rule that only one client can be
connected at a time. The surface flinger process, when transitioning
composer ownership from surface flinger to vr flinger, will destroy the
current client on one thread and create a new client on another
thread. Although surface flinger ensures that these events happen in the
expected sequence (delete then create), the requests sometimes land in
the hardware composer service in inverted order, causing the creation
request to fail with an error.
Instead of failing with an error, block for a brief period (1 second)
until the existing client is removed, then proceed to initialize the new
client. This gives us enough time to ensure an inverted
creation/destruction order doesn't cause client creation to fail, while
avoiding a deadlock if the existing client is never destroyed.
Bug: 62925812
Test: - Transitioned to/from vr flinger hundreds of times, and confirmed
I no longer see sporadic composer client creation failure due to an
already existing client.
- Ran the vts graphics composer tests and confirmed they all pass.
Change-Id: I40be1fb0cb3d42ddb5a9fc159188886e9f5b6267
Our use of message queues is synchronous. If there are already data
in the queue when writeQueue is called, we know they are stale and
can be discarded.
Bug: 65449888
Test: manual
Change-Id: Ie29b8a7386c9733c183a6c3569e3572efa62cbc2
* For registerTestService/getServiceName, no need to pass
any hard coded string of HAL service FQName.
* Affect test: VtsHalCameraProviderV2_4TargetTest,
VtsHalGraphicsComposerV2_1TargetTest,
VtsHalNeuralnetworksV1_0TargetTest
Bug: 62946472
Bug: 64203181
Test: make vts
vts-tradefed run vts -m VtsHalCameraProviderV2_4Target
Merged-In: If365ab2ed9a91eb4013d71769804b9d4bf089d66
Change-Id: Id0bddbc2949337147557f45cc60dbfaa114ce25e
(cherry picked from commit d71b654d6d)
This reverts commit 8ac1971678.
Reason for revert: Didn't remove automotive changes from this CL.
Merged-In: I8608c8f636c35f21e4246a805a9eff6d14124e0a
Change-Id: I1c660cffc8817ad0b33da9f6eceb3d88e7c48416
These tests now statically links to HAL def libs which are
not guaranteed to be on the device.
Bug: 64040096
Test: vts-tradefed run commandAndExit vts --skip-all-system-status-check
--skip-preconditions --module VtsHalGraphicsMapperV2_0Target
Test: vts-tradefed run commandAndExit vts --skip-all-system-status-check
--skip-preconditions --module VtsHalGraphicsComposerV2_1Target
Change-Id: I83b68dafbd161f88394f67dbda14f9957ddf7232
vndk-sp is not automatically tagged by hidl-gen.
For vndk-sp libs, "support_system_process: true" is manually added
in "vndk" property.
Bug: 63866913
Test: build and boot with BOARD_VNDK_VERSION=current
Change-Id: I2b18d691411e58dc55bcdfa39ecb3659242c8437
Update the Android.bp generated with hidl-gen.
Test: build with and without BOARD_VNDK_VERSION=current
Bug: 63866913
Change-Id: I1a9db1df49e0f13c5790da2b118ae9ec63ba34a7
