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
failureEnablingIpForwarding verifies that TetheringMetrics sends one
more error report than it should. This extra verification is caused by
any(class) being passed into the mock WifiManager.startTetheredHotspot,
which does not match null even though the actual code passes in a
null. This results in an extra failure that causes the extra error
report call.
Fix this by replacing any(class) with null, and removing the extra error
verification.
Bug: 216524590
Test: atest TetheringTest
Change-Id: I93986a999d573a186696e54793563e2be8405f39
Quang Anh Luongcommited 2025-03-15 10:42:22 +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
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
Mockito extended tends to cause all kinds of issues due to the way it
injects itself into the bytecode of framework classes instead of
creating subclasses.
Use non-extended mockito as it is not actually necessary for current
tests.
Test: atest
Change-Id: Id2874309cce2778c4405b852df9a3ae816c4abcb
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
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
Add a test that verifies that legacyTether will not use the
explicit pending TetheringRequest set by startTethering.
Bug: 216524590
Test: atest TetheringTest
Change-Id: I3e0638a3c60cdf3b73b1accc136ed7098e7b48f6
Quang Anh Luongcommited 2025-03-04 16:58:40 +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
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
Tethering will ignore interfaceStatusChanged for enabled interfaces
starting in B, instead only creating the IpServer when the link layer
event comes. Fix the assertions around interfaceStatusChanged for B.
Bug: 393978354
Test: atest TetheringTest
Change-Id: I74d0843785c5d9353e59b73d6d7b30d6d07ac0e0
Quang Anh Luongcommited 2025-02-05 10:43:59 +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
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
The intention of this test case is to check that the cached hotspot prefix doesn't get assigned to ethernet, even if released, so that it can be offered to the hotspot if requested again.
Therefore we should call `requestStickyDownstreamAddress` instead of `requestDownstreamAddress` when requesting the prefix for hotspot.
Bug: 375858174
Test: atest TetheringTests:com.android.networkstack.tethering.PrivateAddressCoordinatorTest#testReservedPrefix --iteration 200
Change-Id: I5d897aa958a9549f3d773bd59920906a815edb5e
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
The hotspotPrefix was previously released on line 192, so when a new
prefix was allocated on line 206, it was allowed to "conflict" with the
now-released hotspotPrefix.
This change moves the call to releaseDownstream() to the end, so the
test can properly check for conflicts.
Test: TH
Bug: 375858174
Change-Id: Iac786237340fc14098701d86fa80946a7fb8e0b6
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
This is a test only refactoring which updates the unit tests to use a
TestableResultReceiver to have better readability, and asserting
no entitlement result received.
Test: atest TetheringTests:EntitlementManagerTest
Bug: 376792293
Change-Id: I5cc02c8ab85ae614e714055c7f8f4c076341f48f
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
Quang Anh Luong
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Priyanka Advani (xWF)
authored and
Paul Hu
commited 
Remi NGUYEN VAN
authored and
Maciej Żenczykowski
commited 
Junyu Lai
commited 
Lorenzo Colitti
commited 
Handa Wang
commited 
Patrick Rohr
commited 
Seungjae Yoo
authored and