HIDL libs are not necessarily part of VNDK now. Because some are
used by VNDK libs, they are still VNDK. But rest are now just
vendor-available.
.hidl_for_test files are also removed because they are used to exclude
test-purpose hidl libs from VNDK libs.
Instead, .hidl_for_system_ext files are added to tests/lazy to
distinguish them from others which are installed /system.
Bug: 143933769
Test: update-makefiles.sh && m com.android.vndk.current
Merged-In: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
Change-Id: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
(cherry picked from commit b0907a6bb8)
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL update suite name vts-core to vts as
the suite name is updated. This CL won't change test logic or behavior.
Change-Id: I562b4dc50765e953800a814a8fd84a01c1b9352b
Merged-In: I562b4dc50765e953800a814a8fd84a01c1b9352b
Convert VtsHalTetheroffloadControlV1_0TargetTest to be parameterized test
and add it to vts-core
Bug: 142397658
Test: $ atest VtsHalTetheroffloadControlV1_0TargetTest
Change-Id: I54a5f0324df88d0e058a31f03d12cc6b6f8292a3
Convert VtsHalTetheroffloadConfigV1_0TargetTest to be parameterized test
and add it to vts-core
Bug: 142397658
Test: $atest VtsHalTetheroffloadConfigV1_0TargetTest
Change-Id: I0023e27fef163364e302b0efc5b139b5a6105123
hidl-generated makefiles are now generated such that bpfmt(file) == file.
Bug: 67417008
Test: enable bpfmt hook
Change-Id: I1f69d292bc23a7cc293a66110cb02d597e1019ad
This test is testing that subsequent calls to stopOffload fail.
Therefore, don't fail if the first call fails. Only fail if the
subsequent calls fail
Bug: 77996655
Test: OffloadControlHidlTestBase.AdditionalStopsWithInitReturnFalse passes
Change-Id: I819a2942cc9bb2bca5cf0f603bb7e2b2b9b03d23
* This allow VTS to test tetheroffload hal against all service
implmentations registered with different service name.
Bug: 64203181
Test: make vts
vts-tradefed run vts -m VtsHalTetherOffloadConfigV1_0Target
vts-tradefed run vts -m VtsHalTetherOffloadControlV1_0Target
Change-Id: I0b4f3cf4abd3ffbd15cef7c2126ce6252a65a28e
Removing whenever I see these in code reviews.
Test: none
Merged-In: I4322f533a837d55618ec2ed2125e8966ace9d61d
Change-Id: I4322f533a837d55618ec2ed2125e8966ace9d61d
Removing whenever I see these in code reviews.
Test: none
Merged-In: I4322f533a837d55618ec2ed2125e8966ace9d61d
Change-Id: I4322f533a837d55618ec2ed2125e8966ace9d61d
The AdditionalStopsWithInitReturnFalse test inits offload and
then checks that stopOffload returns true. However, the HAL is
allowed to return false to stopOffload if no upstream was ever
successfully programmed.
To ensure this test doesn't fail in the common case that the
interface is not up, don't expect stopOffload to return true in
this case.
Bug: 67439856
Test: VtsHalTetheroffloadControlV1_0TargetTest passes with and without mobile data connection
Change-Id: I245f9e3e4376a7799572a3b3967e2bf6c52b5e4d
The tetheroffload HAL is somewhat...and over- and under-specified.
A not unreasonable interpretation is that stopOffload() doesn't have
return success unless offload was actually started (via a call to
setUpstreamParameters()), and that after initOffload() and before
setUpstreamParameters() not actual "offload" has been engaged.
Precision in this matter is not required for the test case:
OffloadControlHidlTestBase.AdditionalInitsWithoutStopReturnFalse
But for the test case:
OffloadControlHidlTestBase.AdditionalStopsWithInitReturnFalse
we want to ensure the "matching" stopOffload call succeeds. For this
test we add in a call to setUpstreamParameters() for good measure.
Test: as follows
prompt$ make vts -j30 BUILD_GOOGLE_VTS=true && \
vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--primary-abi-only \
--skip-preconditions \
--module VtsHalTetherOffloadControlV1_0Target \
-l DEBUG
Observed:
10-16 19:17:17 I/ResultReporter: Invocation finished in 1m 2s. PASSED: 38, FAILED: 0, MODULES: 1 of 1
Bug: 65270149
Bug: 65612227
Bug: 65612332
Change-Id: I924d41f5a20f07707e3d6991cb59d9c6b2b02339
[1] Call addDownstream before removeDownstream in affirmative tests
In order to properly test removeDownstream() where the HAL might
reasonably reject downstreams not previously added we now call
addDownstream() first (for affirmative tests).
[2] Clarify when stopOffload() return values can be safely ignored.
Test: as follows
- make vts -j30 BUILD_GOOGLE_VTS=true && \
vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--primary-abi-only \
--skip-preconditions \
--module VtsHalTetherOffloadControlV1_0Target \
-l DEBUG
still doesn't pass but it's better than before :)
Bug: 65270149
Change-Id: I27a574bd2110e3a1626de343f6b57b9efb8cdf83
This reverts commit 8ac1971678.
Reason for revert: Didn't remove automotive changes from this CL.
Merged-In: I8608c8f636c35f21e4246a805a9eff6d14124e0a
Change-Id: I1c660cffc8817ad0b33da9f6eceb3d88e7c48416
