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)
Because setSignalStrengthReportingCriteria only
supports a single measurement quantity, provide
further clarification on the applicability of the
API and how it may be used in various situations.
Bug: 110121199
Test: compilation - docstring-only change
Merged-In: If4236070fbc03368e5a78b0cf502cdc4a529a6ed
Change-Id: If4236070fbc03368e5a78b0cf502cdc4a529a6ed
(cherry picked from commit 529d2fffa0)
Do not expect its affect on cardStatus if it is not successfully returned.
Check the response error before updating sim card status.
Test: sanity
Bug: 111661946
Change-Id: I48551f5469289b9fcfc47dd9fd2e455779640329
Merged-In: I48551f5469289b9fcfc47dd9fd2e455779640329
(cherry picked from commit 7e787e192cd4700d8f4e7cc5f55501bc37590245)
If the function isn't executed successfully, do not expect its effect
of cardStatus.
Bug: 111661946
Test: run vts
Change-Id: I952728311b595149b449280e73142f2f82af544d
Merged-In: I952728311b595149b449280e73142f2f82af544d
(cherry picked from commit 934243085a)
(cherry picked from commit c02dd2562f)
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
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
The radio band mode is perilous because depending
on the setting and the detected locale, other
settings may be disabled. That can leave the modem
in a soft-brick state. Thus, BandMode = 0 = AUTOMATIC
should always be supported so that the modem can
update and select a band mode of its choosing.
Bug: 28124606
Test: vts radio - getAvailableBandModes
Change-Id: I1f25d9125ef06d290e3a89b5d2162c6bfe939eba
Checked points:
- service is on
- vts can run on it
- provided a dummy implementation that a VTS test can pass it
- applied with recent update in radio 1.2 hal
- format repaired
- pass on a 1.0 VTS test, a 1.1 VTS test, and a 1.2 VTS test
Bug: 74114758
Test: run vts
Change-Id: I8a052e3cedb41db9028552ab88f1e26492718497
Radio VTS client 1.2 radio response cannot be cast from radio response
in the service. To fix it, the client radio response and indication
should extend 1.2 IRadioResponse and IRadioIndication
Bug: 77815815
Test: ran it on the default service
Change-Id: Ib014af98d52d9f208d2139f4a239e9d61ea4d569
When copying over from WcdmaSignalStrength, the
ranges and references were wrong. Sadly they
were carried over. Fixing before this gets
out of hand.
Bug: 18628145
Test: compilation - documentation-only change
Change-Id: I08a247674cf42ebeed26c721ff99a71db4152bbf
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
