RaParams is populated with the upstream IPv4 MTU, rather than the IPv6
or route MTU. This change clamps that value between 1280 and 1400. 1280
as it is the minimum IPv6 MTU and 1400 to keep QUIC working. A follow up
change could improve on this by either adding the IPv6 MTU to
LinkProperties, or (possibly better) binding and connecting a UDP socket
to determine the MTU. Note that at that point the MTU in the Tether6Key
should also be fixed.
Test: TH
Flag: EXEMPT low risk
Bug: 432676104
Change-Id: I1d900039caf84c58cd04fdb52bdeaf2d1b846268
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
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
Offload HAL conntrack sockets are used for conntrack state dumps,
so should use the dump socket buffer size.
Bug: 409212357
Test: TreeHugger
Flag: EXEMPT mainline/trivial
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I73b4bb706efe55505b3646df63330de521a6df3f
Maciej Żenczykowskicommited 2025-05-19 10:49:35 -07:00
Today on R and S, it is theoretically possible for WiFi to start
tethering with interface name wlan0, but the tethering regexes to map
wlan0 to type TETHERING_USB, because ifaceNameToType(wlan0) could return
TETHERING_USB and the subsequent call to checkTetherableType() returns
true.
This change adds a telemetry express log to figure out whether this
actually happens in the field.
Test: TH
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: I59d6665670fc3210ddf8d49dc28917f000751ccd
Fold the method into its only caller. This is a no-op change.
The only types that could previously make it to this method are
BLUETOOTH pre-T and WIGIG pre-S. Therefore the call to
checkTetherableType is mostly redundant, except for the check
that WIGIG should not be brought up if the device does not
have FEATURE_WIFI. Put that check into the caller as well.
Bug: 408087033
Flag: EXEMPT refactor
Test: no-op covered by existing tests
Change-Id: I380d649c2fd8af8b00a55a5bb7d2254c8b126a34
Lorenzo Colitticommited 2025-05-16 15:06:36 +09: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
This is a no-op change.
ensureIpServerStartedForInterface -> ensureIpServerStartedLegacy
ensureIpServerStartedForType -> ensureIpServerStarted
Also pass in the type to ensureIpServerStartedLegacy. There's
no point reading calling ifaceNameToType again, the only thing
this can possibly do is get a new type that disagrees with the
previous one.
Bug: 408087033
Flag: EXEMPT refactor
Test: no-op covered by existing tests
Change-Id: Ie6f3859eab46a085c0d332b5de12473180032102
Lorenzo Colitticommited 2025-05-16 13:22:06 +09:00
To improve readability. Renames the forNcmFunction parameter to isNcm to
make it all fit on a single line.
Test: TH
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: Iafebc4398aaf061175c4f84c45b37975940ca587
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
It looks like the code was already trying to ignore this (it
reported an error to the caller), but it then continued on to
create a request and call tetherInternal on it. This is still a
no-op because the code will never create an IpServer for an
interface that has type INVALID: IpServers are only ever created
in ensureIpServerStartedForType, and the only callers are:
- ensureIpServerStartedForInterface, which returns early if the
type is INVALID.
- enableIpServing:
- enableWifiP2pIpServing: returns early if type is INVALID
- enableWifiIpServing: returns early if type is INVALID
- enableUsbIpServing: can only pass in USB or NCM
- BluetoothCallback#onAvailable: passes in BLUETOOTH
- EthernetCallback#onAvailable: passes in ETHERNET
- setVirtualMachineTethering: only called with VIRTUAL
- StartTetheringSoftApCallback#onStateChanged: passes in the
request previously passed to it by setWifiTethering, which
is always WIFI.
Bug: 408087033
Test: covered by existing tests
Flag: EXEMPT dead code
Change-Id: I8ebba3edde93677c54488803fe4b573d78ad25a9
Lorenzo Colitticommited 2025-05-13 18:56:31 +09:00
Terrible errors in Tethering.java aren't used to log actual errors, but
just to provide metrics on how often these expected codepaths occur. To
avoid spamming the android error logs or crashing eng devices, change
these to use info logs instead.
Flag: EXEMPT logging change only
Bug: 410470516
Test: atest TetheringTest
Change-Id: I4ec202231e79c32f727a7620a6cab08e850d1629
Quang Anh Luongcommited 2025-04-30 12:16:30 +09:00
Add tether start/stop events along with their TetheringRequests to keep
track of which uid/package made the request.
Flag: EXEMPT logging change
Bug: 409564618
Test: start/stop tethering and verify the new logs show up in dumpsys
Change-Id: Iab16b16208f0ede90d7119709f7ff4888c8b86df
Quang Anh Luongcommited 2025-04-21 10:52:54 +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
* 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
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
The feature will be gradually enabled via flag rollout.
Sample ip rule output:
0: from all lookup local
10000: from all fwmark 0xc0000/0xd0000 lookup legacy_system
11000: from all iif lo oif dummy0 uidrange 0-0 lookup dummy0
11000: from all iif lo oif rmnet1 uidrange 0-0 lookup rmnet1
11000: from all iif lo oif wlan0 uidrange 0-0 lookup wlan0
16000: from all fwmark 0x10063/0x1ffff iif lo lookup local_network
16000: from all fwmark 0x10064/0x1ffff iif lo lookup rmnet1
16000: from all fwmark 0x10066/0x1ffff iif lo lookup wlan0
16000: from all fwmark 0x10063/0x1ffff iif lo lookup wlan0
17000: from all iif lo oif dummy0 lookup dummy0
17000: from all iif lo oif rmnet1 lookup rmnet1
17000: from all iif lo oif wlan0 lookup wlan0
18000: from all fwmark 0x0/0x10000 lookup legacy_system
19000: from all fwmark 0x0/0x10000 lookup legacy_network
20000: from all fwmark 0x0/0x10000 lookup local_network
20000: from all fwmark 0x0/0x10000 lookup wlan0
21000: from all iif wlan0 lookup rmnet1
23000: from all fwmark 0x64/0x1ffff iif lo lookup rmnet1
23000: from all fwmark 0x66/0x1ffff iif lo lookup wlan0
31000: from all fwmark 0x0/0xffff iif lo lookup rmnet1
32000: from all unreachable
Test: adb shell device_config put tethering tethering_local_network_agent 1
Test: atest TetheringTests:android.net.ip.IpServerTest TetheringManagerTest
Bug: 349487600
Change-Id: Iaa88dde645da917149fec0d44fff796c551bcc7e
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
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
There are currently two variants of checkAndNotifyCommonError that do
the exactly the same thing, except one uses IIntResultListener and
another uses ResultReceiver. Remove the lesser-used ResultReceiver
variant and just use the IIntResultListener instead (with a
IIntResultListener wrapper for the ResultReceiver).
Bug: 216524590
Test: covered by existing tests
Change-Id: I292a96b32cd975852a52c7953b03bcb35728db24
Quang Anh Luongcommited 2025-03-14 15:27:49 +09:00
Revert submission 3527440
Reason for revert: Droidmonitor created revert due to b/403261952. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3527440
Change-Id: Ife596c639899528778f53fef797749fa88596dd6
Revert submission 3527440
Reason for revert: Droidmonitor created revert due to b/403261952. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:3527440
Change-Id: I31ae861d5151c9db7e559ba19db7f07c9545d422
Priyanka Advani (xWF)authored and Gerrit Code Reviewcommited 2025-03-13 10:22:16 -07: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.
Bug: 216524590
Test: atest TetheringTest RequestTrackerTest TetheringManagerTest
Change-Id: Ia8a8eab78fbecd38321fd0d48734855cff16febb
Quang Anh Luongcommited 2025-03-13 12:49:08 +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
Bug: 216524590
Test: atest TetheringTest RequestTrackerTest TetheringManagerTest
Change-Id: I1e193f3595a48f806fb70fd08630a12ce2631a59
Quang Anh Luongcommited 2025-03-13 11:11:17 +09:00
Replace the explicit SDK_INT checks with the helper function
SdkLevel.isAtLeastB().
Bug: 216524590
Test: covered by existing tests
Change-Id: I32ae771d5b157d97dfbe3c37caf62e734eaa250e
Quang Anh Luongcommited 2025-03-11 17:16:56 +09:00
Currently there may be multiple identical bluetooth requests waiting for
the PAN service to connect before their listeners are notified. To
simplify future code, we should only allow one pending request/listener
pair at a time, and reject every subsequent request with
TETHER_ERROR_SERVICE_UNAVAILABLE.
This should be OK because
1) Bluetooth tethering is hardly used at all
2) Settings disallows extra startTethering calls between the first call
and the bluetooth service starting
3) Apps are expected to handle TETHER_ERROR_SERVICE_UNAVAILABLE
correctly.
Bug: 216524590
Test: atest TetheringTest
Change-Id: I8375d495575715f428e893316f7cd7e5a7ebba59
Quang Anh Luongauthored and Quang Luongcommited 2025-03-10 21:02:50 -07:00
This is a no-op refactoring which inline the functionalities
to IpServer, enabling subsequent changes to move
networkAddInterface part to ConnectivityService when the
tethering is enabled.
Test: atest TetheringTests:android.net.ip.IpServerTest
atest NetdStaticLibTests:com.android.net.module.util.NetdUtilsTest
Bug: 349487600
Change-Id: I6d0e5d349691df7a15bee852d5fd1dd19f5da6f6
This is a no-op, preparatory refactoring to isolate route
modification functionality, enabling subsequent changes to move
routing control to ConnectivityService.
Test: atest TetheringTests:android.net.ip.IpServerTest
atest NetdStaticLibTests:com.android.net.module.util.NetdUtilsTest
Bug: 349487600
Change-Id: I55af07968567b173dd9f97795600390439f1b927
Pending requests should be updated via a helper class RequestTracker
and stored in a Request wrapper object. This will help out with future
changes to associate each TetheringRequest with it's own
IIntResultListener and make it easier to gate behavior changes.
Bug: 216524590
Test: atest TetheringTest RequestTrackerTest
Change-Id: Ib867e91863bdf618bb0e955eeb529cd132209d77
Quang Anh Luongcommited 2025-03-06 15:18:28 +09:00
* changes:
no-op: use stopTetheringInternal when restarting tethering on start
Use pending request when legacy tethering
no-op: Add test to verify legacyTether does not use explicit request
Quang Luongauthored and Gerrit Code Reviewcommited 2025-03-04 02:25:35 -08:00
startTethering will sometimes restart tethering if there is an existing
request of the same type but with different contents. This call is
equivalent to stopTetheringInternal, so use that instead for simplicity.
Bug: 216524590
Test: covered by existing tests
Change-Id: I224c10557c2348e2d2f971e1e3ecb11ae346d2cf
Quang Anh Luongcommited 2025-03-04 16:58:43 +09:00
Legacy tethering was changed to use it's own tethering requests
with REQUEST_TYPE_LEGACY in aosp/3465235 instead of using the pending
request as it was thought that pending requests (from startTethering)
and legacy tethering would always be mutually exclusive.
However, pre-T Bluetooth tethering actually relies on
startTethering(request) to add the pending request, and then BT service
directly calls legacyTether(iface) to start tethering. Thus we should
continue to use pending requests even for legacyTether.
Bug: 216524590
Test: atest TetheringTest
Change-Id: I0aa7b5cc6d6d54f516a07b0e89259c61e1d05f69
Quang Anh Luongcommited 2025-03-04 16:58:42 +09:00
The tether_enable_sync_sm flag has been successfully rolled out
to public stage on Pixel devices without any observed
regressions. As a result, this flag should be enabled by default
with a kill switch, allowing the feature to be deployed to all
production devices.
Test: atest TetheringTests CtsTetheringTest
Change-Id: I2f0f55c1586e1f4987b28488082c4c1f4cae0f5e
Since the feature was fully rolled out via experiment without
regression, this commit removes the flag and the corresponding
logic in PrivateAddressCoordinator. The flag is no longer
necessary and simplifies the code.
Test: atest ConnectivityCoverageTests:PrivateAddressCoordinatorTest
Fix: 312647670
Change-Id: I8781f98b7e99ed0856e9e04112056df5adca2527
Maciej Żenczykowski
commited 
Patrick Rohr
commited 
Chalard Jean
authored and
Yuyang Huang
commited 
Motomu Utsumi
commited 
Quang Anh Luong
commited 
Treehugger Robot
authored and
Android (Google) Code Review
commited 
Lorenzo Colitti
commited 
Paul Hu
commited 
Junyu Lai
commited 
Gerrit Code Review
commited 
Priyanka Advani (xWF)
commited