Currently Passpoint-r1 follows the PPS-MO format to install passpoint
profile.
Howevever, one field(SubscriptionParameter) is not correct.
Normally passpoint-r1 doesn't use this field because this is used for
passpoint-r2 feature.
So, currently there is no issue with wrong field for using passpoint-r1.
But, it needs to be "SubscriptionParameters" according to the hostpot2.0
release 2.0 techinical specification.
Bug: 111449001
Test: ./frameworks/base/wifi/tests/runtests.sh
Change-Id: Idb6bb4d28913bd3d0905b330e25fbb20b99bbf2e
Signed-off-by: Ecco Park <eccopark@google.com>
Added support to notify user of a change to their softap configuration
preferences after being restored via SettingsBackupAgent.
Bug: 80251951
Test: frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Test: manually confirmed configs are converted for different device
Change-Id: I4cec15549d694cdb1a7b09f1426d027eec021122
Add call @hide allowing settings to check if the device requires softap
configs be converted from 5GHz only to ANY
Bug: 80251951
Test: frameworks/base/wifi/tests/runtests.sh
Change-Id: Id4d435eb55e2696d23ceb4d301e5d039e134d66a
Wi-Fi RTT legacy API is (now) a wrapper around the new API. Two
new result parameters were added to the new API but not propagated
to the corresponding legacy API:
- Count of attempted measurements
- Count of successful measurements
Bug: 79883720
Test: unit tests
Test: RangeApSupporting11McTest:test_legacy_rtt_80211mc_supporting_aps
Change-Id: Id000c691c22319474e3e98f5ba5d77e4bb4c343e
Add a new network disable reason to temporarily blacklist an
auto-connected network.
Bug: 72635747
Test: Manually verified that device switched away from an
auto-connected network when it detects no internet.
Change-Id: Id3d2de05f6b2869c0b64d5e427e14573e8912905
Select preamble to use for RTT exchange using IEs advertised by the
AP rather than channel width (which is used as a backup method).
Bug: 69965964
Test: unit test & integration tests
Change-Id: I60ef31c4627795bd4da505f31998b49668d1a115
Clarify that service discovery callbacks may be triggered multiple
times (and that therefore apps should deal correctly with it). These
may happen for several reasons (not documented since too low level):
- Peer went out-of-hearing-range and came back
- Peer went out of geofence range and came back
- Concurrency limitations caused discovery to switch from ranging-based
to non-ranging-based or back
Bug: 77925576
Test: N/A
Change-Id: I9fbb909e5bd57fb714aa82bcfeb2834361722149
Per Effective Java, if a class implements equals(),
it should override hashCode().
Test: (new) unit tests
Bug: 37000525
Change-Id: If4175a7e2bc34935c525d0fb96fbbe1e904030e3
Use TimeUtils to format the time display fields which hold wall clock
time.
Also, use |elapsedRealTime| to calculate the time durations for the
fields which are populated using elapsedRealTime.
Bug: 77224338
Test: Unit tests
Test: 'adb shell dumpsys wifi'
Change-Id: I850ebdc3ba1f7bfb7d5137382d2feed7e551c311
The api for setWifiApConfiguration allows for config saves to return
false, but the implementation always returns true (if there wasn't an
exception thrown). This CL allows the API to actually return false and
adds unittests.
Bug: 67601382
Test: frameworks/base/wifi/tests/runtests.sh
Test: frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Test: manually update ap config in settings and verify save
Test: wifi integration tests
Change-Id: I038ab68f5fc4bf22df5b61d329077eacda547338
Some call sites using explicit TRANSPORT types want to know about the
raw underlying transport, and they don't want to know about VPNs
that are going over that transport.
For example, SettingsLib always wants to know about the actual
Wi-Fi network, so it uses NOT_VPN to avoid being confused by VPN
networks that are backed by a TRANSPORT_WIFI network.
GnssLocationProvider wants to know about any validated internet
access, regardless of the underlying transport.
Test: atest com.android.settingslib.wifi
Bug: 68499889
Change-Id: Ib5897946d856444d9ff3b54c4aeace6baa42f8bf
The RTT distance and standard deviation are calculated based on a set
of N measurements. Of those M (M<=N) may be successful.
The quality of the provided results can be assessed by 2 measures:
1. The standard deviation of the results
The standard deviation is only valid if the number of successful
measurements is >1 otherwise a 0 is returned. A value of 0 cannot be
differentiated from a legitimate 0 standard deviation.
In one case (number of samples > 1) a standard deviation of 0 indicates
high confidence in the result. In the other case (number of samples = 0)
no confidence information can be derived.
2. The ratio of successful to total attempted measurements
Add API which provides the number of attempted measurements and number
of successful measurements used to calculate the final results.
Bug: 76445930
Test: N/A (unhide CL only, code verified earlier)
Change-Id: Ia7322b3abc28e83c29d0b0ae79db30fd99bb7fe1
Add information about the number of attemped and successful measurements
used to calculate the final results (especially critical for standard
deviation).
Bug: 76445930
Test: unit tests & integration tests
Change-Id: I906b6e8a4d74799447ab7c2e55965fdd448dc470
Since we are using "02:00:00:00:00:00" as the default/invalid MAC
address in the Wifi Framework, we should make it invalid for Connected
MAC Randomization for consistency.
Updated the configuration to use "02:00:00:00:00:00" as the default
invalid MAC and attempt multiple time to generate valid random MAC.
Bug: 74436465
Bug: 74446723
Test: Unittest
Change-Id: Ia5ac806d478191d7e8fad247d5c3a1b97d16498f
This is needed for client mode operations for configuring WPA_PSK
networks. There is no alternative public value for WPA_PSK.
The intention was to deprecate usage of this value for AP
mode, but since we share the same object across client & AP mode
operations, we cannot mark this field deprecated.
Bug: 72332080
Test: make update-api
Change-Id: I75f675b630080d853422f945d7cbc37c5f205fde
This is an internal cleanup patch
Bug: 68388459
Test: compile, unit tests
Test: manual test that wifi scan still works
Change-Id: I30ee0b342a04fe55fc8da8142600ccc4d34b30c1
Clarify that limits include "=". This is particuarly critical for
the lower range value of 0 since in very close quarters measurements
will result in negative values which will be translated to a 0 - i.e.
must have >=0 for ranging to trigger discovery.
Bug: 65108607
Test: N/A
Change-Id: I443c2fff7fe8dad6133d66a82f645a8304787f4c
Clarify that this method is only available to device owner and
profile owner.
Change-Id: I2f77a16442a0403cc7895bdc3b8375cb22cb68a9
Fixes: 70038439
Test: builds
Removing @hide class that's not being used.
Bug: 74019502
Test: compile, run ./frameworks/base/wifi/tests/runtests.sh
This is CP from master fbce0f15544edc80b1ae49061f6fee365e3a2fea
Change-Id: I8b364bfa09f6fe6a585fbec01e5ff94b8b745bca
Responder to ANYONE was deprecated for API >= P. But the manager
code did not check for target API - i.e. even older apps would have
been rejected. Added the target API check to the manager code.
Bug: 72175022
Test: unit test + integration tests
Change-Id: I52e0c877e0af0756816b5b13e42f432504461e20
