For devices using Play services, disable auto-update during tests, as it
may interfere with them. For example, Webview may be killed if it is
opened while the update is applied.
Bug: 263665773
Test: atest
Change-Id: I9613d739ad0763c882a1971879aa743f4541a75c
Rename ConnectivityCheckTargetPreparer to
ConnectivityTestTargetPreparer, and the ConnectivityChecker app to
ConnectivityTestPreparer, and remove the assumption that the app only
does connectivity checks.
This will allow overriding the app with versions that have more specific
setup steps in downstream branches.
Bug: 263665773
Bug: 267413275
Test: tests using this preparer
Merged-In: Icb9b1eb8eb1c75f89cb751e0ca696ea96359e6d0
Change-Id: Icb9b1eb8eb1c75f89cb751e0ca696ea96359e6d0
Given the maximum prefix length of IPv6 address is 128 and it
should not be assigned via IA prefix option to client, so S8
is enough to represent the prefix-length field.
Bug: 260934173
Test: m
Change-Id: Ia7fc52f7495775f3a29141d75adffafd84c38a02
This reverts commit fbe95d914c707c34d2c9d150a467d51c73414fcd.
Reason for revert: I've reconsidered. This is a bad idea.
(and there are not yet any users)
The NetworkStack is an apk, not an apex, and as such it cannot
ship any bpf .o files (since that requires apex disk image format
instead of apk/jar zip file format).
There's no support for this (NetworkStack shipping bpf) in the
current tip-of-tree bpfloader.
As such there's no chance of this happening before V.
And even in V+ it is *super* unlikely, because... apk...
(We'd have to add apk zip traversal into the bpfloader...)
As such NetworkStack cannot possibly own any bpf programs/maps,
and could only potentially access platform/system bpf maps or
bpf maps owned by another module (ie. the Tethering apex).
Using any bpf maps from the system is not viable, as these
are owned by the platform, and as such may be modified by
vendors/oems. Ie. their number, names, key/value layout, etc...
cannot be guaranteed. As such using them from mainline
code is simply not safe.
Furthermore none of the platform bpfs are network related
(and indeed bpfloader enforces this).
As such this the only potential use of this would be
for NetworkStack to use Tethering apex bpf maps/programs.
However, this is also unsafe.
On older devices (pre-S) we don't even have support for
tethering apex shipped programs/maps.
On pre-T only the offload program is shipped, while
roughly equivalent netd.o maps/programs for the other
stuff are still provided by the platform.
(but the format of these cannot be relied upon)
As such use would have to be limited to T+.
(because the offload bpf map isn't interesting
to the network stack)
But on T+ we run into a cross-module versioning problem:
the source (and thus bpf map name/format/struct definitions)
used to build the NetworkStack apk and Tethering apex may differ.
Even modules shipped in tandem are build from separate release branches. Additionally there's potential for only one module
to update, while the other remains older. Thus making this
work cross-module would require freezing the map name & format.
ie. they would need to become cross-module API.
This is not something I'm willing to do.
Basically, this can be summarized as:
there is no *safe* way for NetworkStack apk to use bpf maps.
Test: TreeHugger
Bug: 276230058
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I65ecf6ffca6ae88a1b72f6f4c8a5739991d78fe3
The DNS-over-TLS port is a commonly used port number that is
typically set to 853 and is unlikely to be changed. To prevent
from code duplication in various modules, it would be beneficial
to include the port number definition in a static library.
Test: TH
Bug: 276230058
Change-Id: I7e6d0056ba15c932d9b4c3dd8760924278bde8fe
Enable error-prone checking in the net-utils-framework-common to
catch NullablePrimitive errors during build time.
Also fix any NullablePrimitive errors that are found in the
library classes.
Bug: 256991804
Test: Enable error-prone checking and check if the build fails
with any NullablePrimitive errors. If it does, fix the
errors and build again.
Change-Id: I7e1508d166f258f5232ff39388ac984fbdc6169e
When loading BpfMap class, JNI part is needed for native
methods. Allow the static lib can be compiled with NetworkStack
JNI library.
Test: atest FrameworksNetTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Bug: 276230058
Change-Id: I72ebe801dacd02de6711558d2058c1b756cf3080
isFeatureEnabled is not usable in APEX module service initialization,
as it relies on PackageManager.getModuleInfo, which is only available
once the module controller is initialized. Also, there is no module
metadata in base AOSP.
Avoid this by guessing the tethering module name based on its
APK-in-APEX packages, which can be queried at that time.
ConnectivityServiceResources will indicate the package prefix used on
the device.
If querying with prefix + "tethering" fails, retry querying with prefix
+ "go.tethering" for Go devices.
This should allow using isFeatureEnabled in services (like
ConnectivityService) constructors, and allows removing the
FIXED_PACKAGE_VERSION hack when Tethering is not considered a module.
getConnectivityResourcesPackageName is implemented based on existing
code in ConnectivityResources.java. aosp/2446026 updates
ConnectivityResources to use getConnectivityResourcesPackageName.
Bug: 279108992
Test: atest
Change-Id: I277f4583e92ba41d53bd19666f1e8e29f68dfcd1
(they're only of historical interest at this point)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0e52efda62626091c3023c5fd3622ffcdcd00ee1
This is the default for BPFLOADER_MIN_VER if not otherwise specified.
This does not affect mainline code, see:
cs/p:aosp-master file:packages/modules/Connectivity/bpf_progs define.*BPFLOADER_MIN_VER
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ice5b14c3b580653f8889a5292abaa89cf8434da1
This is also needed in other classes in subsequent CLs, move to
a common place to prevent from code duplication.
Test: TH
Bug: 275532605
Change-Id: Id460cd231bbc520ebdcfe988a7507c6959500ac4
This CL also adds SOCK_DESTROY constants.
These changes will be used by upcoming CLs that implement socket destroy
in ConnectivityService.
Bug: 270298713
Test: atest NetworkStaticLibTests
Change-Id: Ief507b3f8cc4fe23c08699e7fc8f3f62e5acfcdc
Before this CL, StructInetDiagSockId.parse convert v4-mapped v6 address
to Inet4Address that is inconsistent with the value in
inet_diag_msg.idiag_family.
Also, due to this behavior, input of parse and output of pack could be
different.
This is the issue specifically when SOCK_DESTROY request is populated
based on the InetDiagMessage from the kernel.
Bug: 270298713
Test: atest NetworkStaticLibTests
Change-Id: I45256bb1069cfc4e01662b3a533077933f3f019a
