This is supported by:
1. Utilize the new API from both NetworkStatsProvider
and IOffloadControl to send data warning quota to hardware.
And pass the warning reached notification back to NPMS.
2. Disable software solution introduced in R release for
V1.1+ hardware, since now we can fully offload data warning
and limit notification to hardware.
Test: atest TetheringTests
Fix: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: Ie49461694d77ab7f25a549433b01b5b0167bd489
This is a no-op change that just adapt new API from
NetworkStatsProvider to get warning and limit bytes at the same
time. This change also stores them locally for subsequent
patches to set warning bytes to hardware.
Test: Will be included in the subsequent patch.
Bug: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: Iec01cb01fd1ce481ce0bd736762baddde1e38084
This is a no-op change that redirect both V1.0 and V1.1 callback
events to the same handling function. Since the V1.1 callback
is extended from V1.0 callback, we can safely use V1.1
callback for both V1.0 and V1.1 control.
The change also provides interface for subsequent
OffloadController changes to set warning and limit at the
same time.
Test: atest TetheringTests
Bug: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: I6505a04de8c57357dd1fa9ce898c13395e497816
While the actual part that track default request is inside
UpstreamNetworkMonitor, instead of passing it from Tethering,
move it into counter-part CL and use it from
UpstreamNetworkMonitor.
Since the current code is replaced by registerSystemDefaultCallback
in Android S, implement it inside the api30 shim implementation
to provide an unified interface to tethering.
Test: atest TetheringCoverageTests
Bug: 185952829
Change-Id: Iaf21b6b662aa6aba79c2b75379128b8523f81f02
This is no longer necessary as all the methods that take it are
running on on the handler thread, either in Tethering itself or
on the state machine thread in IpServer, which runs on the same
thread as Tethering.
Specifically:
- interfaceStatusChanged, interfaceAdded, interfaceRemoved,
interfaceLinkStateChanged: run from mNetdCallback, which always
posts them to mHandler.
- setWifiTethering: only called by enableTetheringInternal, which
is called by the following:
- startTethering, stopTethering: via lambda posted to mHandler
- IpServerCallback#requestEnableTethering: called by IpServer
while processing a command.
- setEthernetTethering: only called by enableTetheringInternal.
- EthernetCallback: runs on mExecutor, which posts to mHandler.
- getLastTetherError: only used by the test. Renamed to
getLastErrorForTest to ensure no other callers.
- sendTetherStateChangedBroadcast: called only by
notifyInterfaceStateChange, which is called only by
- IpServerCallback#updateInterfaceState, which is called only
by sendInterfaceState, which is called by various IpServer
state enter methods.
- notifyLinkPropertiesChanged: called only by
IpServerCallback#updateLinkProperties, which is only called by
IpServer#sendLinkProperties, which is only called by:
- Code that processes CMD_IPV6_TETHER_UPDATE
- IpServer#handleNewPrefixRequest: only called when processing
CMD_NEW_PREFIX_REQUEST.
- IpServer#sendInterfaceState (see above)
- handleWifiApAction, handleWifiP2pAction: only called by
mStateReceiver, which runs on the handler thread
- tether(String, int): called by:
- tether(String, IIntResultListener): posted to mHandler
- changeInterfaceState: called by:
- EthernetCallback (see above)
- enableWifiIpServingLocked: called by handleWifiApAction and
handleWifiP2pAction (see above)
- tetherMatchingInterfaces: only called by handleUsbAction,
which is run from mStateReceiver on the handler thread.
- untether(String): called by:
- untether(String, IIntResultListener): posted to mHandler
- changeInterfaceState (see above)
- setUsbTethering: called by:
- setUsbTethering(boolean, IIntResultListener): posted to mHandler
- enableTetheringInternal (see above)
- setNcmTethering: called by enableTetheringInternal (see above)
- getTetheredIfaces: called only by TetheringTest. Renamed to
getTetheredIfacesForTest to ensure no other callers.
- getErroredIfaces: unused, deleted in this CL
- getTetheredIfaces: called by:
- isTetheringActive: called by onUserRestrictionsChanged, which
is only called by mStateReceiver
- TetheringTest
- dump(): changed to run on handler thread
- upstreamWanted: called by
- TetherModeAliveState#enter
- TetherModeAliveState#updateUpstreamWanted, which is called
only by TetherModeAliveState#processMessage.
Test: atest TetheringCoverageTests
Test: enabled/disabled hotspot, USB tethering
Change-Id: Id49d33f027b8df4c97fda480ff239c0ba90bb96a
This is in preparation for removing mPublicSync.
Test: m
Test: adb shell dumpsys tethering
Test: atest TetheringTests TetheringIntegrationTests
Change-Id: Ib2c9d0bff23614f76c8e075d32cb03412d3d21f7
Some OEM may have special mobile data icon show up when non-default
(e.g. DUN) mobile connection connected even wifi is also connected.
So always connected DUN may let user hard to distinguish tethering
upstream in those OEM's devices. Also release unused mobile connection
may safe power.
This CL removes unnecessary code from selectPreferredUpstreamType.
In particular:
- When a DUN or HIPRI upstream is selected, calling
registerMobileNetworkRequest is unnecessary. A mobile
NetworkRequest is always registered unless a non-mobile upstream
is selected.
- When a non-mobile upstream is found, releasing the mobile
NetworkRequest is unnecessary in selectPreferredUpstreamType
because it will be done by chooseUpstreamType immediately after
selectPreferredUpstreamType returns.
- When no upstream is found and cellular upstream is not permitted,
it is not necessary to release the mobile NetworkRequest. When
cellular is not permitted, no such NetworkRequest will be filed
because registerMobileNetworkRequest checks with EntitlementManager
before actually requesting the network. If cellular becomes the
upstream and then later becomes not permitted because of an
entitlement failure, all tethering will be stopped by Settings.
Note: currently legacy upstream selection has two known bugs:
1. If mobile has higher priority than non-mobile network, mobile request
should never be released and always prefer use mobile. But in practice,
mobile request would be released when tethering select non-mobile network
as upstream.
2. If mobile has higher priority than wifi network and default network
is wifi but mobile is still connected, tethering would choose mobile as
upstream because it has higher priority. Mobile disconnecting may not
trigger tethering to switch its upstream to wifi because currnetly
tethering rely on CONNECTIVITY_ACTION broadcast to handle upstream
disconnect.
Bug: 173068192
Test: atest TetheringTests
Change-Id: Id5df58af830cc534ecd79041ddf8a04171047e9b
This is a no-op change that try to use 1.1 HAL if available.
Otherwise, fallback to 1.0 HAL. The change also provides version
information for subsequent patches to determine what to do for
specific version.
Test: atest TetheringTests
Bug: 149467454
Ignore-AOSP-First: avoid long automerger delay
Change-Id: I6a3ce877cdff2496087b97b191a9bfd5b0792827
This is useful for OEMs that want to use RNDIS or NCM as a
local-only link that is directly connected to some other host.
This can be used to implement USB tethering using NCM, which
currently only supports local-only mode.
Bug: 175090447
Test: TetheringIntegrationTests:EthernetTetheringTest#testLocalOnlyTethering
Change-Id: I0ffaa46e4640e5b235340a15d25909106ceb0c07
When a 464xlat upstream disconnects, onLinkPropertiesChanged is
called after onLost. This breaks an UpstreamNetworkMonitor
assumption that no callback will ever arrive after onLost.
Bug: 173068192
Fix: 185117377
Test: new unit test
Change-Id: I4ff1eca6d5ed1680ff716c71b683891c8a0e5a77
Current upstream selection code suffers from a race where if the
CONNECTIVITY_ACTION broadcast for a given network switch is
received and processed before the NetworkCallbacks for that
network switch, upstream selection just re-selects the same
upstream it had before. The incorrect upstream persists until
another CONNECTIVITY_ACTION is received.
Fix this by defining a new EVENT_DEFAULT_SWITCHED message code
communicated from UpstreamNetworkMonitor to Tethering, and send
that whenever the default network switches.
The message is sent in onLinkPropertiesChanged, because the
tethering code stores all information about networks in an
UpstreamNetworkState structure that contains Network,
LinkProperties and NetworkCapabilities. When a network switch
occurs, onLinkPropertiesChanged always follows onAvailable and
onCapabilitiesChanged, and thus marks the first point in time
when all the information is available.
This CL tries not to change existing codepaths too much, but
it does move the update of mDefaultInternetNetwork from
onCapabilitiesChanged to onLinkPropertiesChanged. This should
not be a problem because the only thing that reads
mDefaultInternetNetwork is getCurrentPreferredUpstream, which,
in the case of a default network switch, will be run by the
onLinkPropertiesChanged which will immediately follow.
Bug: 173068192
Test: changes to existing unit tests show bug is fixed
Change-Id: Ic9196bc92892811b25bda463ffd839ee5c19d294
