Note that this just increases the gtest time to match our
highest wait times. Each test still has wait times fitted for the
expected length of that test.
Bug: 159289514
Test: atest VtsHalRadioV1_0TargetTest
Change-Id: I0825305258bae20ea6e13e9b9a65ce30b7153611
The test doesn't need framework. It seems that the test can be flaky
when framework was stop/started earlier.
Bug: 154445273
Test: atest -a VtsHalBluetoothV1_0TargetTest \
VtsHalSapV1_0TargetTest \
VtsHalAudioV4_0TargetTest
Change-Id: I60f62923cfb826c5e33e9885ea08efdbe4c8f57e
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
- IRadio.nvResetConfig:
IRadio.nvResetConfig with ResetNvType ERASE cause radio restart.
The subsuquent test cases fail with RADIO_NOT_AVAILABLE.
Fix to use ResetNvType FACTORY_RESET which does not restart the radio.
Test: run vts -m VtsHalRadioV1_0Target
Bug: 147831226
Change-Id: I45e5cbcf9144c3ace987ac8e047e40fbee403734
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
If function is not supported or executed successfully, do not
expect its effect on cardStatus.
Bug: 112008372
Test: run vts
Change-Id: I4532a39af2cfcf0e44eafe29c3c7f6779ae101f5
Merged-In: I4532a39af2cfcf0e44eafe29c3c7f6779ae101f5
(cherry picked from commit 44b129f728)
This is to match it with other 1.0 tests where general errors are
allowed. For newer tests we have decided to not allow these errors,
but a failure for this old test is reported when run with SIM
present.
Test: run vts -m VtsHalRadioV1_0Target
Bug: 109889468
Change-Id: If36083b7832706a50805932e8ba08e4eb397f3fe
Merged-In: If36083b7832706a50805932e8ba08e4eb397f3fe
(cherry picked from commit 817848e59e)
Add SIM_PUK2 for supplyIccPin2ForApp and changeIccPin2ForApp if sim
card is in the puk2 state.
Bug: 111211929
Test: sanity
Change-Id: I80d924cc4a61565887cbd2a65ee5927a42ad656e
Merged-In: I80d924cc4a61565887cbd2a65ee5927a42ad656e
(cherry picked from commit 4ed0a216ad)
PUK1 and PUK2 can get permanent blocked when it inputs wrong
passwords more than 10 times.
Bug: 111211929
Test: sanity
Change-Id: I736873b1b181b88f279df7dc1c09e18e0fc76af3
Merged-In: I736873b1b181b88f279df7dc1c09e18e0fc76af3
(cherry picked from commit cb9e9d10462cc82ee6e7074f8d4c831b6348b3ea)
If function is not supported or executed successfully, do not
expect its effect on cardStatus.
Bug: 112008372
Test: run vts
Change-Id: I4532a39af2cfcf0e44eafe29c3c7f6779ae101f5
Merged-In: I4532a39af2cfcf0e44eafe29c3c7f6779ae101f5
(cherry picked from commit 44b129f728)
Add SIM_PUK2 for supplyIccPin2ForApp and changeIccPin2ForApp if sim
card is in the puk2 state.
Bug: 111211929
Test: sanity
Change-Id: I80d924cc4a61565887cbd2a65ee5927a42ad656e
Merged-In: I80d924cc4a61565887cbd2a65ee5927a42ad656e
(cherry picked from commit 4ed0a216ad)
PUK1 and PUK2 can get permanent blocked when it inputs wrong
passwords more than 10 times.
Bug: 111211929
Test: sanity
Change-Id: I736873b1b181b88f279df7dc1c09e18e0fc76af3
Test: I solemnly swear I tested this conflict resolution.
Bug: 72075328
Change-Id: I5d7c124bc3905f899e63f080ac94def4e06fe9c2
Merged-In: I8c993cd2fa95c961dc7f976b5bd85a2826b42889
"Allow startLceService to succeed even in the
SIM_ABSENT case. The original RIL documentation
states that SUCCESS is valid for all LCE
operations, and there is no logical reason why
one of these operations must fail in a no-SIM
case (though a vendor may choose not to support
that configuration). Thus, a call to
startLceService should permit NONE when requested
in the no-SIM case for 1.0 VTS.
In addition, a successful call to startLceService
should also permit a successful call to
pullLceData, so also allow RadioError::NONE for
the pull operation. Ideally the tests would only
allow NONE for pull if startLceService also
returns NONE, but that's out of scope for now."
Bug: 110181475
Bug: 72075328
Test: confirmed in the discussion; compilation
This is to match it with other 1.0 tests where general errors are
allowed. For newer tests we have decided to not allow these errors,
but a failure for this old test is reported when run with SIM
present.
Test: run vts -m VtsHalRadioV1_0Target
Bug: 109889468
Change-Id: If36083b7832706a50805932e8ba08e4eb397f3fe
Fix and enhance sim-present tests,
Save VTS running time,
Fix serial number inconsistancy issue
Fix and enhance sim-present tests:
In 1.0:
- setupDataCall timeout, need more waiting time
- requestIccSimAuthentication returns REQUEST_NOT_SUPPORTED,
need to check it
- sendSms timeout, would need more waiting time
- sendSMSExpectMore timeout, would need more waiting time
- getAllowedCarriers, getting CardState::RESTRICTED, the previous test
of setAllowedCarriers is doing resetting back to no carrier restriction,
but that needs some time to populate.
In 1.1:
- setSimCardPower_1_1 set sim card power down that makes other tests
fail, reset it back with sim card power on.
Save VTS running time,
- Use waiting loop and prevent unnecessary waiting to save the whole
running time.
Fix serial number inconsistancy issue
- During the enforcement running, it is liked the serial number is
not consistent. And it happens in b/78249227. Suspect that when sim
card is inserted, during the testing running time, the radio may
request some response that is not triggered from the test, but the
test may receive it and think it is what is triggered by the test. The
fix is to check serial number before notifying of unlock the test
lock.
Bug: 76125134
Bug: 78248071
Bug: 78139665
Bug: 78249227
Test: run vts -m VtsHalRadioV1_0Target; run vts -m VtsHalRadioV1_1Target
Change-Id: I08fe9d7ac16283c7ce1a5aeb6b3b372786a8d5c3
Merged-In: I08fe9d7ac16283c7ce1a5aeb6b3b372786a8d5c3
(cherry picked from commit 788eb80830)
Fix and enhance sim-present tests,
Save VTS running time,
Fix serial number inconsistancy issue
Fix and enhance sim-present tests:
In 1.0:
- setupDataCall timeout, need more waiting time
- requestIccSimAuthentication returns REQUEST_NOT_SUPPORTED,
need to check it
- sendSms timeout, would need more waiting time
- sendSMSExpectMore timeout, would need more waiting time
- getAllowedCarriers, getting CardState::RESTRICTED, the previous test
of setAllowedCarriers is doing resetting back to no carrier restriction,
but that needs some time to populate.
In 1.1:
- setSimCardPower_1_1 set sim card power down that makes other tests
fail, reset it back with sim card power on.
Save VTS running time,
- Use waiting loop and prevent unnecessary waiting to save the whole
running time.
Fix serial number inconsistancy issue
- During the enforcement running, it is liked the serial number is
not consistent. And it happens in b/78249227. Suspect that when sim
card is inserted, during the testing running time, the radio may
request some response that is not triggered from the test, but the
test may receive it and think it is what is triggered by the test. The
fix is to check serial number before notifying of unlock the test
lock.
Bug: 76125134
Bug: 78248071
Bug: 78139665
Bug: 78249227
Test: run vts -m VtsHalRadioV1_0Target; run vts -m VtsHalRadioV1_1Target
Change-Id: I08fe9d7ac16283c7ce1a5aeb6b3b372786a8d5c3
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 test cases are not changed.
Change-Id: Iaef7e8eefa8fcfde0ff8030cba1f9753a28eac61
Merged-In: Iaae71e0abacd28275d86a19264813ff209ddb79c
As per the spec, the range should be 0-31, 99, and the section
should be 8.5.
Test: builds - No change to behavior
Bug: 71329173
Change-Id: Ib1ea54b19a7bcb33a0235b3ddb3fa09c4872890f
The LTE TA Doc string has been fixed to reflect
the actual reported value of the field. The spec
reference was previously incorrect, which would
have indicated a range of 0-63 as the incremental
timing advance; however the field actually reports
the absolute timing advance, which has a much
larger range of 0-1282. In addition, this CL
updates the comment to remove a link to a defunct
website and explicitly states the range extracted
from the updated spec reference. This does not
impact the current behavior of the API as the the
previously incorrect docstring was nonsensical.
Bug: 66751464
Test: compilation (doc only change)
Change-Id: I2fc90c08ed6dd14548b10c638bf805b37d5c34e8
Since the purpose of most of the test cases in current VTS is to check
if proper errors are returned and there is no crash seen in vendor code,
updating setRadioPower test case to turn on the radio instead of
turning off. We want to avoid test cases which turn off
radio or leads to modem shut down as those test cases affect other tests.
Test: VTS
Change-Id: I4fb9f18884f7ef21162015a0032c4431444f7025
Merged-In: I4fb9f18884f7ef21162015a0032c4431444f7025
Bug: 65230472
(cherry picked from commit 9a721b8087)
(cherry picked from commit 536818d17a)
Remove same unit test case with arguments "","0" for:
- sendEnvelope
- sendTerminalResponseToSim
- sendEnvelopeWithStatus
Test: verified by vendor, treehuger
Bug: 62926561
Change-Id: I5f535bdfc5821275a7ea2571d411374e0d7a8822
Merged-In: I5f535bdfc5821275a7ea2571d411374e0d7a8822
(cherry picked from commit 67901bf2ce)
