Modify the document for 'hasKnownUserIntentEmergency'.
In the scenarios that the 'address' in the 'dialInfo' field has other
functions besides the emergency number function, if the
'hasKnownUserIntentEmergency' field is true, the user's intent for this
dial request is emergency call, and the modem must treat this as an
actual emergency dial; if the 'hasKnownUserIntentEmergency' field is
false, Android does not know user's intent for this call.
Test: compile
Bug: 121345950
Change-Id: I3457e7519be564ac5043e06380e9450a1b12425f
(cherry picked from commit 7208840ec0148ad5a01bdf419170282cd1b32437)
Add the NR Cell Identity field to the NrCellIdentity
struct.
Bug: 124126359
Test: compilation on goog/master; VTS currently infeasible
pending other changes.
Change-Id: Ie7082a7dc1737cb613ab178e86016fa0d09c24d3
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
New tests would be added in cpp files under functional folder. Add a new
folder since it doesn't exist for 1.4 yet.
Test: Compilation
Change-Id: Ieac30bbbc865b76a08d4bdd655f0d489bb7f77bd
Bug: 73784494
The new parameter is to indicate if the request is initiated
by the user through an emergency dialer or shortcut, meaning
that the request is explicitly an emergency dial request.
This is to indicate to the modem that no disambiguation (regarding
whether this is really an emergency request) should
be done for this request.
Test: builds fine
Bug: 123101600
Merged-in: Ic830762d8a8319f494f22d875ca6adad91ffce3b
Change-Id: Ic830762d8a8319f494f22d875ca6adad91ffce3b
(cherry picked from commit 143d32860f)
If 'isTesting' is true, this request is for testing purpose,
and must not be sent to a real emergency service; otherwise it's
a real emergency call request.
Bug: 122840137
Test: Treehugger (VTS later)
Merged-in: I9607967b2a362f72e9d2bcda4ef25afaf0cc7f1d
Change-Id: I9607967b2a362f72e9d2bcda4ef25afaf0cc7f1d
(cherry picked from commit 527d650656)
The new parameter is to indicate if the request is initiated
by the user through an emergency dialer or shortcut, meaning
that the request is explicitly an emergency dial request.
This is to indicate to the modem that no disambiguation (regarding
whether this is really an emergency request) should
be done for this request.
Test: builds fine
Bug: 123101600
Change-Id: Ic830762d8a8319f494f22d875ca6adad91ffce3b
Clean up some unneeded/confusing error codes in the 1.4 Radio HAL.
Quoting description from aosp/616923:
-Remove SYSTEM_ERROR. This is an ultra-generic error
that also provides no meaningful distinction from
INTERNAL_ERROR but is even less specified in scope.
-Remove NO_MEMORY. This is very implementation
specific, and should be essentially impossible to
hit in the generic sense. Today we don't have a
generic EBUSY error code, which this would map to.
Since it should be essentially impossible to hit,
the preference is to assert that it shouldn't be.
If an implementation really has memory pressure
then it can return INTERNAL_ERROR, of which this
is a class. INTERNAL_ERROR will be treated as a
temporary failure anyway, making NO_MEMORY a
distinction without a difference.
-Remove CANCELLED. We have no way to cancel an API
call. If a persistent/ongoing request is cancelled
by the caller using a separate API request, then
that's a success case rather than an error case.
Bug: 73174777
Change-Id: I5bf268f86ed52e7294f7127f24beba04c9159fea
Test: Compilation
Many of error causes reason are using very esoteric
abbreviations and acronyms. Refine description for making more
clear to the developer.
Bug: 113505704
Test: Build pass and data call can setup normally.
Change-Id: Ifb9c256eef8354add46c76c322cd6a3bd126bd44
Add support for dual SIM to carrier restrictions.
Add support to exclude specific carriers in the list of carrier
restrictions.
Bug: 120313541
Test: Created test application to verify correct functionality.
Change-Id: Ib05267fda5f2fd0b8821a5812fcf47d460e60a2b
Merged-In: Ib05267fda5f2fd0b8821a5812fcf47d460e60a2b
setModemsConfig and getModemsConfig APIs will allow the framework
to set the number of live modems to switch to single/multi sim state
Bug: 122073700
Test: vts
Change-Id: Ib200ffa5f2aebe21caf2b761407c79828730e6f1
Merged-In: Ib200ffa5f2aebe21caf2b761407c79828730e6f1
setModemsConfig and getModemsConfig APIs will allow the framework
to set the number of live modems to switch to single/multi sim state
Bug: 122073700
Test: vts
Change-Id: Ib200ffa5f2aebe21caf2b761407c79828730e6f1
Some countries or carriers require some emergency numbers that must
be handled with normal call routing or emergency routing.
In multi-sim senario, this radio request will be sent through the IRadio
service that serves the subscription the emergency number belongs to,
no matter of the PUK/PIN state of the subscription and the service state.
Test: Treehugger
Bug: 112657134
Change-Id: Iaa9768226dc2d7d2d66a9678823ba7d0047a1988
Merged-In: Iaa9768226dc2d7d2d66a9678823ba7d0047a1988
(cherry picked from commit dd49ad675e)
If 'isTesting' is true, this request is for testing purpose,
and must not be sent to a real emergency service; otherwise it's
a real emergency call request.
Bug: 122840137
Test: Treehugger (VTS later)
Change-Id: I9607967b2a362f72e9d2bcda4ef25afaf0cc7f1d
Add support for dual SIM to carrier restrictions.
Add support to exclude specific carriers in the list of carrier
restrictions.
Bug: 120313541
Test: Created test application to verify correct functionality.
Change-Id: Ib05267fda5f2fd0b8821a5812fcf47d460e60a2b
Some countries or carriers require some emergency numbers that must
be handled with normal call routing or emergency routing.
In multi-sim senario, this radio request will be sent through the IRadio
service that serves the subscription the emergency number belongs to,
no matter of the PUK/PIN state of the subscription and the service state.
Test: Treehugger
Bug: 112657134
Change-Id: Iaa9768226dc2d7d2d66a9678823ba7d0047a1988
Currently, most of the fail causes for data connectivity are
exposed as ERROR_UNSPECIFIED. To know the precise fail
cause not just common exception, add more cause definitions
let exact fail reason can pass up to the apps from modem.
Bug: 113505704
Test: Build pass and data call can setup normally.
Change-Id: I1c8b910c272a027c811434d6d034b60ebfd64afa
To better test CBRS, we want IRadio 1.1 to be Android P plus CBRS
HAL interfaces, while 1.2 will be 1.1 plus all other Android Q
interfaces. So we are creating V1_2 folder and moving everything
currently defined in android.hardware.radio.config.V1_1 there.
Bug: 117805040
Test: build and telephony unittest
Change-Id: Ia221258b62351d1190e78fa0e5faafc36163f4a9
Merged-In: Ia221258b62351d1190e78fa0e5faafc36163f4a9
To better test CBRS, we want IRadio 1.3 to be Android P plus CBRS
HAL interfaces, while 1.4 will be 1.3 plus all other Android Q
interfaces. So we are creating V1_4 folder and moving everything
currently defined in android.hardware.radio.V1_3 there.
Part 2: re-create 1.3 folder.
Bug: 117805040
Test: build and telephony unittest
Change-Id: If177cd24d8275e22c18d9b5b907cd65ac13a4461
Merged-In: If177cd24d8275e22c18d9b5b907cd65ac13a4461
To better test CBRS, we want IRadio 1.3 to be Android P plus CBRS
HAL interfaces, while 1.4 will be 1.3 plus all other Android Q
interfaces. So we are creating V1_4 folder and moving everything
currently defined in android.hardware.radio.V1_3 there.
Part 2: move 1.3 to 1.4.
Bug: 117805040
Test: build and telephony unittest
Change-Id: I9fc36f1af0e7cc4d2a5878531aae5746823e1bb4
Merged-In: I9fc36f1af0e7cc4d2a5878531aae5746823e1bb4
To better test CBRS, we want IRadio 1.1 to be Android P plus CBRS
HAL interfaces, while 1.2 will be 1.1 plus all other Android Q
interfaces. So we are creating V1_2 folder and moving everything
currently defined in android.hardware.radio.config.V1_1 there.
Bug: 117805040
Test: build and telephony unittest
Change-Id: Ia221258b62351d1190e78fa0e5faafc36163f4a9
To better test CBRS, we want IRadio 1.3 to be Android P plus CBRS
HAL interfaces, while 1.4 will be 1.3 plus all other Android Q
interfaces. So we are creating V1_4 folder and moving everything
currently defined in android.hardware.radio.V1_3 there.
Part 2: re-create 1.3 folder.
Bug: 117805040
Test: build and telephony unittest
Change-Id: If177cd24d8275e22c18d9b5b907cd65ac13a4461
To better test CBRS, we want IRadio 1.3 to be Android P plus CBRS
HAL interfaces, while 1.4 will be 1.3 plus all other Android Q
interfaces. So we are creating V1_4 folder and moving everything
currently defined in android.hardware.radio.V1_3 there.
Part 2: move 1.3 to 1.4.
Bug: 117805040
Test: build and telephony unittest
Change-Id: I9fc36f1af0e7cc4d2a5878531aae5746823e1bb4
These two fields are still needed for some carriers. Should
not be removed in 1.3. Reverted back to what we have in 1.0.
Test: Telephony sanity tests
Bug: 73659459
Change-Id: I33e7b9b0cb26b56fc3c0e011557657136cb38a6c
1. Deprecated the fields 'mvnoType', 'mvnoMatchData', 'maxConnsTime',
and 'maxConns'.
2. Added a new flag 'preferred' indicating if this data profile
is preferred for default data connection setup.
3. Move modemCognative flag from setupDataCall and setInitialAttachApn
into the struct DataProfileInfo and rename it to 'persistent'.
4. Removed isRoaming flag in setupDataCall, setInitialAttachApn, and
setDataProfile.
Test: Telephony sanity tests
Bug: 73659459
Change-Id: Ia28715e85755b47a1ee870b5c90e5505a7fd8c4a
- Add Emergency Number source for Emergency number, which is critical for
management and display priority.
- Remove solicited request for getting emergency number list.
- Rephrasing the documentations.
Test: Treehugger (will add VTS later)
Bug: 112657134
Change-Id: Idbfebf8d246de06fd91e8de89088f5cc2c70227b
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)
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
Merged-In: I456847815057d76561bfb3e840016619ac753476
Change-Id: I456847815057d76561bfb3e840016619ac753476
(cherry picked from commit 12f7d6127b)
We are trying to tighten the APIs. However for this case since the
documentation was not updated, we are allowing NOT_SUPPORTED for
now and will be cleaned up in a later release.
Test: run vts -m VtsHalRadioV1_2Target
Bug: 110118713
Merged-In: Id9dd3d7bac99bed36ceb9c906189f1fea78d5a2c
Change-Id: Id9dd3d7bac99bed36ceb9c906189f1fea78d5a2c
(cherry picked from commit a7587b5a7f)
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)
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
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 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)
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)
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)
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)
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
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)
"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
Added RadioError::NONE as a possible return value for data call
setup API. The data call could be setup for emergency purposes
when no SIM inserted.
Test: VTS
Bug: 109767888
Merged-In: I4469c371f999b99d35f4078df000f05ee1f3c84d
Change-Id: I4469c371f999b99d35f4078df000f05ee1f3c84d
(cherry picked from commit 431eb118f8)
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
Change-Id: If4236070fbc03368e5a78b0cf502cdc4a529a6ed
We are trying to tighten the APIs. However for this case since the
documentation was not updated, we are allowing NOT_SUPPORTED for
now and will be cleaned up in a later release.
Test: run vts -m VtsHalRadioV1_2Target
Bug: 110118713
Change-Id: Id9dd3d7bac99bed36ceb9c906189f1fea78d5a2c
(cherry picked from commit a7587b5a7f)
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
Doc comments look like "/** ... */" and they
can only be in certain places.
Bug: 79865343
Test: m
Change-Id: Ic15c08ff7dc6e4f9827c1dbe7f7236c11a572ec1
Merged-In: Ic15c08ff7dc6e4f9827c1dbe7f7236c11a572ec1
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
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
Merged-In: I8a052e3cedb41db9028552ab88f1e26492718497
(cherry picked from commit 0de4d31569)
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
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
Merged-In: Ib014af98d52d9f208d2139f4a239e9d61ea4d569
(cherry picked from commit 79bafb943b)
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
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
Merged-In: I1f25d9125ef06d290e3a89b5d2162c6bfe939eba
Change-Id: I1f25d9125ef06d290e3a89b5d2162c6bfe939eba
(cherry picked from commit c9e391801ba5ccd24b41481b26c2861b71ef03d0)
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
