It is just a constant source of bugs, with no real tests,
let's stop pretending this is a supported configuration.
The only tested configuration is out-of-process tethering
updatable apex.
Test: TreeHugger
Bug: 279942846
Change-Id: I4b659a3cd32b89a65549b56006b926a5ac755f7b
aosp/2384137 added cronet to framework-tethering.
But framework-connectivity is a better place to put cronet since
cronet does not work on R devices (b/270049141) and
framework-tethering is R+, framework-connectivity is S+.
Followup CLs will move some modules (e.g. CronetJavaPrejarjarDefaults)
that use the branch dependent soong variables to framework/Android.bp
Test: TH
Bug: 278070640
Change-Id: I6bc10116759fb9e083c02147908e53022dab740a
Instead of NetworkStackApiStableShims, use NetworkStackApiCurrentShims
as this is a development branch.
Use java_defaults in the "merge conflicts expected" section, so that
module release branches can use the same defaults, but set it to
NetworkStackApiStableShims.
The shims are removed from FrameworksNetIntegrationTests, as they are
already available there through service-connectivity-pre-jarjar. Keeping
them as a dependency would make FrameworksNetIntegrationTests use both
Stable shims (directly) and Current shims
(through service-connectivity-pre-jarjar).
Bug: 266205506
Test: m
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:921290b49d109360aae5dc39effaa3b0e691f65a)
Merged-In: I88228152834a1c06830fb51e868fb8e3d8c47519
Change-Id: I88228152834a1c06830fb51e868fb8e3d8c47519
Revert submission 2502135-remove_soong_namespace
Reason for revert: Missing line needs to be added
Reverted changes: /q/submissionid:2502135-remove_soong_namespace
Change-Id: I780a21cf7031e04eb368fda4f93ed16ea032ca8d
ConnectivityCompatChanges.java becomes the centralized place for all the
CompatChanges used in the Connectivity module. By putting all the
CompatChanges here, we are able to manage them under a single
platform_compat_config.
Bug: 268440216
Test: atest FrameworksNetTests
Change-Id: I3e17af545718073d7d1c96e27298e7790563fd33
This change introduces a limited library for dependencies on
framework-connectivity from Tethering,
connectivity-internal-api-util, where all classes are annotated with
@RequiresApi(S) to ensure proper API checks are done before usage.
Bug: 245972418
Change-Id: I82bafd9063341adc71d07f0858e6d68283d081f0
The library provides an interface to interface with the
ConnectivityNative service, and implement port blocking APIs.
Bug: 179733303
Test: atest connectivity_native_test
Change-Id: Iad1c84b5eeab835aca14a2db72a900e099aa3c1c
Previously, the hiddenapi*-tiramisu.txt files that were created as part
of the work for creating framework-connecvity-t were just added to the
list of hidden API files on the bootclasspath_fragment. Unfortunately,
that made it impossible to exclude those when generating an sdk
snapshot for S which cannot include framework-connectivity-t.
This change moves those files to be part of framework-connectivity-t
instead of the bcpf so that they will only be used in an sdk snapshot
when the library is part of the snapshot.
Bug: 240406019
Test: packages/modules/common/build/mainline_modules_sdks.sh
# Ran the previous command with and without this change to make
# sure that this change does not change the sdk snapshot
# contents. A follow up change will exclude the
# framework-connectivity-t library from the S sdk snapshot.
Change-Id: Ib5c5c6046d96b911c8e9e5ac3729ce963f1b6907
Add back compat config for RUN_NATIVE_NSD_ONLY_IF_LEGACY_APPS, which was
lost when moving NsdManager to framework-connectivity-t.
This causes NsdManager to start mdnsresponder again when used by apps
with target SDK < 31.
The change also changes the compat ID used, to make sure it does not
conflict with the ID already in use in S and below, when the module is
installed on such a platform. This is the only ChangeId used by
framework-t.
Also add a CtsNetTestCasesMaxTargetSdk30 test to verify that behavior.
Bug: 235355681
Test: atest CtsNetTestCasesMaxTargetSdk30
Change-Id: I7ca6051d0a4ba5aff3e44bece2cbac22eb1be32d
Underscore character may cause bpf prog/map naming collision. For
example, x.o with map y_z and x_y.o with map z both result in x_y_z
prog/map name, which should be prevented during compile-time.
aosp/2147825 will prohibit underscore character in bpf source name
(source name derives the obj name). Existing bpf modules with underscore
characters in source name need to be updated accordingly.
Bug: 236706995
Test: atest bpf_existence_test
Test: adb root; adb shell ls -l sys/fs/bpf/net_shared | grep dscpPolicy
Change-Id: Ibe98944d09d42bd11b78b5e9ae35ded48c70416d
(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
InProcessTethering runs as system_server (uid/gid AID_SYSTEM)
instead of as the network_stack (uid/gid AID_NETWORK_STACK).
Additionally only the network_stack has access to the default
selinux context of /sys/fs/bpf/tethering, which is fs_bpf_tethering,
so we need to use 'fs_bpf_net_shared' instead.
Bug: 190523685
Bug: 236925089
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibb6ae255dcd8a8e8049be112055f60c3b2cf7df0
The objdump -x visible changes between old and new versions of the
mainline shipped .o files are really very minimal: just the inclusion
of a new .BTF section and changes/removals of some 'l' entries from
the symbol table. However, it turns out a change to symbol ordering
is incompatible with BpfLoader <v0.10 which doesn't know to skip
non-function symbols, and as such enabling btf requires a little
bit of gymnastics.
After:
$ adbz shell ls -l /apex/com.android.tethering/etc/bpf/*.o
-rw-r--r-- 1 system system 118352 1969-12-31 16:00 /apex/com.android.tethering/etc/bpf/offload.o
-rw-r--r-- 1 system system 123424 1969-12-31 16:00 /apex/com.android.tethering/etc/bpf/offload@btf.o
-rw-r--r-- 1 system system 2232 1969-12-31 16:00 /apex/com.android.tethering/etc/bpf/test.o
-rw-r--r-- 1 system system 6376 1969-12-31 16:00 /apex/com.android.tethering/etc/bpf/test@btf.o
$ adbz shell logcat -d | egrep offload.*[.]o
07-15 13:10:43.358 0 0 D LibBpfLoader: Loading critical for tethering ELF object /apex/com.android.tethering/etc/bpf/offload.o with license Apache 2.0
07-15 13:10:43.359 0 0 I LibBpfLoader: BpfLoader version 0x00019 ignoring ELF object /apex/com.android.tethering/etc/bpf/offload.o with max ver 0x00019
07-15 13:10:43.359 0 0 I bpfloader: Loaded object: /apex/com.android.tethering/etc/bpf/offload.o
07-15 13:10:43.374 0 0 D LibBpfLoader: Loading critical for tethering ELF object /apex/com.android.tethering/etc/bpf/offload@btf.o with license Apache 2.0
07-15 13:10:43.375 0 0 I LibBpfLoader: BpfLoader version 0x00019 processing ELF object /apex/com.android.tethering/etc/bpf/offload@btf.o with ver [0x00019,0x10000)
07-15 13:10:43.452 0 0 D LibBpfLoader: map_fd found at 0 is 6 in /apex/com.android.tethering/etc/bpf/offload@btf.o
...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id658818d1d42763358747523615b7918d312588e
This change results in the existence of either:
/apex/com.android.tethering/etc/flag/out-of-process
(Phones with mainline updatable Tethering in network_stack process)
or
/apex/com.android.tethering/etc/flag/in-process
(Android Go with InProcessTethering in system_server process)
These flags provide an easy way for the BpfLoader to
detect the required selinux context for /sys/fs/bpf/tethering
directory.
Bug: 190523685
Bug: 236925089
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8e66806d81893885a5ebe8a6dd4194c5b9dae219
When the apex version is set to 0, the version number will be replaced by the build system to the default value for the current branch.
The default value for mainline module manifest version is stored in the defaultManifestVersion constant: https://android.googlesource.com/platform/build/soong/+/refs/heads/master/apex/constants.go#36
The version should not be changed manually in the manifest. Release tooling will set this version to the release version on the release branches.
Test: presubmit
Bug: 231691643
Change-Id: I30b5b486bca521ebdeed17dba7afc61f2c529ab8
Merged-In: I30b5b486bca521ebdeed17dba7afc61f2c529ab8
T FRC signals cannot be gathered from tm-frc-<module>-release branches
and instead tm-release is being used. tm-release uses default source
based version codes which are lower than prebuilts now. Bump them to
allow installation on tm-release based system images.
Bug: 233587299
Test: presubmit
Merged-In: Ibbf3dbf2db8eb8c15d8c9cf8ba0b8363d5c33c5c
Change-Id: Ie3cd8369091571adf6d2265adb62cb9c725234e4
This reverts commit 53eb35cd82.
Reason for revert: b/233081774, caused long build times in FrameworkNetTests
Change-Id: Ide01c994f694b55fc0e87bb0e81584ac44196e68
Merged-In: Ide01c994f694b55fc0e87bb0e81584ac44196e68
(cherry picked from commit ece3171cf0)
This reverts commit 53eb35cd82.
Reason for revert: b/233081774, caused long build times in FrameworkNetTests
Change-Id: Ide01c994f694b55fc0e87bb0e81584ac44196e68
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.
Autogenerate jarjar rules at build time instead. This is achieved by
introducing a jarjar-rules-generator python-based library, which 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)
- Classes that have unsupportedappusage symbols
- Classes that are excluded manually (for example, because they have
hardcoded external references, like for
ConnectivityServiceInitializer in SystemServer).
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: Ied17c3955ea2fda130089265d02908937ad8af1e
(cherry picked from commit 53eb35cd82)
Merged-In: Ied17c3955ea2fda130089265d02908937ad8af1e
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.
Autogenerate jarjar rules at build time instead. This is achieved by
introducing a jarjar-rules-generator python-based library, which 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)
- Classes that have unsupportedappusage symbols
- Classes that are excluded manually (for example, because they have
hardcoded external references, like for
ConnectivityServiceInitializer in SystemServer).
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: Ied17c3955ea2fda130089265d02908937ad8af1e
this hack is no longer needed now that duplicate target in system/netd
is no longer an issue due to automerger to sc-mainline-prod being
turned off
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id2c1dfac3bc4e6a8f5376a41ca2d1432b838da38
(cherry picked from commit d72a5a7a70)
Bug: 232017472
Merged-In: Id2c1dfac3bc4e6a8f5376a41ca2d1432b838da38
this hack is no longer needed now that duplicate target in system/netd
is no longer an issue due to automerger to sc-mainline-prod being
turned off
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id2c1dfac3bc4e6a8f5376a41ca2d1432b838da38
