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
