Bug: 137602441
Bug: 139783330
Test: atest FrameworksNetTests
Test: atest FrameworksWifiTests
Test: CtsVerifier - Wi-Fi Direct
Test: Enable hotspot when P2P GO is running
* P2P GO is terminated
* hotspot is running
Test: Enable P2P GO when hotspot is running
* hotspot is intact
* P2P GO could not be launched
Test: Verify P2P functions with legacy WifiP2pService
Change-Id: Icb2e2b106ae52b19af29b7a1ebc55d3cdf80db9c
The current test we have for a package changing TrafficController
permissions (i.e., INTERNET or UPDATE_DEVICE_STATS permissions)
is not realistic.
This is because the test simulates the update by removing and
adding the package. But TrafficController permissions are not
driven by broadcasts, they are driven by PackageListObserver,
and when an app is updated, PackageListObserver does not see a
remove and and add, but a single change event.
Add a new test for this.
Bug: 137864893
Test: new unit test added
Change-Id: I691b928f57c79c19dfb6ddb01983d55ef305c472
When turning on/off SoftAp with high frequency, sometime calling
WifiManager#updateInterfaceIpState with IFACE_IP_MODE_TETHERED
is performed after handling WIFI_AP_STATE_DISABLED event in
WifiServiceImpl while SoftAp is being terminated. This leads to
the issue that SoftAp is unable to start as startSoftAp always
returns "false". This is because mIfaceIpModes in WifiServiceImpl
keeps the mode WifiManager.IFACE_IP_MODE_TETHERED and the CL below
rejects SoftAp start request.
e257c5c9e79e3675375ca20731cfb74df02b1064 @ frameworks/opt/net/wifi
(WifiServiceImpl: Reject startSoftAp when already tethering)
This CL updates the interface ip state upon receiving ap disable
event from Tethering class to set proper state to mIfaceIpModes.
Bug: 134806980
Test: Ran script to turn on/off soft ap frequently
Signed-off-by: Daichi Ueura <daichi.ueura@sony.com>
Change-Id: I2f89214414d93f1aa942fb8a21264a9baae3452a
In case tethering donwstream is setup but don't ask EntitlementManager
to run provisioning. Cellular upstream should not be allowed if
EntilementManager don't have any donwstream record.
Bug: 134649258
Test: -build, flash, boot
-manual test with carrier SIM
Change-Id: I609722c79f0a45a1c2164d39721ef5883e436feb
Tethering may use wrong sub id for entitlement when data
subscription is changed from preferred data sub id to CBRS
sub id. Fix by using the active data sub id for tethering.
Bug: 134994718
Test: -build, flash, boot
-FrameworkNetTests
-manual test with carrier SIMs
Change-Id: Icb3f5eeb2319e50b2dc98369ad152988c934da57
Merged-In: Icb3f5eeb2319e50b2dc98369ad152988c934da57
Also a few utilities that were in the way, and some opportunistic
cleanups.
Test: FrameworksNetTest NetworkStackTest
Change-Id: I385070e2044fd967cb18f1ffea9a86a4627b742e
Split-tunnel VPN (which are the only ones affected by this change)
always fall through to the default network for routes they don't
handle, and even if the underlying network(s) don't provide access
this may be a pinhole that can actually reach the broader network.
In practice this behaves like the original release of P and is the
safest thing to do for Q. In R we should evaluate giving the VPN
app the ability to simply tell the network stack whether it does
provide Internet access or not.
Bug: 119216095
Test: FrameworksNetTests NetworkStackTests
Change-Id: I262ca41fe0225660551c9a421562405366b6acac
This is the most common test library for Connectivity tests. It is
meant to be usable in framework tests, network stack tests, CTS,
GTS. To achieve that, it can only depend on framework classes.
Bug: none
Test: NetworkMonitorTest
Test: NsdManagerTest
Test: ConnectivityServiceTest
Test: OffloadControllerTest
Test: NetworkStatsObserversTest
Test: NetworkStatsServiceTest
(all the touched classes)
Change-Id: Ic47cbe7ba0e407145fa6bc49bb2adb3c5937dbc4
Also :
- Fix testUidFilteringDuringVpnConnectDisconnectAndUidUpdates that
was failing on devices with a first released SDK >= Q
- Add a test actually tests that the system has the permission, as
the test was only testing what's in the mock
Bug: 119770201
Test: New test making sure this stays true
Change-Id: I74cf5f0fa17fcf818f1fed78c7e3e4375c20152e
Delete the unused NetworkManagementService API for set/remove
permissions. Use PERMISSION_NONE to replace NO_PERMISSIONS so the
framework now use the same set of permission constant when communicate
with netd.
Bug: 128944261
Test: PermissionMonitorTest.java
Change-Id: I25224c9576f52d2a0a0bd2182325c7aac7b28eb5
There is the potential bug[1] that default data subId change
intent may lose. So tethering may cache the outdated default
data subId in TetheringConfiguration. Now EntitlementManager
would fetch configuration every time and this would re-exam
whether subId is changed.
Additional passing subId to Settings to avoid default data
subId change right away when launching entitlement check.
Thus, Settings can know whether this is outdated entitlement
check request.
[1] b/129224596
Bug: 129751453
Test: -build, flash, boot
-atest FrameworksNetTests
-manual test with carrier SIM
Change-Id: If334dd1cd383cced9db5cf0d0bc9dc60ed198816
This reverts commit 3897df2e36.
Reason for revert: Rolling forward, will fix tests in same CL stack.
Bug: 114231106
Bug: 130397860
Test: FrameworksNetTests
Change-Id: Ia8a0c99b4e1fd5dff26c881715cd876618ca4321
This reverts commit fd8f96d719.
This change does not have any topic: not reverting the other 2 commits in the original topic.
Reason for revert: broke FrameworksNetTests presubmit: b/130397860
Change-Id: Iff41d9fe97fafea44680c8d67d1ce19277548cc0
When a fully-routed VPN is running, we want to prevent normal apps
under the VPN from receiving packets originating from any local non-VPN
interfaces. This is achieved by using eBPF to create a per-UID input
interface whitelist and populate the whitelist such that all
non-bypassable apps under a VPN can only receive packets from the VPN's
TUN interface (and loopback implicitly)
This is the framework part of the change that build the whitelist.
The whitelist needs to be updated in the following cases:
* When a VPN is connected and disconnected
This will cover the change to allowBypass bit, since that can't be
changed without reconnecting.
* When a VPN's NetworkCapabilites is changed (whitelist/blacklist app changes)
* When a new app is installed
* When an existing app is removed
* When a VPN becomes fully-routed or is no longer fully-routed
New user/profile creation will automatically result in a whitelist app change
transition so it doesn't need to be handled specially here.
Due to the limitation of the kernel IPSec interacting with eBPF (sk_buf->ifindex
does not point to the virtual tunnel interface for kernel IPSec), the whitelist
will only apply to app VPNs but not legacy VPN connections, to prevent breaking
connectivity with kernel IPSec entirely.
Test: atest PermissionMonitorTest
Test: atest android.net.RouteInfoTest
Test: atest com.android.server.ConnectivityServiceTest
Test: atest HostsideVpnTests
Bug: 114231106
Change-Id: I143b03d60e46cb1b04732b4a4034f5847b4d1b1a
The kernel eBPF maps have a blacklist to store all the uids that doesn't
have internet permission. When an app is unintalled from the device and
it is the last package on device that uses that uid, make sure we
cleaned the uid from the map and do not add no longer used uids into the
eBPF map. This action helps reduce the number of entries stored in the
map and reduce the chance of overflow the eBPF map.
Bug: 128944261
Test: PermissionMonitorTest
Change-Id: I10dd0113d00d6cf9ca39902d9721f2591d387d4a
Add more tests to PermissionMonitor to verify the functionality related
to INTERNET permission and UPDATE_DEVIE_STATS permission. Modified some
of the class design of PermissionMonitor so that it is easier to test
the new functionalities.
Bug: 111560570
Test: PermissionMonitorTest
Change-Id: Ic5585f337db5de48e2f87bf4f01ed7d85c349827
This is a alternative way for moving TetherService logic
into EntitlementManager[1]. Settings would close tethering
when silent entitlement check fail. To be consistent,
tethering should also be closed if UI entitlement check
fails.
[1] https://android-review.googlesource.com/c/platform/frameworks/base/+/928136
bug: 129330738
Test: -build, flash, boot,
-atest EntitlementManagerTest
-manual test with carrier SIM
Change-Id: Idfc35461b6359f3a624e78d49b6f73812db6d8ab
Instead of doing a tethering entitlement check whenever we turn
on tethering, provisioning result should only affect mobile
upstream. List behavior changes below:
1. Change tether entitlement check from pre-flight check to
run-time check.
2. Only run entitlement check when upstream is mobile.
3. Move schedule entitlement re-check logic from Settings to
framework.
4. Run all entitlement thing in TetherMaster thread to avoid
multi-thread problem.
Test: -atest FrameworksNetTests
-build, flash, booted
bug: 111490073
Change-Id: Ic2980b4d6864d6f7287816c43eb6cf7a5cdec541
Merged-in: Ic2980b4d6864d6f7287816c43eb6cf7a5cdec541
Tethering may receive default data subscription change when
carrier config don't load yet. Don't reevaluate provisioning
for this transient "carrier config not loaded" time. Assume
tethering will receive carrier config change and process
provisioning reevaluation after carrier config loaded.
Fix: 128650184
Test: -build, flash, boot
-atest FrameworksNetTests
-manual test with Google Fi
Change-Id: I9e66fe2cbc340ba7477283bea7853ff15f41dd81
1. Some API's argument/return value must be marked either
@NonNull or @Nullable.
2. Change some system APIs to public APIs.
3. Modify the method name
Bug: 126700123
Bug: 126702339
Bug: 126699682
Bug: 118296575
Bug: 126699216
Bug: 126699675
Bug: 126699429
Bug: 126699193
Bug: 123586045
Test: atest FrameworksNetTests
Change-Id: Iaa2832cdcf83758ed0fec81b954a0c63bc5a7bf6
This is a cherry-pick of ag/607226 that has been rebased on
top of four years of changes and with comments addressed.
Gives each factory a serial number and propagates it to every
NetworkAgent so when a score comes back indicating a request is
being handled the factory can account for it properly.
Without this, a new request that's already handled by a network
offered by a factory will not cause an increment of the factorys
ref count. Concretely this results in issues like the RAT icon
not being displayed in spite of the network actually being up
and usable.
This will be ported to AOSP as soon as possible, but immediately
some master-only WiFi tests need to be adjusted with this change
which would not let me submit to AOSP.
Bug: 18637384
Bug: 29030667
Test: manual
Test: atest frameworks/opt/telephony/tests/telephonytests
Test: atest frameworks-net
Test: atest CtsNetTestCases CtsHostsideNetworkTests
Change-Id: I597ac588f76dd507512ff02868fd1310b7e63f7e
Merged-In: I597ac588f76dd507512ff02868fd1310b7e63f7e
* changes:
Catch ServiceSpecificException instead of IllegalStateException.
Manage NAT64 prefix discovery lifecycle in the framework.
Track NAT64 in the framework and start clatd iff NAT64 detected
Change Nat464Xlat lifecycle.
Minor improvements to verifyTcpBufferSizeChange.
Currently NAT64 prefix discovery, which runs in netd, is started
by netd itself when a network is programmed with all-IPv6 DNS
servers. Unfortunately this is not correct because in many cases
we program DNS servers before the network is connected and it's
actually possible to send packets to them.
In general netd does not have enough visibility into network
lifecycle management to decide when to start and stop prefix
discovery. So move it into the framework with the rest of the
464xlat control plane.
Bug: 65674744
Test: atest FrameworksNetTests
Change-Id: I8fa051a9c216d9c05082bf7d0bbb0cbd56000162
Change isDunRequired variable from integer to boolean.
Before this change tethering would reference
config_tether_upstream_types reource configuraton to decide
isDunRequired for DUN_UNSPECIFIED case.
After the change, if isDunRequired is true, tethering would
request DUN. If it is false, tethering skip DUN type. In order
to backwards compatibility, tethering would not add mobile/hipri
type to upstream configuration if one of them already exist in
upstream configuration.
Test: - build, flash, booted
- runtest frameworks-net
- manully test with TMO, VZW SIM.
bug: 63150712
Change-Id: Ia998ea502674ff186d52af37e3fd8f07de495245
Currently, both netd and clatd do NAT64 prefix detection, and we
start clatd on all IPv6-only networks regardless of whether netd
has detected a NAT64 prefix or not.
Instead, track the NAT64 prefix in the framework, and only start
clatd if the prefix is detected. This will allow us to remove
DNS64 detection in clatd, and pass the NAT64 prefix and the IPv6
address to clatd on the command line instead of clatd finding it
itself. That way, netd and the framework will always know how
464xlat is configured, and we'll be able to use that information
in netd.
Test: builds, boots
Test: atest FrameworksNetTests
Change-Id: Ida32d5760c5aecf7aeebef08fdb596291b2ce14a
Currently, NetworkAgentInfo keeps a Nat464Xlat object only on
networks where we're starting clatd (i.e., IPv6-only networks).
Simplify this code by making the Nat464Xlat object final and
always non-null. This allows us to use Nat464Xlat to store
information, such as the NAT64 prefix, even if the clat daemon
has not been started yet.
Also, remove the STOPPING state which waits for the interface to
be removed. Instead, when stop() is called, immediately enter the
IDLE state.
- This is necessary in order to be able to call start() again
before the interface removal notification has arrived.
- It's also arguably more correct than the current code,
because when stop() returns clatd has already terminated
(ClatdController::stopClatd calls waitpid), and thus the tun
fd is already closed and the tun interface is gone.
Also, now that Nat464Xlat objects are reused after stop(), add
test coverage for calling start() after stop, in both cases:
- The notification that the previous interface was removed
arrives before the second start().
- The notification that the previous interface was removed
arrives after the second start() but before the notification
that the second interface was added.
Also fix a couple of lint warnings.
Test: builds, boots
Test: atest FrameworksNetTests
Test: clatd stops when IPv4 address added
Test: clatd restarts after "adb shell killall clatd"
Change-Id: I3dc66d155aa27606681f3473daf2170434d8c6d0
Bug: 122652441
Test: atest com.android.server.connectivity.VpnTest
Test: Establish a IPv4 VPN with minimal routes and check
(dumpsys connectivity) the VPN network does not have INTERNET
capability.
Change-Id: Ic7f19ebb7b7f78a6ffb2a8ec3fc3eca5e5421f57
NetworkStack is only used in services.net or clients of services.net. It
cannot stay in framework.jar because it needs to depend on AIDL
interfaces, which would conflict with app implementations if they were
in framework.jar.
Test: atest FrameworksNetTests NetworkStackTests
Bug: 124033493
Change-Id: Ib1d08a3669983640119d008db7e2990fa798724f
Merged-In: I501b125a388c1100c2182bde4670944c2f0d7a02
Previously, they were only updated when underlying network set was
non-null.
This change also ensures that all the calls b/w ConnectivityService and
Vpn that leads to updating capabilities are on ConnectivityService
handler thread.
Additionally, it also ensures that capabilities are propagated after VPN
enters connected state. This was previously done from establish which
could potentially lead to race between VPN getting connected and
capabilities getting updated.
This change also updates VPN capabilities inline from
ConnectivityService handler thread. Previously, there was an additional
loop where Vpn would update capabilities via NetworkAgent thru
AsyncChannel which posts back to CS handler thread, which could
potentially lead to delays in updating VPN capabilities.
Bug: 119129310
Bug: 118856062
Bug: 124268198
Test: atest FrameworksNetTests
Test: manual - verified VPNs capabilities are getting updated and
DownloadManager is working correctly.
Change-Id: Id0abc4d304bb096e92479a118168690ccce634ed
The callback would be used to notify entitlement value. If the
cache value indicates entitlement succeeded, it just fire
callback with cache value instead of run entitlement check.
Bug: 120887283
Test: atest FrameworksNetTests
Change-Id: I8afe928423bd75c54c61533a50a5c0814922ceb1
For VPN apps targeting Q and above, they will by default be treated as
metered unless they override this setting before establishing VPN.
Bug: 120145746
Test: atest FrameworksNetTests
Test: On device tests verifying meteredness setup correctly for apps
targeting Q and apps targeting P.
Change-Id: Ia6d1f7ef244bc04ae2e28faa59625302b5994875
