This should be done once every time an interface comes online.
Doing this in updateLinkProperties guarantees this happens every
time a new interface comes online, but it doesn't do it more
often than needed.
Test: FrameworksNetTests NetworkStackTests
Change-Id: I0613c23f44192944266d76107308da8d1c541d1c
* changes:
[Tether10]Remove UserManagerInternal usage in Tethering
[Tether07] Migrate Tethering into module
[Tether07] Clean up build rule for libtetheroffloadjni
Apps that do their own DNS queries need to know the NAT64 prefix
to resolve v4 addresses on v6-only networks.
Test: FrameworksNetTests NetworkStackTests
Bug: 144877069
Change-Id: I5a255b7afc2038646b93a0ab893f8ad62d0fb34f
Now tethering would be run in dedicated service.
TetheringManager is the interface used to communicate with
TetheringService. The new call flow would be: ConnectivityManager
-> ConnectivityService -> TetheringManager -> TetheringService.
Note: the return value of #tether(), #untether() and #setUsbTethering()
APIs would always be no error. Client can use #getLastTetherError()
or #getTetheredIfaces or listen tether state change to check
status of corresponding interface.
Bug: 136040414
Bug: 144742179
Test: -build, flash, boot
-atest TetheringTests
-atest FrameworksNetTests
Change-Id: I7e78c0e0a3e70f940a749ba2a39ece7c7ec5b9b3
Merged-In: I7e78c0e0a3e70f940a749ba2a39ece7c7ec5b9b3
As opposed to other patches in this series, there is a logic change
here. This will send all necessary legacy broadcasts after all
matches have been done.
This should be fine because the callbacks and the broadcasts are
unordered anyway, and the broadcasts are still sent in the same
order as before ; there should not be an observable change from
apps besides some jitter.
Bug: 113554781
Test: ConnectivityServiceTest
Change-Id: Ibeab8d0a9106c5198228888ac33084238c0a4a1a
It's fine to do this out of the if() clause because :
• If the network newly satisfies a request it is sure to have
it in the list of requests it satisfies
• If it does not newly satisfy a request and there is still
a request with a legacy type that it satisfies, then it
is already remembered by LegacyTypeTracker
As for the VPN, the code always enters the condition anyway.
Test: ConnectivityServiceTest
Change-Id: I8bd668ad27043d6a5036b1b3c52fa5a3146abcfa
PermissionMonitor#hasUseBackgroundNetworksPermission only uses
the first package name of the uid for checking permission.
This is incorrect since each package declared different
permissions. So using the mApps which already checked both
network and using restricted network permissions. If uid is in
the mApps list that means uid has one of permission at least.
Bug: 135897744
Test: atest FrameworksNetTests
Change-Id: I3500a03ce06b5b822311ad0c67b606ce4039216a
NetworkNotificationManager will only get the first transport
type from the NetworkCapabilities of network, and if the device
connects to a VPN and its underlying network is wifi, then the
first finding transport type will be TRANSPORT_WIFI. So, if the
private DNS is broken when device connected to VPN,
NetworkNotificationManager will try to get the SSID for the
title of notification but failed. For this kind of case, the
title of PRIVATE_DNS_BROKEN notification will show
"null has no internet access".
Bug: 143340533
Test: 1. Build pass.
2. Connect to VPN and let private DNS to be broken, check
title of PRIVATE_DNS_BROKEN notification.
3. atest FrameworksNetTests
Change-Id: I1ed018cc8774d4fce4b94854f8e8703a28818463
