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.
Bug: 69480083
Test: walleye boots to the UI
Merged-In: I8722c1ac15ddf56a627a12a0c649b4d734e5e5cd
Change-Id: I8722c1ac15ddf56a627a12a0c649b4d734e5e5cd
(cherry picked from commit ec44d18dbe)
Spurious wakeups can cause the test thread to return even if the
callback was not actually called as the usb_count isnt initialized.
Bug: 65469351
Test: mma and pushed locally to the device & tested.
--skip-preconditions --module VtsHalUsbV1_0Target
Change-Id: Ib0e838cf4a44807142eab6aa5e9df0cc462bb973
Remove self from test ownership and transfer to new owners as agreed.
Test: none
Bug: 69425312
Change-Id: I8b189e6f2d7076b9ee7f3bad91445ccf6c5e1767
Merged-In: I8b189e6f2d7076b9ee7f3bad91445ccf6c5e1767
OpenSSL changes error code of large RSA data from
KM_ERROR_INVALID_INPUT_LENGTH to KM_ERROR_INVALID_ARGUMENT which causes
HidlHalGTest#EncryptionOperationsTest.RsaOaepTooLarge and
HidlHalGTest#EncryptionOperationsTest.RsaPkcs1TooLarge tests failed.
Fix keymaster VTS to accept both the error codes.
Bug: 68289922
Test: HidlHalGTest#EncryptionOperationsTest.RsaOaepTooLarge and
HidlHalGTest#EncryptionOperationsTest.RsaPkcs1TooLargeHidlHalGTest#EncryptionOperationsTest.RsaOaepTooLarge
and HidlHalGTest#EncryptionOperationsTest.RsaPkcs1TooLarge are
passed after applying this modification and other Keymaster 3.0
VTS test cases are not affected.
Change-Id: I493bfa1c6e4b69560dfae3585a416b5c3d33e215
Analysis: VtsHalRadioV1_0Target's timeout is too short for
getAvailableNetworks, because this request duration depends on NW
environment or frequency.
Suggested solution: Add a timeout parameter to wait() and default
timeout value is 5 minutes in order to avoid timeout fail due to NW
environment.
Bug: 68834032
Test: getAvailableNetworks can be passed after we apply this patch and
test result for all other telephony 1.0 and 1.1 test cases are not
changed.
Change-Id: Iaae71e0abacd28275d86a19264813ff209ddb79c
Transitive includes accidentally added by hidl-gen
were getting added to import lists. This import isn't
actually required and is now properly excluded from
hidl-gen update makefiles.
Bug: 65055216
Test: none
Merged-In: I4fb4de8ef5547a3081cd55b3c75f6288cc518ba6
Change-Id: I4fb4de8ef5547a3081cd55b3c75f6288cc518ba6
OUT is only defined if some functions in envsetup.sh are run, which is
not the case on the build servers. I'm looking at removing the
environment variable in local builds to keep things consistent.
In this case, OUT_DIR was actually expected, not OUT, which is
equivalent to PRODUCT_OUT.
Test: none
Change-Id: I1e5e9f40727104716212d696927d1a32d7a74fab
Merged-In: I1e5e9f40727104716212d696927d1a32d7a74fab
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
Automatic mk -> bp conversion for all modules here
which can be converted and built automatically.
Test: Soong resolves all dependencies
Bug: 37512442
Change-Id: Ib789212cb88d55731397c600d132e7c672c0d8be
