network.
This is to establish a baseline for the existing behavior, and to ensure
that following changes are not causing a regression in existing
behavior.
This CL is also adding missing cleanup for NetworkStatsCollectionTest
which was forcing all network types in NetworkTemplate that was causing
NetworkStatsService related tests to fail.
Bug: 113122541
Bug: 120145746
Test: atest FrameworksNetTests
Change-Id: I285f186cfb16bc9fa704c797996b1e4f8a73dee4
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
In PT17, for security of the patch these two constants have been
switched from boolean to enum values. While this is nice for making
sure a patch is correct, it's also pretty wasteful. Now that it's
certain that the values of these fields don't matter, they can be
set to logical values (as opposed to reversed as it was the case
before PT17.
Test: runtest
Change-Id: I93a0780e23c2f658687be066dc16f27529baaa86
See build/soong/README.md for more information.
Note: tests/ImfTest/Android.mk causes conflict as it hasn't been yet
ported to internal master. Do it later.
Note: the conversion in the following directories has to be done in the
internal master first because of the conflicts:
* tests/ActivityManagerPerfTests
* tests/AppLaunch
* tests/AppLaunchWear
* tests/BackgroundDexOptServiceIntegrationTests
* tests/Camera2Tests/CameraToo
* tests/Camera2Tests/SmartCamera/SimpleCamera
* tests/Compatibility
* tests/Internal
* tests/RcsTests
* tests/ServiceCrashTest
* tests/UsbTests
Bug: 122332340
Test: treehugger
Change-Id: Ie17590c6a96aee5caa80d38092a3de5c1b6efe8d
1. refine the naming in DnsPacket and add more comment
2. add comment in DnsResolver
Test: built, flashed, booted
atest DnsResolverTest DnsPacketTest
Change-Id: Ib482d079d6823fd1d9bff163427b7aad38374199
This change adds the relevant JNI implementations, as well as the
implementations and NetworkAgent tracking code in the TestNetworkService.
TestNetworkService (And Manager) is designed for use exclusively in
testing code, allowing for the creation of TUN and IPsec backed networks
in test code. Specifically, this allows for testing of components such
as IP, DHCP, or DNS clients, as well as kernel features such as IPsec.
Access to the TestNetworkService will be conditioned upon the
MANAGE_TEST_NETWORKS permission that will be granted only to the Shell.
CTS will use UiAutomation.adoptShellPermissionIdentity() to gain the
ability to use this service.
Bug: 72950854
Test: CTS tests passing
Change-Id: Ie66ba631a548b5f9c6b5ed0797582f86688debe5
To address the API review feedback provided by
the API council.
Bug: 126702995
Bug: 126701710
Bug: 126702357
Bug: 126701113
Bug: 126701239
Bug: 126700713
Bug: 126700064
Test: Manual
Change-Id: I4b902c1fc2c09133022b05dacdda8964436205d2
Add @NonNull annotations as required by the automated review.
Bug: 126702338
Test: make checkbuild
Change-Id: I9057f06de8d7ea846af00d5cefa744d4206b4b63
This adds the scaffolding for TestNetworkManager and TestNetworkService.
These are separate from the ConnectivityManager/ConnectivityService in
order to prevent polluting the API space, and making them harder to
maintain.
Bug: 72950854
Test: Compiles, CTS tests relying on this pass
Change-Id: Ic42c09a33d962471e2587ec27f3fab2d72bbcd42
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
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
For packages:
android.net
android.net.wifi
android.nfc
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Merged-In: I7489aad1dceeb18ed7ca48a1ed8829a668b3fa04
Change-Id: I16570aef456b45a5543bf889dddc7a0d25441928
* 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.
In its own change for ease of rollbacks due to the risk of
possibly crashing existing codepaths.
Bug: 65674744
Test: atest FrameworksNetTests
Test: builds, boots. Wifi, cell data, private DNS work
Change-Id: I2c0acc1c7b8367803f17b4a12c1df0fdfbc29691
The old NetworkManagementService methods to start clatd threw
IllegalStateException, but the new netd methods throw
ServiceSpecificException. Update the catch clauses so that if
starting clatd fails, the system doesn't crash.
Also stop logging stack traces but only include the exception
message itself.
Bug: 65674744
Test: atest FrameworksNetTests
Test: connecting/disconnecting to v6-only wifi in a loop does not crash
Change-Id: I4a9ec7f104712fbbe08f4f67e3288df03e8ed873
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
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
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
In order to support tcp keepalive offload, some socket
options are necessary. If one of them isn't supported in
kernel, just return ERROR_HARDWARE_UNSUPPORTED to the
caller.
e.g.
TCP_REPAIR starts from kernel 3.5
TCP_REPAIR_QUEUE starts from kernel 3.5
TCP_QUEUE_SEQ starts from kernel 3.5
TCP_REPAIR_WINDOW starts from kernel version 4.8
Bug: 124453402
Test: -boot, flash, atest FrameworksNetTests
-start tcp keepalive offload in kernel 4.4 and 4.9 device.
Change-Id: I6f87e5be2f2ca7aae1293820c164d0bc7b664eb6
The current logging relies on the system log that may rotate. This is a
problem to investigate bugs where the network stack service is not
started. Add a SharedLog to NetworkStackClient and dump it in
ConnectivityService (for lack of a better place to dump it).
Bug: 124307802
Test: Booted, dumpsys connectivity shows the log
Change-Id: If596451d0613645f68a8a32acb032eea76ea506c
Netd need the list of apps that have permission INTERNET or permission
UPDATE_DEVICE_STATS at run time to make decisions about application
request. To avoid protential deadlock and reduce the traffic between
netd and system server, Use packageManagerServcie to send the list of
apps that have those permissions to netd when device boot and when new
apps get installed.
Bug: 111560570
Bug: 111560739
Test: install and uninstall packages and dumpsys netd trafficcontroller
Change-Id: Idb9905f424557a5c59e35d41f5eafe345aca87e0
