This is done implicitly today via a baseline map in
build/soong/apex/apex.go. Make this explicit in Android.bp
Bug: 281077552
Test: m nothing
Change-Id: I71d9a6ce9707557f8e7652adc7afa3292ef9188d
cp: aosp/1428863 to master branch
This used to be present on the old host side VTS tests, port the feature to
target side since host side VTS tests are deprecated.
Also,
i) Added a separate test: VtsHalWifiV1_4TargetTest to test the wifi
chip methods. Putting them in VtsHalWifiApV1_4TargetTest will prevent
these from running on devices without AP feature.
ii) Ensured all the non-NAN, non-RTT tests disable framework for
testing. NAN/RTT tests uses framework to check if the corresponding
package manager feature exists.
Bug: 166529516
Test: atest \
VtsHalWifiApV1_0TargetTest \
VtsHalWifiApV1_4TargetTest \
VtsHalWifiV1_0TargetTest \
VtsHalWifiV1_4TargetTest
Change-Id: I05aab6992277601633a0f926a8262c4c27402e93
Done for the following tests:
VtsHalWifiApV1_0TargetTest
VtsHalWifiApV1_4TargetTest
VtsHalWifiApV1_5TargetTest
VtsHalWifiNanV1_0TargetTest
VtsHalWifiNanV1_2TargetTest
VtsHalWifiV1_0TargetTest
VtsHalWifiV1_1TargetTest
VtsHalWifiV1_2TargetTest
VtsHalWifiV1_3TargetTest
VtsHalWifiV1_4TargetTest
VtsHalWifiV1_5TargetTest
VtsHalWifiOffloadV1_0TargetTest
Each VTS module is required to have an OWNERS file. The ownership is based on
go/vts-owners. For more information about ownership policy, please visit
go/xts-owners-policy.
Test: Tree Hugger
Bug: 143903671
Change-Id: I4acdb9a3f7a81f078e4c60d7892a72a16f7ae9d2
Add a new chip capability WIGIG, for chips that
can operate on the 60GHz band. This capability is
mapped to the vendor HAL feature WIFI_FEATURE_INFRA_60G.
Bug: 147522435
Test: atest VtsHalWifiV1_0TargetTest VtsHalWifiNanV1_0TargetTest VtsHalWifiApV1_0TargetTest \
VtsHalWifiV1_1TargetTest \
VtsHalWifiV1_2TargetTest VtsHalWifiNanV1_2TargetTest \
VtsHalWifiV1_3TargetTest \
VtsHalWifiApV1_4TargetTest VtsHalWifiNanV1_4TargetTest VtsHalWifiRttV1_4TargetTest
Change-Id: I37b1121c62acadb621dca5e38671c78817f592e1
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
Change-Id: Ia81312dda340b6b5cbdd7a3c21e1d323bda39a4a
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
In current code base, The SetUp() method in wifi VTS tests does not
reset Wifi state. Hence the first Wifi test runs with unspecified state.
Following test cases are not impacted due to that TearDown() takes care
of resetting the Wifi state.
This commit adds the stopWifi() method to the SetUp() so all test cases
start from the same Wifi state.
Bug: 145312303
Test: Run all wifi VTS tests
Test: atest <VTS test module name>
Change-Id: I63d7c0d27f4ceb713dda3804786a199dc2274be5
Attempts to fix a VTS test failure reported by OEM's on devices
supporting concurrent AP iface.
Bug: 143096362
Test: make vts && vts-tradefed run commandAndExit vts --module VtsHalWifiV1_0Host
Test: Will need to ask OEM to verify the fix.
Change-Id: I0958d720411258761f4ac5bcccc823b06a55d518
Previously, VTS would run VtsHalWifiV1_0HostTest, a python script on the
host that tries identify whether SoftAP and NAN should be supported by
the device. This is complex, prevents migration to pure gtests without
custom runners, and duplicates logic that has become available in VTS.
This switches to equivalent methods natively available in VTS:
- NAN: We can use "precondition-feature" to check for the
"android.hardware.wifi.aware" feature.
- SoftAP: We can use "precondition-lshal" to check whether the
"android.hardware.wifi.hostapd" HAL is declared in the device manifest
(should have the same semantics as the previous python check).
This splits out NAN- and SoftAP-dependent parts of IWifiChip tests so
that they can use this method, so some tests moved between these targets:
- VtsHalWifiV1_0TargetTest
- VtsHalWifiApV1_0TargetTest
- VtsHalWifiNanV1_0TargetTest
Bug: 142304083
Test: vts-tradefed run vts --primary-abi-only --skip-device-info -l DEBUG --include-filter VtsHalWifiV1_0Target --include-filter VtsHalWifiApV1_0Target --include-filter VtsHalWifiNanV1_0Target --include-filter VtsHalWifiV1_1Target --include-filter VtsHalWifiV1_2Target --include-filter VtsHalWifiV1_3Target --include-filter VtsHalWifiApV1_4Target
Change-Id: Ica0b58811a0aa152c1a6c3c9a35d577d6ae70160
hidl-generated makefiles are now generated such that bpfmt(file) == file.
Bug: 67417008
Test: enable bpfmt hook
Change-Id: I1f69d292bc23a7cc293a66110cb02d597e1019ad
This commit fixes backward compatibility for the vts tests. For devices
supporting IWifiChip@1.3 HAL interface, getCapabilities_1_3() should be
used instead of getCapabilities() in older HAL version vts tests.
Bug: 120912623
Test: VTS tests run successfully for all HAL versions
Test: run vts -m VtsHalWifiV1_0TargetTest
Test: run vts -m VtsHalWifiV1_1TargetTest
Test: run vts -m VtsHalWifiV1_2TargetTest
Test: run vts -m VtsHalWifiV1_3TargetTest
Change-Id: Ife61bbbbdc8f7c0862f511fbe2b76519bec98941
Update OWNERS to reflect all the current directories under Wi-Fi
team development.
Bug: 110536740
Test: N/A
Change-Id: I6f12400b11be0fa92bc09a730dfd567d7702ef7a
In preparation for new feature development - uprev the Wi-Fi Treble HAL
revision from 1.1 to 1.2.
This CL does not contain any functional changes to the HAL itself. Only
updating the revision.
Bug: 65647646
Test: builds and Wi-Fi runs
Change-Id: I8e80e866562a508bf481104a3dbcf2bd8f8015b4
To prevent property name collisions between properties of system and
vendor, 'vendor.' prefix must be added to a vendor HAL service name.
You can see the details in http://go/treble-sysprop-compatibility.
Test: succeeded building and tested on a walleye device
Bug: 36796459
Change-Id: I4e8fbee791ec917a8f627a1366f4d44ec7e6febc
IWifi::stop() is currently non-blocking which makes it hard for the
client to determing when the stop is fully complete. This for example
causes wificond to disable the wlan0 interface while the legacy HAL
stop is being processed. So, add a timed wait to let the legacy HAL
complete processing of the stop before we unblock the IWifi::stop()
HIDL call.
Bug: 64611487
Test: Manual tests by wifi state toggling and verifying the order of
events in logs:
08-15 19:17:53.302 796 796 I android.hardware.wifi@1.0-service:
Stopping legacy HAL
08-15 19:17:53.302 796 796 I WifiHAL : Sent msg on exit sock to
unblock poll()
08-15 19:17:53.302 796 4793 E CLD80211:
/vendor/bin/hw/android.hardware.wifi@1.0-service: Could not find group
host_logs, errno: 0 id: -2
08-15 19:17:53.302 796 4793 E CLD80211:
/vendor/bin/hw/android.hardware.wifi@1.0-service: Could not find group
fw_logs, errno: 0 id: -2
08-15 19:17:53.302 796 4793 E CLD80211:
/vendor/bin/hw/android.hardware.wifi@1.0-service: Could not find group
per_pkt_stats, errno: 0 id: -2
08-15 19:17:53.302 796 4793 E CLD80211:
/vendor/bin/hw/android.hardware.wifi@1.0-service: Could not find group
diag_events, errno: 0 id: -2
08-15 19:17:53.302 796 4793 E CLD80211:
/vendor/bin/hw/android.hardware.wifi@1.0-service: Could not find group
fatal_events, errno: 0 id: -2
08-15 19:17:53.302 796 4793 I CLD80211:
/vendor/bin/hw/android.hardware.wifi@1.0-service: Sent msg on exit sock
to unblock poll()
08-15 19:17:53.302 796 4793 I android.hardware.wifi@1.0-service:
Legacy HAL stop complete callback received
08-15 19:17:53.304 802 838 D CHRE : @ 151.328: [Platform] wifi:
has 0, enabled 0
08-15 19:17:53.321 796 4793 I android.hardware.wifi@1.0-service:
Legacy HAL event loop terminated
08-15 19:17:53.321 796 796 I android.hardware.wifi@1.0-service:
Legacy HAL stop complete
08-15 19:17:53.522 796 796 I android.hardware.wifi@1.0-service: Wifi
HAL stopped
Test: Will send for regression tests.
Change-Id: I394c11724e9459a4b9a6b970e2bcb4e0ad65fefc
IE elements should not be present in the batched scan results, but it
being there doesn't cause any problems. The IE elements will be ignored
when we send it over the HIDL interface, so reduce the log level to
prevent log spamming.
Bug: 64448186
Test: None
Change-Id: Ia0d0312a113c907bb0992bb8f41e734fe9d05114
This reverts commit 8ac1971678.
Reason for revert: Didn't remove automotive changes from this CL.
Merged-In: I8608c8f636c35f21e4246a805a9eff6d14124e0a
Change-Id: I1c660cffc8817ad0b33da9f6eceb3d88e7c48416
And use VtsHalTargetTestDefaults.
Bug: 64040096
Test: crop out all non-affected tests from vts-hal-hidl.xml and run
vts-tradefed run commandAndExit vts-hal-hidl --skip-all-system-status-check
--skip-preconditions
2 failures, same as without this change:
GatekeeperHidlTest.DeleteAllUsersTest
GatekeeperHidlTest.DeleteUserTest
Change-Id: I8f6995e9536a9aefe283ee3effec9f5a7f03b620
When IWifi.stop() is invoked back to back (happens in the ConfigureChip
vts test), the HAL would return ERROR_NOT_AVAILABLE if the previous stop
is still being processed. This is not an error that needs to fail the test,
but a legitimate status for stop. We have a retry mechanism to handle
this in both the VTS test and framework for the case where IWifi.start()
is invoked while the previous stop is being processed.
While there, corrected a few log messages emitted by the HAL to debug
such startup/stop issues better.
Bug: 63971806
Test: `vts-tradefed run commandAndExit vts --skip-all-system-status-check
--primary-abi-only --skip-preconditions --module VtsHalWifiV1_0Target -l
INFO`
Change-Id: I5e3470ac97541a6ea10aceec9b737e5d03ed5206
Update the Android.bp generated with hidl-gen.
Test: build with and without BOARD_VNDK_VERSION=current
Bug: 63866913
Change-Id: I1a9db1df49e0f13c5790da2b118ae9ec63ba34a7
Allow HAL definition libs to be static.
Bug: 32920003
Bug: 64040096
Test: update-all-google-makefiles.sh
Change-Id: I1483d572bea6799717d1614fb7d52fe225e31104
Modifying the interface used to lower the tx power level for meeting SAR
requirements based on recommendation from the nexus hardware team. The
previous interface passed in a single power value in dBm for meeting SAR
requirements. However, the SAR requirements are more complex than that.
Based on the connection mode (802.11 a,b,g,n,ac) and the number of
streams that are active (MIMO), the SAR power levels are very
different. Using the previous interface would mean that we will have to
use the lowest power level among all the connection modes to meet the SAR
requirements. This would however result in us lowering the power much
more than needed (~2 dBm) for many connection modes.
Instead, we're switching to a more generic interface where the framework
informs the wifi chip that we're entering a special tx power mode scenario
(today, there is only 1 for voice call). The chip can then lookup the
extensive table of power levels for different connection modes which are
pre-populated by the OEM's in the BDF file to set the power level (depending
on the scenario framework sends and the active connection mode).
Bug: 62437848
Test: Manual tests
Change-Id: I5ee3f0d2c130958dbeb352e3b5ad9407f432624f
Change the order of shutdown to invalidate chips before
shutting down the legacy HAL. Allows pre-shutdown commands
to be sent down.
Bug: 63704506
Test: NAN tests passing
Test: full regression suite
Change-Id: I03d237d732b4e3482b1e1639848342dfdde9fcb7
