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)
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
Allow HAL definition libs to be static.
Bug: 32920003
Bug: 64040096
Test: update-all-google-makefiles.sh
Change-Id: I1483d572bea6799717d1614fb7d52fe225e31104
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
We should call native_handle_clone instead of IMapper::importBuffer
on sideband stream handles.
Bug: 63707399
Test: manual
Change-Id: Ie07e50f6bb771f3c7a69d29e36f60b149dc6af95
This reverts commit 33c08a53ac. Some
gralloc implementations apparently have library initializers (executed
on dlopen) which create anonymous sockets, open device nodes, etc.
which Zygote and some other non-Zygote-child processes that use libui
don't have permissions to do. When the library initializer fails, it
crashes the process.
Reverting this until this initialization code can be made lazy (on
first use of gralloc).
Bug: 62732270
Test: boot fugu to launcher
In the a.h.graphics.mapper default implementation, load the gralloc
module in a static constructor that runs when the library is loaded.
This causes Zygote to load the gralloc module and its dependencies
when it loads a.h.graphics.mapper, so that it doesn't have to be
loaded during each activity launch.
Bug: 62353585
Test: boot to launcher, run calculator, confirm gralloc library is in
/proc/`pid zygote64`/maps
Change-Id: I56defd76b0ba0fba71dea48e2b0d338511563d1f
BufferUsage::SENSOR_DIRECT_DATA should be filtered out for consumer
usage. BufferUsage::GPU_DATA_BUFFER should be filtered out for
producer usage and be translated to
GRALLOC1_CONSUMER_USAGE_GPU_DATA_BUFFER for consumer usage.
Bug: 62491483
Test: boots
Change-Id: I171712adf45ae80dadeed7997fb9872ff176fa1a
Split up utility classes that can be re-used in other IComposer related
tests (such as the IVrComposerClient tests).
Changes:
* Move GraphicsComposerCallback into separate module
* Extract TestCommandReader in separate module
* Extract Composer::execute() from test class
Bug: 38203529
Test: Compiled
Change-Id: I0d1193469e9dd94c477a63058f98111c162dfa99
There are implmentations that can dead lock when calling certain
functions in certain states. It works fine before HIDL because
SurfaceFlinger calls those functions in another thread. We allow
for 4 hwbinder threads in this commit to simulate how SurfaceFlinger
calls hwcomposer.
Bug: 38183197
Test: camera, videos, multi windows, screencap, screenrecord
Change-Id: Ie05b2ca349b8c1ed9a3ac962981434f2efee92d9
This should help buffer allocation performance. We choose 4 because
that is the number of binder threads in SurfaceFlinger.
Bug: 38243574
Test: manual
Change-Id: I704aacb271fb7fd6a91c9231ab8a5256531eebc9
android.hidl.base@1.0 and android.hidl.manager@1.0 are built into libhidltransport.
Test: links
Bug: 33276472
Merged-In: I08aaad80f7e2fc262aa3a8b66fe932e8133a928d
Change-Id: I08aaad80f7e2fc262aa3a8b66fe932e8133a928d
When setLayerBuffer() was called on a layer previously destroyed by
destroyLayer() the code would crash. Instead, return an error.
Bug: 37159844
Test: Ran vr flinger in a way that would trigger the crash, and
confirmed that I now get error logs instead of crashing. Unfortunately
the error code is consumed by the Composer wrapper class and not
propagated back to the caller, but that's a separate issue (b/37901601).
Change-Id: I75a5b954d47a1deac44d03851f60f347085eca89
android.hidl.base@1.0 and android.hidl.manager@1.0 are built into libhidltransport.
Test: links
Bug: 33276472
Change-Id: I08aaad80f7e2fc262aa3a8b66fe932e8133a928d
Note, current.txt change (as opposed to addition) is only allowed
because this is an unreleased interface.
Bug: 32593292
Test: builds
Change-Id: I95381d1a3a456aeadbc472e2dbbffde19cb43e6c
HALs are not expected to see YCBCR_422_888, YCBCR_444_888,
FLEX_RGB_888, and FLEX_RGBA_8888. JPEG is purely wrong.
Note, current.txt change (as opposed to addition) is only allowed
because this is an unreleased interface.
Bug: 32593292
Test: builds
Change-Id: I432e6cb75cfc347a41e8e1632ae1898eed3350c8
Make the docs more self-contained, not referring to stuff not
defined by the HIDL interfaces.
Mark JPEG, YCBCR_422_888, YCBCR_444_888, FLEX_RGB_888,
FLEX_RGBA_8888 as "MUST NOT USE". These format are never supposed
to be seen by gralloc and do not belong to the HIDL interfaces.
Note, current.txt change (as opposed to addition) is only allowed
because this is an unreleased interface.
Bug: 32593292
Test: builds
Change-Id: Ia7607cc73dd2f58dfa27e71b0004b21c7ca6904d
Sort the enum values in their numerical order. There is no other
change.
Note, current.txt change (as opposed to addition) is only allowed
because this is an unreleased interface.
Bug: 32593292
Test: builds
Change-Id: I47914a7971f922f5602f982b41dd7602842e853b
We must use the mapper HAL instead of gralloc0/gralloc1 from the
composer.
Bug: 37540361
Test: boots on marlin, angler, and ryu
Change-Id: I5a3ff6a025bf51a3507a4f33fa77e9506a6f1ec9
A buffer handle recieved from a HAL is by definition raw and needs
to be imported. But because of passthrough HALs, such a raw handle
may have been imported already. Explicitly specify that an
implementation must accept such a raw handle.
Bug: 37540361
Test: boots on angler, ryu and marlin
Change-Id: I5ecf526e59b27cc4a8f7f5d5ec27477da0946ece
GraphicBufferMapper is valid during process termination. IMapper
must stay valid as well. It should not rely on global/static
objects that may have been destructed.
Bug: 37480313
Test: libgui_test
Change-Id: Icb8079153306f2465c26c0f1ce812895ad83f21b
