See packages/modules/Connectivity/framework/src/android/net/NetworkUtils.java,
11 are 'static native' and 1 is 'native static'
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic6392452ce6f760db0f4300e0a35a33b9487c931
Add a warning to unregisterNetworkOffer to inform users that this method
executes asynchronously.
Test: documentation only change
Change-Id: Ic4742bf570ebcd4d00b0b259c35fd46688494517
DscpPolicyTest does not have an IpClient, so it relies on assigning the
LinkAddresses at interface creation. If DAD is enabled, the global
address cannot be used immediately, so the test packet selects the wrong
source address. There is no obvious way to fix this without disabling
DAD as the TestableNetworkCallback receives the LinkProperties update
before the address can be used.
This functionality will also be useful in ethernet tests, which
currently have to block for a long time.
Test: atest DscpPolicyTest
Bug: 235559605
Change-Id: Id7788df5e92ebd8eaf4619a23f44135ea4a2144e
(This rolls forward part of a previous change, now that jarjar was fixed
to not get very slow when the number of rules increases).
Autogenerate connectivity jarjar rules at build time, to avoid issues
with forgotten jarjar rules or hard-to-diagnose errors introduced by
incorrect rules.
This change causes all classes in framework-connectivity(-t) and
service-connectivity to be jarjared into android.net.connectivity, but
still avoids jarjaring classes in com.android.server as before, to keep
it small.
For many classes this differs from the original jarjar rule.
Notes on implementation:
- connectivity-jarjar-rules now has a subset
framework-connectivity-jarjar-rules containing only the rules
necessary for framework-connectivity. This is necessary because
framework-connectivity cannot depend on rules generated based on
service-connectivity, as there would be a dependency cycle
(service-connectivity depends on framework-connectivity); Soong even
crashes with a stack overflow.
- framework-wifi.stubs.module_lib is added to
framework-connectivity-pre-jarjar as it is necessary to build it (it
is already in impl_only_libs in the defaults).
It is unclear why framework-connectivity-pre-jarjar could build
before that (possibly because it was only used as "lib" ?)
- Fix package-private visibility; for example NattSocketKeepalive,
TcpSocketKeepalive are not API so should be jarjared, but are used
by ConnectivityManager which is not jarjared, so they are not in the
same package after the change. Package-private members in the
former 2 need to be public to be accessible. Changes in this commit
are all that is needed, as demonstrated by followup commits that move
the classes to a different package without further changes, and that
enforce that no class in an API package gets jarjared.
- framework-connectivity-internal-test-defaults is separated from
framework-connectivity-test-defaults, for unit tests that need to
access internal jarjared classes. Such tests need to use the jarjar
rules themselves too, so this is only appropriate for connectivity
internal unit tests.
Test: atest ConnectivityCoverageTests CtsNetTestCases
Bug: 217129444
Change-Id: Ib1bd939b71c0171d945fc01b96195d2f620ff13b
Revert the previous change to filter out all non-RTN_THROW routes when
EXCLUDED_ROUTES is disabled, as that behavior is CTS tested for T, and
has been used by T for a while. The previous change already ensured that
there is no behavior change on S, so this is the safest approach.
This fixes HostsideLinkPropertiesGatingTests.
Bug: 239046959
Test: atest LinkPropertiesTest CtsHostsideNetworkTests
Change-Id: I55e078cdc06341f4957fe7bc743c0022b2c7d3da
"{@see" aren't rendered properly. Replace them with "See {@link"
or @see depending on the usage.
Bug: 238753273
Test: make doc-comment-check-docs ; Check the doc result
Change-Id: I70cb2f36e7c5fa8102b5949054df5184d755202c
Starting from T, VpnService supports exclude routes, which will
make the caller to get both of include routes and exclude routes
from LinkProperties#getRoutes(), and it's not expected to get the
exclude routes before T in production code even though the code
returns all routes.
But there is a CTS - LinkPropertiesTest#testRouteAddWithSameKey()
will try to add an exclude route and check if the result of
LinkProperties#getRoutes() contains that exclude route or not.
And the test is failed now since LinkProperties#getRoutes() will
only return include route if compat feature - EXCLUDED_ROUTES is
disabled. (EXCLUDED_ROUTES is enabled starting from target SDK T)
To fix this test failure, let LinkProperties#getRoutes() keeps
returning all routes if SDK is before T. This avoids changing
behavior on S, and even though there is still a behavior change
when upgrading to T, apps are unlikely to be relying on such
behavior, especially outside of tests.
Bug: 238061814
Test: Run "atest CtsNetTestCases:LinkPropertiesTest" on S build
with mainline module which contains this patch.
Change-Id: Iac4362c4fe347ee3f06d5b21b0325fa69a7f27b6
The constants are used for the NetworkAgent.sendQosCallbackError system
API, so changing their values changes the behavior of that API. This is
observed when running S CTS against the latest version of the
connectivity module: testQosCallbackOnError fails because a
SocketNotConnectedException ends up being reported, instead of an
UnsupportedOperationException.
Revert the constants to their values before change ID:
I7102ae9ba7cb9e1cc8d06b252aad4dad75860f3e
Bug: 238061856
Test: cts-tradefed run cts -m CtsNetTestCases \
-t android.net.cts.NetworkAgentTest
using a CTS v12.1 package.
Change-Id: Iaa12729d9e7dc627a6654a6fa47b8248e0cd3049
Previously, after calling unregisterNetworkOffer(), onNetworkNeeded() /
onNetworkUnneeded callbacks are still being called until CS's handler
thread has finished running. While this behavior could be taken care of
in the network provider implemention (e.g. the ethernet service), it is
much simpler to deal with in NetworkProvider.java.
As NetworkProvider.java wraps the passed callback object inside a proxy
that it forwards to CS, it should be as simple as adding a boolean to
the proxy that is checked inside the executor thread before the
implementation's callback is called. Since for every call to
registerNetworkOffer() with a new callback object a new proxy object is
created, this should be safe. Even if the callback object is reused on
the user side (such as ethernet service does right now), this should be
okay, as the implementation will only receive callbacks from the active
proxy.
Test: atest NetworkProviderTest
Bug: 171872016
Change-Id: Iaf84b5801ad3ee44895e933763927151ea5824dd
Without an IpClient, there is otherwise no way to configure IPv4
addresses on a tap interface in tests.
Test: TH
Change-Id: I6a788687708b2034c464befdfec9267ce3399d70
Add the required lib to the user of net-utils-framework-common-srcs
which has LocationPermissionChecker.
Bug: 158059172
Test: m
Merged-In: Id54de2bd94e8b5821814715683b5b2520f1f026e
Change-Id: Id54de2bd94e8b5821814715683b5b2520f1f026e
(cherry picked from commit d795228affd7e7ad828adb2bf4fbcb9093c3f377)
This commit adds ConnectivityManager#getFirewallChainEnabled to read the
current firewall chain status
Bug: 208371987
Test: m
Change-Id: I1eadb69f953af5d031cd8dabde3e1f098cf0f4df
Both setting the carrier up / down and creating an tun / tap interface
without carrier need TUNSETCARRIER to be present in the kernel.
Bug: 236783925
Test: documentation only change
Change-Id: Ie7f7d2c81c926adbc10b29b4b1748e47edaa4cb7
* changes:
TestNetworkInterface: add support for MacAddress and MTU
TestNetworkService: add support for creating iface without carrier
TestNetworkService: Add support for toggling carrier on tun/tap
TestNetworkService: Fix TestNetworkInterface parcel flags
Both MacAddress and MTU size are often needed in tests and very painful
to get a hold of without system server permissions.
Test: TH
Change-Id: Ie1a91959916ea39277e76aa1b61f38d59a5d2a90
Disabling the carrier of a tun/tap interface before the interface is
brought up is useful in testing.
Test: atest EthernetManagerTest
Change-Id: Ic189b2c0eda76e3f58c3f664e5f5d18c2d7e6e96
Adds support for setting carrier to on/off for a tun/tap interface. It
turns out that TUNSETCARRIER is also usable by tap interfaces, and
TUNSETLINK does not work as expected.
Test: atest EthernetManagerTest
Change-Id: I39d70e0a65a34e7a4c4df70c53e4cc781a24a213
This change allows tests to mock NetworkAgent, and the methods
required for ensuring that the VPN is migrating properly.
Bug: 235853154
Test: Treehugger
Change-Id: I49333c010cc7f3d60ffd39f853777bfc52de3a89
PARCELABLE_WRITE_RETURN_VALUE will close the fd when writeParcelable is
called. This is not always preferable (specifically, if
TestNetworkInterface is passed as an "in" parameter).
writeParcelable(FileDescriptor, ...) should therefore use the flags
passed to writeToParcel which should be correct for all cases.
Test: atest EthernetManagerTest
Change-Id: Ibb5f14028a3d686157504da3657a18ec0bc28110
(This rolls forward part of a previous change, now that jarjar was fixed
to not get very slow when the number of rules increases).
Jarjar rules are hard to keep in sync with code, and hard to maintain
manually as the distinction between what should and should not be
jarjared is not always clear. This results in unsafe binaries that are
manually maintained, and developer frustration when something fails due
to incorrect jarjar rules.
Add utility to autogenerate jarjar rules, which can be run at build time
time (via a genrule) instead. The generator scans pre-jarjar
intermediate artifacts, and outputs jarjar rules for every class to put
it in a package specific to the module. The only exceptions are:
- Classes that are API (module-lib API is the largest API surface of
the module, so module-lib API stubs would typically be used)
- Classes that have unsupportedappusage symbols
- Classes that are excluded manually (for example, because they have
hardcoded external references, like for
ConnectivityServiceInitializer in SystemServer).
Bug: 217129444
Test: atest jarjar-rules-generator-test;
Change-Id: I3493957e39a661b6c2e330944e7c3023b8f3203e
This change allows tests to mock NetworkAgent, and the methods
required for ensuring that the VPN is migrating properly.
Bug: 235853154
Test: Treehugger
Change-Id: If4de0935a3c8627ca12db52ff223834f9f7237e8
LOCKDOWN_VPN was in the FirewallChain IntDef but this was not a right
place because LOCKDOWN_VPN was not a valid value for Connectivity APIs
that take an argument annotated with @FirewallChain(setUidFirewallRule,
setFirewallChainEnabled, replaceFirewallChain).
LOCKDOWN_VPN was in the FirewallChain IntDef because
BpfNetMaps#setUidRule was used to add/remove LOCKDOWN_VPN entries.
This commit adds BpfNetMaps#updateUidLockdownRule and uses this to
add/remove LOCKDOWN_VPN entries instead of BpfNetMaps#setUidRule and
removes LOCKDOWN from FirewallChain.
Bug: 206482423
Test: atest TrafficControllerTest ConnectivityServiceTest
PermissionMonitorTest HostsideVpnTests#testBlockIncomingPacket
Change-Id: Iff9b9792fc0f208f153e10e396c6d5034b412d7c
The depfile concept in Soong and Ninja isn't applicable in Bazel because
Bazel requires listing the deps explicitly. This CL changes the module
type from gensrcs to java_library with proto.type set to "stream".
The end goal is to eventually deprecate depfile in gensrcs to ensure all
gensrcs modules are convertable to Bazel.
Test: CI
Bug: 179452413
Change-Id: I921324e6260b7de6329a1ff445b6326643a9c526
This reverts commit f1ab80ea62.
Reason for revert: DroidMonitor: Potential culprit for Bug 233698500 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I7de63e0a3656194b94b29e28862c62fc300dfdfa
This broke my tests in unexpected ways as creating a new
NetworkRequest.Builder() changed the static request object.
Test: TH && atest EthernetManagerTest
Change-Id: Ia6c39145cf92a2795f7fc2f4efbcb46d193f6b72
