Add indication APIs to expose Quality Of Service (QOS) information
from LTE and NR default as well as dedicated bearers. The QOS is
added to the existing SetupDataCallResult structure so that the
baseband can notify whenever there is a change in QoS on a PDN.
The baseband vendor shall notify the {@link Qos} of the default
bearer at the time of setup data call success. The dedicated bearer
QOS shall be notified whenever network establishes or modfies a
dedicated bearer using dataCallListChanged() API. When network tears
down the dedicated bearer, vendor shall update the same with a empty
{@link QosSession} for the particular data call.
Bug: 158315614
Test: make, VTS
Change-Id: I58cd3fd2cf354de8916aeed1292cd7071e79e184
HIDL libs are not necessarily part of VNDK now. Because some are
used by VNDK libs, they are still VNDK. But rest are now just
vendor-available.
.hidl_for_test files are also removed because they are used to exclude
test-purpose hidl libs from VNDK libs.
Instead, .hidl_for_system_ext files are added to tests/lazy to
distinguish them from others which are installed /system.
Bug: 143933769
Test: update-makefiles.sh && m com.android.vndk.current
Merged-In: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
Change-Id: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
(cherry picked from commit b0907a6bb8)
HIDL libs are not necessarily part of VNDK now. Because some are
used by VNDK libs, they are still VNDK. But rest are now just
vendor-available.
.hidl_for_test files are also removed because they are used to exclude
test-purpose hidl libs from VNDK libs.
Instead, .hidl_for_system_ext files are added to tests/lazy to
distinguish them from others which are installed /system.
Bug: 143933769
Test: update-makefiles.sh && m com.android.vndk.current
Merged-In: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
Change-Id: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
(cherry picked from commit b0907a6bb8)
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
Merged-In: I0825305258bae20ea6e13e9b9a65ce30b7153611
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
Allow devices launching with IRadio 1.5 this year to
not support BarringInfo.
Bug: 159582898
Test: atest VtsHalRadioV1_5TargetTest -- -t getBarringInfo
Change-Id: I05b749fa3cfb3648148fd2666d7eb6f43f3c45d2
Sendcdmasexpectmoreresponse to the request sendcdmasexpectmore
did not accept the return parameter responseinfo, which caused
the VTS system to wait for a response until it exceeded 60 seconds,
and the VTS determined No test results.
so we can add parameters to receive the parameters of
sendcdmasexpectmoreresponse,and then make subsequent judgment.
Bug: 158542706
Test: run vts -m VtsHalRadioV1_5TargetTest
Change-Id: I1d6214f58850d707520b80634cb93d0e0cc712bb
Merged-In: I1d6214f58850d707520b80634cb93d0e0cc712bb
VtsHalRadioV1_5TargetTest.PerInstance/RadioHidlTest_v1_5#
sendCdmaSmsExpectMore/0_slot1
Sendcdmasexpectmoreresponse to the request sendcdmasexpectmore
did not accept the return parameter responseinfo, which caused
the VTS system to wait for a response until it exceeded 60 seconds,
and the VTS determined No test results.
so we can add parameters to receive the parameters of
sendcdmasexpectmoreresponse,and then make subsequent judgment.
Bug: 158542706
Test: run vts -m VtsHalRadioV1_5TargetTest
Change-Id: I1d6214f58850d707520b80634cb93d0e0cc712bb
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
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
Due to modem issue, enableModem only works in dual-SIM mode.
And we only use that in dual-SIM mode. So skipping testing in
in single SIM mode.
Bug: 152557383
Test: vts
Change-Id: I41f200317eaf9be0613f92e5bff9a3ee8a98ef15
Merged-In: I41f200317eaf9be0613f92e5bff9a3ee8a98ef15
Due to modem issue, enableModem only works in dual-SIM mode.
And we only use that in dual-SIM mode. So skipping testing in
in single SIM mode.
Bug: 152557383
Test: vts
Change-Id: I41f200317eaf9be0613f92e5bff9a3ee8a98ef15
