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
Refactor tether state change callback/broadcast to allow for redactions
based on the callback cookie of the recipient. This CL is a no-op and
will be used in a future CL to redact the SoftApConfiguration in
TetheringInterface.
Bug: 216524590
Test: atest TetheringTest CtsTetheringTests
Change-Id: I3684929e6ba832f4da353d48137967739ca558d6
Quang Anh Luongauthored and Quang Luongcommited 2024-11-08 05:08:43 +00:00
Change the permission check for tethering to checkPackage. This avoids
having to create context as another user which is not supported when
running the networkstack from secondary user.
Bug: 375535923
Bug: 216524590
Test: atest TetheringManagerTest TetheringServiceTest
Change-Id: Ibc3abe9ec2eab5ec976c6a9cbc08e1552203ee5d
Oscar Shuauthored and Quang Luongcommited 2024-11-08 02:31:46 +00:00
Add a uid and package name to TetheringRequest to keep track of which
app the request belongs to, and also convey this information to Wifi
for later use with resource conflicts.
Bug: 216524590
Test: atest TetheringManagerTest TetheringServiceTest
Change-Id: If963694cb1bbd831ba379a76043825c94ef9d67a
Quang Anh Luongcommited 2024-10-23 15:52:03 +09:00
This is a no-op refactoring which only introduce
dependencies object injection to replace the wrapper class.
Test: atest TetheringTests:EntitlementManagerTest
Fix: 363972541
Change-Id: I24b0bf5f8951c453af1e9ae9278285d1a7b86849
This change addresses the launch of entitlement UI activities
in Headless System User Mode (HSUM) on multi-user devices.
HSUM is a configuration where the system user (user 0) does
not represent a human user and primarily runs system services.
In this mode, the first user set up on the device is not user 0.
Modified the EntitlementManager logic to handle the
launch of the entitlement UI in multi-user environments,
specifically addressing scenarios where HSUM is enabled, which
includes:
1. Always launch the UI to the foreground current user.
2. Check whether the current user is allowed to show the UI.
This ensures the UI is presented to the appropriate user.
Test: Manual
1. Mock requires entitlement
2. adb shell cmd user set-system-user-mode-emulation headless
3. enable hotspot
Test: atest TetheringTests:EntitlementManagerTest
Fix: 363972541
Change-Id: I950d678741a3f1714f347206fa161bcd7538b402
This CL splits requestDownstreamAddress into two methods: requestStickyDownstreamAddress and requestDownstreamAddress.
- The requestStickyDownstreamAddress is equivalent to the former requestDownstreamAddress when useLastAddress=true.
- The new requestDownstreamAddress method allows allocating an address without providing the interface type and scope, which is Thread NAT64's use case.
Bug: 369282577
Change-Id: Ib839d121c7b46c492f2c4c1c61b52b5d017fa055
Quang Anh Luong
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Lorenzo Colitti
commited 
Junyu Lai
commited 
Seungjae Yoo
authored and
Oscar Shu
authored and
Patrick Rohr
authored and
Handa Wang
authored and