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
Add a TetheringRequest argument to enableTetheringInternal and
sendTetherResult so we can pass the request to Wifi in a later CL.
Also pass through for TETHERING_VIRTUAL to use the request and
interface directly.
Note that removing getOrCreatePendingTetheringRequest in
setVirtualTethering is also a no-op:
- If setVirtualTethering is called from startTethering, the request
that is now passed in as a parameter is the exact same one that
was just inserted into the pending list, and which the old code
would have obtained from getOrCreatePendingTetheringRequest.
- If setVirtualTethering is called due to an IP conflict, both the
old and the new code use a placeholder request with no interface.
This codepath was already broken before this CL (and likely has
never worked).
Bug: 216524590
Test: covered by existing tests
Change-Id: I3cb9b5ed44e83bb6bbf4ed77c37cbf35e306f08b
Quang Anh Luongcommited 2025-02-13 19:09:01 +09:00
enableTetheringInternal immediately sends the tether result for all
types except for TETHERING_BLUETOOTH, which relies on
setBluetoothTethering to sends the result immediately if the Pan
service is connected, or defer the result until after the Pan service
connects.
To keep better track of the active listeners and simplify the logic for
further listener behavior changes (i.e. notifying the listener after the
link layer event), refactor the bluetooth listener to be called
immediately within enableTetheringInternal if the Pan service is
connected like the other tethering types.
Bug: 216524590
Test: covered by existing tests
Change-Id: I91196e430b44ef2391de662ff0ed6e051b453d98
Quang Anh Luongcommited 2025-02-13 18:50:27 +09:00
Currently, WIFI_AP_STATE_CHANGED for LOHS will use any pending Wifi
TetheringRequest to start the IpServer. This is a bug, since pending
Wifi requests are always for tethered SoftAP, not LOHS. This means if
there's already a pending request for tethered SoftAP, we will
mistakenly use the tethered SoftAP request for LOHS. Then, when the
WIFI_AP_STATE_CHANGED event for the tethered SoftAP arrives, the pending
request for it will already be gone.
Fix this by always having LOHS use an implicit LOHS TetheringRequest
instead of taking the request from the pending list.
Bug: 216524590
Test: atest
Change-Id: Ic349e0b0688addf6a41b3de0528d444d716846a2
Quang Anh Luongcommited 2025-02-13 10:25:20 +09:00
If there are pending pan requests for an enable but a disable request
comes (or vice versa), remove all the pending requests and pre-emptively
fail their result listeners. This simplifies the logic and helps us
keep track of which request the future link layer event should be long
to.
Technically this is an app-visible behaviour change. In particular, if
something disables bluetooth tethering while the service is
disconnected and request(s) to enable tethering are queued, then the new
code will immediately send onTetheringFailed to all those requests,
whereas the old code would wait until the service connects, enable
tethering (and send the enabler an onTetheringStarted), and then disable
it. Given that this situation is very rare, and Bluetooth tethering is
itself so uncommon (<1% of total tethering sessions) this is an
acceptable trade-off.
Bug: 216524590
Test: atest TetheringTest
Change-Id: I061733d714894b741e7d686810dd39f054e85476
Quang Anh Luongcommited 2025-02-13 10:24:42 +09:00
Add a basic implementation of stopTetheringRequest that simply stops
tethering for that specific type if it is active, or fail with
TETHER_ERROR_UNKNOWN_REQUEST if not. In the future, we will do fuzzy
matching to ensure the correct request is removed.
Bug: 216524590
Test: atest TetheringManagerTest#testStopTetheringRequest
Change-Id: Ib4a660aacdb83e645e39ceb61b7cda45bb24d89d
Quang Anh Luongcommited 2025-01-31 16:23:04 +09:00
IpServer#enable is called with both a non-null TetheringRequest and the
requestedState, but the requestedState is derived from the
TetheringRequest's connectivity scope. Remove this requestedState arg
and simply have IpServer read the connectivity scope itself.
Bug: 216524590
Test: covered by existing tests
Change-Id: I73227f5053da3a2ab35563268fc416b6dd9b1801
Quang Anh Luongcommited 2025-01-30 14:30:51 +09:00
Currently the enableIpServing->tetherInternal call stack may have a
tethering request alongside a redundant tethering type and requested
state. The redundant arguments were necessary since there may be cases
where the active request is null (e.g. back-to-back start/stop, which
removes the active request before the link layer event enables ip
serving).
This change gets rid of the redundant arguments and makes the call stack
take a non-null TetheringRequest. In case the active request is not
found, we will create a placeholder request with just the type and
connectivity scope (i.e. requested state). This should be equivalent to
the old code of sending a null request (since none of the other fields
in TetheringRequest are used), making this a no-op change.
Bug: 216524590
Test: covered by existing tests
Change-Id: I5ac83c74f5bc4aec2fe85daa9477740749d95c63
Quang Anh Luongcommited 2025-01-30 14:30:49 +09:00
mActiveTetheringRequests is a misnomer because the requests aren't
actually active yet. Rename this to mPendingTetheringRequests since
they're pending a link layer event that the iface is ready to start IP
serving.
Bug: 216524590
Test: covered by existing tests
Change-Id: Ib0c4a52e0aa72fc27b67bce25187124b20082c05
Quang Anh Luongauthored and Lorenzo Colitticommited 2025-01-29 17:15:53 +09:00
The fact that the two overloads have the same name is confusing
because one of them fetches the type and one of them has it
passed in. This means it's not obvious whether they behave
identically or not.
This is a no-op refactor.
Bug: 216524590
Test: covered by existing tests
Change-Id: Iff7d2981cb5835831f00117166035d48b44a61a4
Lorenzo Colitticommited 2025-01-29 17:11:37 +09:00
Currently, the active TetheringRequest (if any) is fetched at the
very bottom of the stack, just before enabling the IpServer.
Have the callers pass it in instead.
This CL is a no-op refactor. In particular, it ignores the fact
that the TetheringRequest can be null, and that the connectivity
scope in the request might not match the requested state, etc. -
it just documents the current behaviour (bugs included) and
leaves it unchanged. It exists only to make future changes
easier.
Bug: 216524590
Test: covered by existing tests
Change-Id: Ie8af8b718a9de1f1d5adde0ac589060dce112a27
Lorenzo Colitticommited 2025-01-29 17:11:37 +09:00
There is no safe way to invoke this method correctly since the
package might not be installed for certain user type by OEM.
Thus, improve error handling and logging into WTF counter metrics.
Test: Manual:
1. Use internal main branch
2. Modify xml under vendor/google/data/etc/sysconfig to
configure tethering only installs on the SYSTEM user
3. Mock the device as entitlement required (ag/29664886)
4. Create a secondary user which has the permission to
enable tethering (go/hsum)
5. adb shell pm list packages --user 10 | grep tether
6. m statsd_testdrive && statsd_testdrive -e 979
7. Enable tethering
Test: atest TetheringTests:EntitlementManagerTest
Bug: 382628161
Change-Id: I233cad672e41d2b4687e53e61b93dcea9eb07817
Add TetheringRequest#RequestType to distinguish the type of
TetheringRequest (i.e. from startTethering, from implicit broadcasts, or
from the legacy tether API) as well as helper methods to create these
requests. These will be used in a future CL.
Bug: 216524590
Test: build
Change-Id: Ibfda48f59e80d423c9b6ee0d244cbdab14be1bd2
Quang Anh Luongcommited 2025-01-21 17:48:38 +09:00
Log extra enums to audit usages of Wifi/P2P tether() that successfully
resulted in tethering on an interface.
Bug: 216524590
Test: build
Change-Id: Ia0d2a8fc1e508263c597bfd40fbefe5b49ec15d5
Quang Anh Luongcommited 2025-01-15 16:15:37 +09:00
As part of the major tethering refactor to associate every IpServer with
a TetheringRequest, tether()/untether() APIs should be completely
removed in B and all tethering should go through startTethering() (with
the exception of Wifi LOHS and Wifi P2P, which will move to
startTethering() in a future CL).
Bug: 216524590
Test: atest CtsTetheringTests TetheringTests
Change-Id: If7981f1ee7d80ff0a1cc0069ba7a4ebf79144160
Quang Anh Luongcommited 2025-01-15 08:59:42 +09:00
This reverts commit 685b8aa508.
Reason for revert: May break Bluetooth pre-T IPv4 prefix conflict handling if TetheringRequest is not specified. Instead we should add this to AOSP/3389321 when we can guarantee IpServer always has a tethering request here.
Bug: 384812983
Test: presubmit
Change-Id: I9c65e87804855fd293fa75c921de3d256caad1b3
TetheringManager#tether() is deprecated and should not be used anymore,
especially for Wifi and Wifi P2P which already start and enable IpServer
based on WIFI_(AP/P2P)_STATE_CHANGED broadcast.
In order to refactor Tethering to only start IpServer with a final
TetheringRequest, we need to audit usage of tether() with Wifi and Wifi
P2P so that we can safely remove it from
Tethering.processInterfaceStateChanged (which starts an IpServer without
TetheringRequest in anticipation of a tether() call).
Bug: 216524590
Test: build
Change-Id: Ieb4bd14150a8b25257bee8ddc71e30037ec3a122
Quang Anh Luongcommited 2024-12-19 22:48:06 +09:00
In the current design, the upstream monitor collects prefixes
of all upstream networks to prevent prefix conflicts,
which are coordinated by the PrivateAddressCoordinator.
However, the upstream monitor does not exclude the newly
added NET_CAP_LOCAL_NETWORK capability, which could be
held by a downstream network. This could lead to a prefix
conflict detection loop:
1. In UpstreamNetworkMonitor, a prefix is collected from
a local network and sent to the PrivateAddressCoordinator.
2. PrivateAddressCoordinator detects a prefix conflict with
an existing downstream prefix.
3. The conflict notification is sent to the local
network provider, triggering a recovery.
Test: atest TetheringTests:com.android.networkstack.tethering.UpstreamNetworkMonitorTest
Bug: 349487600
Bug: 382397803
Change-Id: I743d569394e190c8620b283689d853cd2f5e3f28
As TetheringManager moves to a Public API, remove the weak
WRITE_SETTINGS permission and use TETHER_PRIVILEGED instead. System
callers can still aquire TETHER_PRIVILEGED, and public callers must be
Device Owner or Carrier App to bypass (to be done in a future CL)
Bug: 374400379
Test: atest TetheringTest TetheringServiceTest CtsTetheringTests
Change-Id: Ia192021ac48f9eb3f27cc8c412f17629ad16a587
Quang Anh Luongcommited 2024-12-18 13:53:04 +09:00
Legacy duplicate tethering requests would restart tethering if a pending
request existed that was different (via equals()) from the new request.
However, this behavior existed before uid/package name was added to
TetheringRequest#equals(), so we should use new method to check
equality while ignoring uid/package name.
Bug: 216524590
Test: atest TetheringTest TetheringManagerTest
Change-Id: I962c7b4d8efc7f631077d6fa0f87f52ee779192e
Quang Anh Luongcommited 2024-12-18 13:53:04 +09:00
Follow-up from aosp/3383831, some arguments are still missing,
adding them and update tests accordingly.
Test: atest NetdStaticLibTests
Bug: 349487600
Change-Id: I495291f1e57c3a32c015fc7dfa3c2e6e86663da8
This is a no-op refactoring which:
1. Updates netd utility methods to handle custom netIds.
2. Rename internal methods to reflect the functionality.
3. Import constants from TetheringManager to improve
readability.
This refactoring is a prerequisite for future changes that will
utilize a new netId for routing instead of LOCAL_NETWORK_ID.
Test: atest NetdStaticLibTests TetheringTests CtsTetheringTest
Test: adb shell ip ru && adb shell ip ro show table local_network
Bug: 349487600
Change-Id: I1f3a68d24852b6bd85ce7be2ec58746e49b67636
This commit updates the logic for launching the entitlement UI
for tethering when there are multiple users. It disables the
check for whether the current user can change tethering settings
for secondary users due to a potential issue with calling
createContextAsUser. This reverts the behavior change introduced
in aosp/3289821.
One expected outcome is this change will break tethering with
entilement check enabled for HSUM-enabled devices. Since there
is no currently HSUM-enabled projects, disable this check is
safe.
Test: Manual
1. Mock requires entitlement
2. adb shell cmd user set-system-user-mode-emulation headless
3. enable hotspot
Test: atest TetheringTests:EntitlementManagerTest
Bug: 382624069
Change-Id: Ife3b721d1374602a8fa760954b372429cda1bf71
This commit ensures that EntitlementManager sends the appropriate
error code to the receiver when the current user is not allowed
to perform entitlement check. This error code also listened by
the tethering module, where it would stop tethering when receiving
such error code.
Test: atest TetheringTests:EntitlementManagerTest
Bug: 376792293
Change-Id: I2dd18f9df9ad7cab542f8877b9fc86600c248144
IpServer currently starts/stops tethering by specifying the tethering
type, but this will be a problem when we start to allow multiple
requests per type. To fix this, specify the TetheringRequest instead.
Note this CL has no functional changes.
Bug: 216524590
Test: atest TetheringTest TetheringManagerTest
Change-Id: I6bd9ceebcaa637a540435d5e91a35382f167a809
Quang Anh Luongcommited 2024-11-19 19:32:22 +09:00
Include SoftApConfiguration in TetheringEventCallback via
TetheringInterface, to allow apps to know which interfaces are created
with their SoftApConfigurations.
API-Coverage-Bug: 371133403
Bug: 216524590
Test: atest TetheringTest CtsTetheringTest
Change-Id: I1b4868ba8327bee3b03c0f21e5b4f0845f2f24a8
Quang Anh Luongcommited 2024-11-18 13:37:39 +09:00
Junyu Lai
commited 
Quang Anh Luong
commited 
Gerrit Code Review
commited 
Paul Hu
authored and
Patrick Rohr
authored and
Treehugger Robot
authored and
Lorenzo Colitti
commited 
Seungjae Yoo
authored and