In some networks, network validation may only get success
result for http probe but fail result for https probe.
For this kind of network, it may still work at some websites
or apps, but user didn't know about that. In order to fix this
issue, we will check if network has partial connectivity and
notify user to make a choice if they want to use this partial
connectivity or not.
Bug: 113450764
Test: 1. Build pass.
2. Fake partial connectivity case for testing.
3. atest FrameworksNetTests
4. atest NetworkStackTests
Change-Id: I69ed00ac4850904ff708c9fef22e148879a10e92
Add a mechanism by which a factory can declare "instant failure" for
a request - which would result in it getting an OnUnavailable()
(even without a timeout).
Factories may only do this iff:
1. They know they are the only factory which may fulfill this
request (common for transport-specific requests).
2. The know that the request can definitely not be
fulfilled at any point in the future.
Bug: 31382922
Test: atest ConnectivityServiceTest
Merged-In: I9bce0f4d85fa8cad7f8a9998819f945b778c5ac5
Change-Id: I9bce0f4d85fa8cad7f8a9998819f945b778c5ac5
NSS needed it for getting VpnInfo[], NetworkState[] and
activeLinkProperties which it used to query via ConnectivityManager.
For VpnInfo[], this was racy as NSS may ignore intermediate changes to a
VPN's underlying networks. See http://b/123961098 for more context.
It may also lead to deadlocks b/w ConnectivityService and
NetworkStatsService. See http://b/126245192 for more info.
This change will ensure that NSS is never contending on any of
ConnectivityService locks.
Bug: 123961098
Bug: 126245192
Bug: 120145746
Test: atest FrameworksNetTests
Change-Id: Id1da446b54d95ee68ed14079107b1a10318bcf8b
Merged-In: I57e117bb4e9efe491b19d6b5a479f2d58d1c58e6
NSS needed it for getting VpnInfo[], NetworkState[] and
activeLinkProperties which it used to query via ConnectivityManager.
For VpnInfo[], this was racy as NSS may ignore intermediate changes to a
VPN's underlying networks. See http://b/123961098 for more context.
It may also lead to deadlocks b/w ConnectivityService and
NetworkStatsService. See http://b/126245192 for more info.
This change will ensure that NSS is never contending on any of
ConnectivityService locks.
Bug: 123961098
Bug: 126245192
Bug: 120145746
Test: atest FrameworksNetTests
Change-Id: I57e117bb4e9efe491b19d6b5a479f2d58d1c58e6
This change is basically a revert of http://ag/3580901.
It was made because previously VPN capabilities did not use to update
based on its underlying networks. That is no longer the case anymore.
This was previously returning meteredness on the basis of VPN's first
underlying network which is incorrect in cases such as VPN using
multiple underlying networks, or VPN that has explicitly marked itself
as metered via VpnService.Builder#setMetered API.
Bug: 123936838
Test: atest FrameworksNetTests
Change-Id: Ia54b8570fbad4a638a6d43a95e0271c6baf66685
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
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
1. Remove "throws Exception" from the signature so it can be used
in tests that do not already throw Exception.
2. Update comment to reflect the fact that TCP buffer sizes are
set on default network switch, not on connect.
3. Move into the method a class-level static constant that is
only used in that method.
Test: atest ConnectivityServiceTest
Change-Id: Ic2e4fbedc23065efc20e45ea84996b577a8e94b6
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
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.
(cherry-pick of aosp/905233 with trivial conflicts in SystemServer.java)
Test: atest FrameworksNetTests NetworkStackTests
Bug: 124033493
Change-Id: I501b125a388c1100c2182bde4670944c2f0d7a02
The test did not wait for the WifiNetworkAgent to disconnect, and there
are reports of flakes where it is still connected in
connectKeepaliveNetwork.
Test: atest FrameworksNetTests
Bug: 124319553
Change-Id: I85968806885c8853ec4f4dbea356366c1af0ea1c
Add a mechanism by which a factory can declare "instant failure" for
a request - which would result in it getting an OnUnavailable()
(even without a timeout).
Factories may only do this iff:
1. They know they are the only factory which may fulfill this
request (common for transport-specific requests).
2. The know that the request can definitely not be
fulfilled at any point in the future.
Bug: 31382922
Test: atest ConnectivityServiceTest
Change-Id: I9bce0f4d85fa8cad7f8a9998819f945b778c5ac5
Have the network stack pass its package name in
showProvisioningNotification instead.
Bug: 124033493
Test: flashed, WiFi and captive portal works
Test: atest FrameworksNetTests NetworkStackTests
Change-Id: I1f3312768ba1fb34e99a827e1fcdaf7510e318a8
In previous change, the new SocketKeepalive API was exported.
But internally, old PacketKeepalive names and structures are
still used.
This change rename them properly for code consistency and also
refactor KeepalivePacketData to support different types of
KeepalivePacketData.
Bug: 114151147
Test: 1. atest FrameworksNetTests
2. atest FrameworksWifiTests
3. atest FrameworksTelephonyTests
Change-Id: Ia9917d12987e91e87e34ffb3f126e7bc7c9c187e
Merged-In: Ia9917d12987e91e87e34ffb3f126e7bc7c9c187e
In previous change, the new SocketKeepalive API was exported.
But internally, old PacketKeepalive names and structures are
still used.
This change rename them properly for code consistency and also
refactor KeepalivePacketData to support different types of
KeepalivePacketData.
(clean cherry-pick from aosp/860394)
Bug: 114151147
Test: 1. atest FrameworksNetTests
2. atest FrameworksWifiTests
3. atest FrameworksTelephonyTests
Change-Id: Ia9917d12987e91e87e34ffb3f126e7bc7c9c187e
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
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 propogates 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
Includes various small changes to stop using hidden APIs
Test: make NetworkStack
Test: flashed, booted, WiFi and tethering working
Bug: 112869080
Change-Id: Id2830795a444f484b377ed6437435a1cd833697a
Adds system api of createSocketKeepalive to take file descriptor,
so privileged apps could use it without the need of IpSecService.
Bug: 114151147
Test: atest FrameworksNetTests
Change-Id: If926c21704b6ed73a0adfcadad732b97b42bacae
The new set of API replace the PacketKeepalive system API
which is only specific for IPsec NAT-T keepalive packet. Allows
applications to request different types of keepalives through
the same set of API.
By using keepalives, applications could request system to
periodically send specific packets on their behalf, using
hardware offload to save battery power.
This change would only address interface change and test part of
original functionality. After all reference of PacketKeepalive
are removed, another change would be submitted to remove old
API.
Bug: 114151147
Test: atest FrameworksNetTests
Change-Id: I3367666810acc44d5ad20e19acd4bf936e8b5d9c
This avoids the need to expose ConnectivityService implementation
details as @SystemApi and the complexities that would be required
to make NetworkCapabilities parcelable in stable AIDL.
Bug: 112869080
Test: atest FrameworksNetTests NetworkStackTests
Change-Id: Icd5d25b9b8e9b7a7d1899b000c92dc4976c3b3d7
Currently testStackedLinkProperties accounts for some of the
NetworkCallbacks that are fired, but not all of them. The test
passes because it only ever expects LinkProperties changed
callbacks (and not, e.g., lost callbacks), because it uses
waitForIdle(), and because at the end, when the callback is
unregistered, it does not call assertNoCallback().
Add the missing callback expectation and expect a LOST callback
at the end. Also add an assertNoCallback, even though it's not
strictly necessary. Remove all the waitForIdle statements, which
are no longer necessary because every assertion happens after
waiting for a callback.
Making the expectations more precise in a separate CL will help
ensure that upcoming changes to this code don't break anything,
and will make said changes easier to review.
Bug: 65674744
Test: atest FrameworksNetTests
Test: ConnectivityServiceTest#testStackedLinkProperties passes 400 times
Change-Id: I73cda0dd029a0e6546f7272beedf841ce5a4c0dc
