These tests assumed that they were rooted before running, and due to
a combination of b/152655658 and b/154638140, these appeared to work
when a device already happened to be rooted and the test failures showed
up as problems with the test rather than as problems with the target
preparer.
This is the same workaround being used elsewhere.
Fixes: 154445273 # specifically about VtsHalSapV1_0TargetTest
Test: atest VtsHalSapV1_0TargetTest # passes 100%
The following tests, I confirm MultiSimTargetPreparer works, although my
test device has no SIM so I cannot get fully useful results.
Test: atest VtsHalRadioV1_0TargetTest # slot2 cases can now pass
Test: atest VtsHalRadioV1_1TargetTest # slot2 cases can now pass
Test: atest VtsHalRadioV1_2TargetTest # slot2 cases can now pass
Test: atest VtsHalRadioV1_3TargetTest # fully passes
Test: atest VtsHalRadioV1_4TargetTest # fully passes
Change-Id: Id62cb2e1b7a95552b560ab1d4ff2f63c0a7569a3
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
Add the initialization of the incrementalResultsPeriodicity and
maxSearchTime in the networkScan request.
The incrementalResultsPeriodicity and maxSearchTime are not
initialized in the networkScan request. So the default value is 0.
But the incrementalResultsPeriodicity and maxSearchTime
are required not to be 0 in subsequent tests.
CL ported from pag/1433565
Bug:140451434
Test: make vts && vts-tradefed run commandAndExit vts -m \
VtsHalRadioV1_2Target -t RadioHidlTest_v1_2#startNetworkScan
Change-Id: I1b4e512a37d3d85ebc905a64987a40af801bce53
(cherry picked from commit f7894eb4d8c395add7c70a20520336057ae2656f)
Update the documentation of NetworkScanRequest to clarify
that the interval between scans is from the completion of
one scan to the start of another. This is the only possible
definition that doesn't possibly result in back-to-back
scans which never complete.
In the initial design of this API, the stated use case was
for scans where "interval" >> "scan duration". For that
use case, this clarification doesn't make a meaningful
difference; however, for the use case of long-duration
scans, the distinction prevents the issue stated above.
Bug: 139935383
Test: compilation (docstring-only change)
Change-Id: Ib8393110bfd3ea883045648ee7dac9c6e6a32d44
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I075670b64eebbbbd6a6ae0e84ad51bf1c6f5ba36
Providing non-dds exemption for HAL 1.2 network scan due to some devices
only perform network scan on preferred data sim. Since logical modem
id(0/1) and physical sim slot id(0/1) are intuitively aligned. Set
first sim as dds sim, and skip the network scan on the second one
(non-dds).
Test: Vts
Bug: 135243177
Change-Id: I58b89473714dc6d3ce6567ba1809baad6cd6d799
(cherry picked from commit fc85e8fa50)
Providing non-dds exemption for HAL 1.2 network scan due to some devices
only perform network scan on preferred data sim. Since logical modem
id(0/1) and physical sim slot id(0/1) are intuitively aligned. Set
first sim as dds sim, and skip the network scan on the second one
(non-dds).
Test: Vts
Bug: 135243177
Change-Id: I58b89473714dc6d3ce6567ba1809baad6cd6d799
Change stopNetworkScan from 1_1 to 1_2 when testing VtsHalRadioV1_2Target.
Symptom:
When vts process slot2 "startnetworkscan", it will call "stopnetworkscan()" when startnetworkscan
success. But from current design it will set stopnetworkscan to slot1(wrong slot, expect is slot2)
as bwlow log.
CTS fail log:
hardware/interfaces/radio/1.2/vts/functional/radio_hidl_hal_test.cpp:111
//Device request NwScan on 2nd Sim
06-28 11:30:22.770 radio 873 1213 F RILQ : RIL[1][Log.cpp: 48] [DispatcherModul(873,1213)]
d: [DispatcherModule]: Handling msg = RIL_REQUEST_START_NETWORK_SCAN
//But Device want to abort on Primary Sim
06-28 11:30:22.776 radio 923 1205 F RILQ : RIL[0][Log.cpp: 48] [DispatcherModul(923,1205)]
d: [NasModule]: Handling msg = RIL_REQUEST_STOP_NETWORK_SCAN[Context: IRadio(1681692777)]
Bug: 135982495
Test: Build pass. Local test VTS pass.
Change-Id: Ic53c24ab2a670e806b4ac7f192e6eb81252ade84
(cherry picked from commit 5cef297cb2)
Change stopNetworkScan from 1_1 to 1_2 when testing VtsHalRadioV1_2Target.
Symptom:
When vts process slot2 "startnetworkscan", it will call "stopnetworkscan()" when startnetworkscan
success. But from current design it will set stopnetworkscan to slot1(wrong slot, expect is slot2)
as bwlow log.
CTS fail log:
hardware/interfaces/radio/1.2/vts/functional/radio_hidl_hal_test.cpp:111
//Device request NwScan on 2nd Sim
06-28 11:30:22.770 radio 873 1213 F RILQ : RIL[1][Log.cpp: 48] [DispatcherModul(873,1213)]
d: [DispatcherModule]: Handling msg = RIL_REQUEST_START_NETWORK_SCAN
//But Device want to abort on Primary Sim
06-28 11:30:22.776 radio 923 1205 F RILQ : RIL[0][Log.cpp: 48] [DispatcherModul(923,1205)]
d: [NasModule]: Handling msg = RIL_REQUEST_STOP_NETWORK_SCAN[Context: IRadio(1681692777)]
Bug: 135982495
Test: Build pass. Local test VTS pass.
Change-Id: Ic53c24ab2a670e806b4ac7f192e6eb81252ade84
For some vendors do not supports independent radios, if
there is one manual search ongoing, another manual search
on other SIM is not supported. So sending stop network scan
request once trigger network scan completed to exclude this
modem limitation.
Bug: 135005200
Test: atest RadioHidlTest_v1_2#startNetworkScan
Change-Id: Iacfd59ac2ad4d44e763ee03697c1f8f57162ce38
Currently tests that check for incremental scan interval
range-checking have incremental scans disabled.
This CL turns on incremental scans for tests where the
invalid interval range checks are being validated.
Bug: 112486807
Test: atest RadioHidlTest_v1_2#startNetworkScan_InvalidPeriodicity1;
atest RadioHidlTest_v1_2#startNetworkScan_InvalidPeriodicity2;
Merged-In: I94874f538d2df70a72913b489d9298f8d1cf9b56
Change-Id: I94874f538d2df70a72913b489d9298f8d1cf9b56
(cherry picked from commit f56b9a41dd)
When incremental results are disabled for network scans,
update the API documentation to allow implementations to
ignore range checking for the incremental scan interval.
Bug: 112486807
Test: compilation - docstring-only change
Merged-In: I901335550b4b8c2cf75f91b39fd031f03ffae982
Change-Id: I901335550b4b8c2cf75f91b39fd031f03ffae982
(cherry picked from commit 944efca78d)
Currently tests that check for incremental scan interval
range-checking have incremental scans disabled.
This CL turns on incremental scans for tests where the
invalid interval range checks are being validated.
Bug: 112486807
Test: atest RadioHidlTest_v1_2#startNetworkScan_InvalidPeriodicity1;
atest RadioHidlTest_v1_2#startNetworkScan_InvalidPeriodicity2;
Change-Id: I94874f538d2df70a72913b489d9298f8d1cf9b56
When incremental results are disabled for network scans,
update the API documentation to allow implementations to
ignore range checking for the incremental scan interval.
Bug: 112486807
Test: compilation - docstring-only change
Change-Id: I901335550b4b8c2cf75f91b39fd031f03ffae982
Change the network scan tests to use the P900 and 850
GSM bands, which are commonly (nearly universally) supported
bands.
Bug: 132076611
Test: atest RadioHidlTest_v1_2
Merged-In: Ia682f022d35c481876c49c9c8802d7c39722be0e
Change-Id: Ia682f022d35c481876c49c9c8802d7c39722be0e
(cherry picked from commit 2ea2a64bc7)
Change the network scan tests to use the P900 and 850
GSM bands, which are commonly (nearly universally) supported
bands.
Bug: 132076611
Test: atest RadioHidlTest_v1_2
Change-Id: Ia682f022d35c481876c49c9c8802d7c39722be0e
Change the network scan tests to use the P900 and 850
GSM bands, which are commonly (nearly universally) supported
bands.
Bug: 132076611
Test: atest RadioHidlTest_v1_2
Change-Id: Icb4dc47360a5753b9697f74aec19045155ee27fc
hidl-generated makefiles are now generated such that bpfmt(file) == file.
Bug: 67417008
Test: enable bpfmt hook
Change-Id: I1f69d292bc23a7cc293a66110cb02d597e1019ad
When fields are inapplicable, they should not
be set to a clearly out-of-range value to signal
to the framework that those fields are not used.
In some cases, there is an in-range invalid value
that has been defined by the standards. The docs
are inconsistent in calling out INT_MAX as the
value to be used when something is inapplicable
vs the case when a measurement is simply not
reported. In all cases, INT_MAX can be used to
denote an invalid value, and in cases where the
field/structure is inapplicable, it is the correct
value. This CL updates all the docstrings for
SignalStrength-related fields to clarify that
INT_MAX is the correct "invalid" value for cases
when fields are inapplicable.
Bug: 123088652
Test: compilation (docstring-only change); CTS
naturally enforces this change on devices with
newer HALs; backwards compatibility is preserved
for existing HAL versions.
Change-Id: I5cfa917f504d15691ab3f2c298189bdd47794a42
The type of mcc and mnc is String instead of Int now. They should be an
empty string if unknown. Also added a test case for their values.
Bug: 111703979
Test: Vts
Change-Id: Ie0426453dc426ccc6cf203b315806e78511ce14d
startNetworkScan:
Some vendor may not support the required manual GSM search
functionality.
startNetworkScan_GoodRequest1 and startNetworkScan_GoodRequest2:
Some vendor may not support max search time of 360s.
Test: sanity
Bug: 109765420
Change-Id: I456847815057d76561bfb3e840016619ac753476
Merged-In: I456847815057d76561bfb3e840016619ac753476
(cherry picked from commit 12f7d6127b)
Since the EMERGENCY-type APN is a must set in the radio
setupDataCall request for modem to perform Emergency call,
and the given VTS test case does not set that emergency bit,
I think modem should treat the request as a normal call
request, and should not return "NONE" for no-sim.
This reverts commit 431eb118f8.
Reason for revert: after further discussion, NONE
is not acceptable given the test case.
Bug: 109767888
Change-Id: I3d1cc96120d53a9be0ae5059c26b091bf82dc352
Merged-In: I3d1cc96120d53a9be0ae5059c26b091bf82dc352
(cherry picked from commit 17fec3625d)
