(mostly autogenerated, with minor tweaks to make it build)
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5a5ba231cb38886b9b681b4c08d89a18ad418f23
Maciej Żenczykowskicommited 2025-08-07 15:48:28 -07:00
(mostly autogenerated, with minor tweaks to make it build)
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I718fca9ed8a4329cc53b0479159c35601e2f20d6
Maciej Żenczykowskicommited 2025-08-05 19:15:35 -07:00
(mostly autogenerated, with minor tweaks to make it build)
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ieb2be6e5515fe2b9077b1ffeb1c07628213595b3
Maciej Żenczykowskicommited 2025-08-05 19:15:35 -07:00
(mostly autogenerated, with minor tweaks to make it build)
Test: TreeHugger, manually
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iab85fc8e035d77347f4b4fd1cd5ecaf94174d997
Maciej Żenczykowskicommited 2025-08-05 19:15:35 -07:00
This refactoring changes how the bluetoothUseRandomAddress flag is
accessed.
PrivateAddressCoordinator is in a library used by multiple mainline
modules(Tethering, NetworkStack, CaptivePortal, WiFi) and cannot
directly read a Tethering mainline beta flag.
To fix this, the flag's value is now passed down through constructors.
An alternative solution would be to split the Java library for each module,
but with this solution, a single utility class cannot be shared.
This commit is a no-op as the passed value is hardcoded to false.
Test: TH
Flag: EXEMPT refactor
Bug: 287177081
Change-Id: I5f2174ee94b55e7a7298b9742221d6e6c3c5cac5
After T, Bluetooth tethering could use a random address. But if we keep
putting the legacy Bluetooth address in the cache, the coordinator will
always assign the legacy address first until it runs into a conflict.
This change in itself does not do anything. Once we have a
trunk-stable namespace for mainline beta, we will add a flag for
this change, and check the flag in PrivateAddressCoordinator.
Bug: 287177081
Test: new unit tests
Flag: EXEMPT no behaviour changes
Change-Id: I56810b5b0e1098a5f89cbb1ad665d2b8652e860c
Yuyang Huangauthored and Lorenzo Colitticommited 2025-06-26 15:14:47 +09:00
EthernetTethering tests on auto devices are flaky waiting for RA. Increased timeout will give a more generous window to receive RA.
Flag: EXEMPT bugfix
Bug: 418010532
Test: atest android.net.EthernetTetheringTest#testLocalOnlyTethering --iterations 50
Test: atest android.net.EthernetTetheringTest --iterations 20
Change-Id: I6092ee805267a6d50fa2842d3131eeae544c3443
If the PAN service disconnects before the BT iface is available, the BT
TetheringRequest will be stuck pending and prevent any new BT
startTethering attempts. This may happen if the user turns BT tethering
on and turns off BT without connecting to any device.
Fix this by always removing the pending BT request when the PAN service
disconnects.
Flag: EXEMPT minor bugfix
Bug: 420412916
Test: atest TetheringTest, manually verify turning BT tethering on,
turning off BT, and turning BT tethering on again.
Change-Id: I6bc96d6e4016d83af6cfd8e549d474ce651a44fc
Quang Anh Luongcommited 2025-06-04 09:46:51 +09:00
The failure is caused by a RA packet read race condition. The test
receives a callback that local-only tethering has started and
immediately begins listening for an RA. However, the system's RA daemon
may not have finished initializing.
The test's packet reader times out waiting for an RA and returns a null
packet. The waitForRouterAdvertisement then uses the null packet
checking for RA, causing NPE. Change modifies waitForRouterAdvertisement
to check if a packet is null before processing it.
Flag: EXEMPT bugfix
Bug: 418010532
Test: atest android.net.EthernetTetheringTest#testLocalOnlyTethering
Change-Id: Ic534c53766958ae48a82687a9bd6d09297f074f2
This class doesn't actually serve a purpose, it only makes
TestableNetworkCallbck more complex.
Test: CtsNetTestCases ConnectivityCoverageTests
Flag: EXEMPT test-only
Change-Id: I39a598b82a3215384bdfe04980f4b280ab2c2716
* changes:
Remove ensureIpServerStartedLegacy.
Never create IpServers based on interface up for WIFI and WIFI_P2P.
Rename the methods in the legacy codepath for clarity.
Patrick Rohrauthored and Android (Google) Code Reviewcommited 2025-05-16 02:15:46 -07:00
This is not necessary because creating the IpServer based on
interface events is only necessary for the tether() API, and
field metrics indicate that that API is unused for WIFI and
WIFI_P2P.
Also add comments to clarify when the legacy codepath is taken.
Bug: 408087033
Test: updated unit tests
Flag: EXEMPT refactor
Change-Id: I64734ee710e9782903d4422efb0370d6fec77dd7
Lorenzo Colitticommited 2025-05-16 15:06:36 +09:00
AOSP code has never used this API, and metrics from production
show no usage either. Removing it will allow simplifying the
code.
This CL removes testRequestStaticIpLegacyTether because it makes
legacyTether a no-op and there is already a test for static IP
request right above it.
Bug: 408087033
Flag: EXEMPT dead code
Test: updated existing tests
Change-Id: Ib94ed0860ab57abfd9fc7bdfdc911f5ab57003ed
Lorenzo Colitticommited 2025-05-13 19:43:58 +09:00
Currently, Tethering feature flags are located in
TetheringConfiguration or other classes. However,
not all flags are truly related to the tethering configuration.
Therefore, create the TetheringFeatureFlags class to centralize
and manage these feature flags more easily.
Test: m
Flag: EXEMPT refactor
Change-Id: Iadca476aba57019776061102cb2a6d8226a70200
Since the feature was fully rolled out via experiment without
regression, this commit replaced with a
kill switch.
Flag: EXEMPT refactor
Test: atest ConnectivityCoverageTests:PrivateAddressCoordinatorTest
Fix: 312647670
Fix: 406955982
Change-Id: I18adcca45fa5f698adc80cea044d8006de097977
* changes:
Add integration test of tethering local network agent feature
Add unit test of tethering local network agent feature
Support LocalNetworkAgent for Tethering
Treehugger Robotauthored and Gerrit Code Reviewcommited 2025-03-21 07:42:40 -07:00
Currently, apps targeting V can see thread local network.
This change introduces a mechanism to make existing
apps unable to see non-thread local networks to ensure minimal
impact on existing devices and applications while adopting this
behavior. Apps targeting B+ Sdk and run on V+ devices can see
non-thread local networks.
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.CSLocalAgentTests \
--update-device
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server --update-device
(on next/trunk_staging release config)
Bug: 349487600
Change-Id: I6aa43cebc20a9017c2d8a8a90ebb1d53040a27bb
Allow carrier-privileged apps to call startTethering and stopTethering
for wifi tethering with a non-null SoftApConfiguration.
Bug: 295979433
Test: atest TetheringTests CtsTetheringTests
Change-Id: I7fae1964c44902b1d500729794fc59e5bdd185e5
Quang Anh Luongcommited 2025-03-21 18:25:28 +09:00
Allow DO apps to call startTethering and stopTethering for wifi
tethering with a non-null SoftApConfiguration.
Bug: 295979433
Test: atest TetheringTests CtsTetheringTests
Change-Id: Ie5836e9e30afb2df1de0640645d696e185aa2191
Quang Anh Luongauthored and Quang Luongcommited 2025-03-19 03:30:48 -07:00
Use WifiManager.startTetheredHotspot(TetheringRequest, Executor,
SoftApCallback) to start softap. This allows for passing in the
requested SoftApConfiguration via TetheringRequest.
Bug: 216524590
Test: atest TetheringTest TetheringManagerTest
Change-Id: Ie4fb851e8b2243d233f9a8b3e18e2fa335cec307
Quang Anh Luongcommited 2025-03-17 21:13:47 +09:00
TetheringTest has several tests that rely on starting Wifi tethering,
but do not mock WifiManager.startTetheredHotspot. This causes the
pending Wifi request to be removed, even though the test continues
thinking that the call succeeded and continues mocking Wifi AP events.
Fix this by making sure the mock returns true in setUp(), and only set
it to false when we expect that the call should fail.
Bug: 216524590
Test: atest TetheringTest
Change-Id: Iaf076b9ae64d737a8591c7f41a5552757b47999b
Quang Anh Luongcommited 2025-03-17 15:18:29 +09:00
isTetheringWithSoftApConfig flag is finalized, replace it with a simple
SdkLevel.isAtLeastB() check. This also fixes any issues with reading the
flag during boot.
Bug: 216524590
Test: covered by existing tests
Change-Id: I6c2717a68fa4f3c664c9948ec19b246db5afdb8b
Quang Anh Luongcommited 2025-03-17 15:18:29 +09:00
stopTethering with a TetheringRequest should only stop tethering if
there is an existing request (pending or serving) that fuzzy-matches the
input and whose UID matches the caller (unless the caller is Settings,
which is allowed to remove any request).
If there is no existing fuzzy-matched request, return
TETHER_ERROR_UNKNOWN_REQUEST.
Note: This was originally merged as aosp/3527440 but was reverted due to
a dependency CL being reverted. Remerging this on top of the fix for the
dependency CL.
Reverted changes: /q/submissionid:3541662-revert-3527440-JRJJTQBUFC
Bug: 216524590
Test: atest TetheringTest RequestTrackerTest TetheringManagerTest
Change-Id: I99dd2433efbb82f3721aa708ab50d198f6fbcb10
Quang Luongauthored and Quang Anh Luongcommited 2025-03-17 15:18:29 +09:00
Legacy behavior will return success results to multiple startTethering
calls of the same type, even though the link layer can only support one
of those requests at a time (other than tethered AP + LOHS).
For B+, clean up this behavior by only allowing the amount of requests
that the link layer can concurrently support. To do this, we'll
introduce the concept of "fuzzy-matching" such that if a new request
fuzzy-matches an existing request (either pending or serving), this
indicates that the link layer cannot support the new request
concurrently, and we'll fail the new request with
TETHER_ERROR_DUPLICATE_REQUEST.
To keep track of serving requests, we'll store the request and it's
IpServer in RequestTracker when we call IpServer.enable(), and we'll
remove it (indexed by IpServer) when
1) Calling IpServer.onStop()
2) Calling IpServer.unwanted()
3) We detect an IpServer transition to AvailableState with error code
Note: This was originally merged as aosp/3529632 but was reverted due to
a crash when reading aconfig flags at boot. That issue has been fixed
here.
Reverted changes: /q/submissionid:3541662-revert-3527440-JRJJTQBUFC
Bug: 216524590
Test: atest TetheringTest RequestTrackerTest TetheringManagerTest
Change-Id: I87a1ed31927cda27d3b7fdd7c823b8f828f8d777
Quang Luongauthored and Quang Anh Luongcommited 2025-03-17 15:18:29 +09:00
Maciej Żenczykowski
commited 
Chalard Jean
authored and
Yuyang Huang
commited 
Motomu Utsumi
commited 
Lorenzo Colitti
commited 
Patrick Rohr
authored and
Android (Google) Code Review
commited 
Chris Desir
commited 
Quang Anh Luong
commited 
Paul Hu
commited 
Treehugger Robot
authored and
Junyu Lai
commited 
Automerger Merge Worker
commited 
Gerrit Code Review
commited