With the release cut of the July train and the recent automerger
cutover, tm-mainline-prod is now officially an abandoned branch.

This change deletes (most) infrastructure that was put in place to
disable cronet on tm-mainline-prod.

Test: builds
Bug: 278639767
(cherry picked from https://android-review.googlesource.com/q/commit:2e3e2955b8cf7ba181788140dd62b2dd20e7b600)
Merged-In: I078f2114b736a634f08d8f704c19beb2224ef645
Change-Id: I078f2114b736a634f08d8f704c19beb2224ef645

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
(cherry picked from https://android-review.googlesource.com/q/commit:7a03c187f596049db96acdae3f00dc6ff5e9e672)
Merged-In: I4b659a3cd32b89a65549b56006b926a5ac755f7b
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

Keep using NetworkStackApiStableShims as this is a module release
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).

Ignore-AOSP-First: this needs to be submitted separately in each branch,
                   with downstream branches first as there are merge
		   conflicts in Tethering/apex/Android.bp that cannot be
		   automerged.

Bug: 266205506
Test: m
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:921290b49d109360aae5dc39effaa3b0e691f65a)
Merged-In: I88228152834a1c06830fb51e868fb8e3d8c47519

Change-Id: I88228152834a1c06830fb51e868fb8e3d8c47519

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).

Ignore-AOSP-First: this needs to be submitted separately in each branch,
                   with downstream branches first as there are merge
		   conflicts in Tethering/apex/Android.bp that cannot be
		   automerged.

Bug: 266205506
Test: m
Change-Id: I88228152834a1c06830fb51e868fb8e3d8c47519

8484ec4d

Change-Id: I490c09179ea6a20ca5fba83c314b552d360be688

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

* This was causing the infra to ignore the modules and masking build errors.

Test: TH
Change-Id: Ic5aa3557353488d5370f4d9c4240954820bfe52b

This relands commit 2cd4ac87

Merged-In: I903369dbad37b663a39e80149e25b0634386df6d
Change-Id: I018121bf4d02ccc59c89de39e3d1598deb9cf67b
Bug: 274094720

This relands commit 2cd4ac87

Merged-In: Iee63b9f53866d1f44440fed1e632549dd6b296f9
Change-Id: I903369dbad37b663a39e80149e25b0634386df6d
Bug: 274094720

This relands commit 2cd4ac87

Change-Id: Iee63b9f53866d1f44440fed1e632549dd6b296f9
Ignore-AOSP-First: We need to build our way up to AOSP to have end up with a line change difference in tm-mainline-prod
Bug: 274094720

This reverts commit 2cd4ac87.

Reason for revert: b/273575026

Change-Id: I5b9886465b8a0f71af469d303a39f670a9b0cb68

Test: m && atest CtsNetHttpTestCases
Change-Id: I3c28a52d60128cf4324eda436c1f6e9fa463108e

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

Test: m
API-Coverage-Bug: 258707653

Change-Id: I2d6401ec719ce265abdb30d6ba8fd94861845197

Cronet is being released in U and therefore shouldn't become part of the
tethering apex until then.

The Merged-In line of this change references the change that originally
introduced it to prevent it from automerging anywhere.

Test: TH
Merged-In: I5a15acfed68f47b4d59fa72da3dbbce2fd00ae63
Change-Id: I2db8597adc8b4b340761fe4727fd7c74afaa4084

Merging them as enabled, so they can be disabled on tm-mainline-prod.

Test: TH
Change-Id: I5a15acfed68f47b4d59fa72da3dbbce2fd00ae63

The "next" targets are only used for development builds using
unfinalized SDKs, and are not necessary in the module release
branch.

This should not be (auto)merged in development branches.

Ignore-AOSP-First: module release branch-only change
Change-Id: I8cb64d8bb86b781cd57d1a1a466c56185573fcc2
Test: m

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

This reverts commit d44b2931.

Reason for revert: b/255986188

Change-Id: Ida999c15203b77aae1420be96dece22396c4ede1

Also remove cronet apex related modules and files

Bug: 251054736
Test: atest CronetApiTest
Change-Id: Idd41785fd2f74a153c5bb03f4c00c7cccdb50e7a

DCLA (Dynamic Common Library Apex) is a mechanism used by Mainline, which places shared c++ libraries into a separate apex in order to de-duplicate them, with the goal of reducing the overall size of a train.

This change results in two packages being built:
If the APEX_BUILD_FOR_PRE_S_DEVICES=1 is set, the apex will have min_sdk set to 30 as before, and this will deliver to Android 11.
If the flag is not set, the second package will have min_sdk set to 31, and will deliver to Android 12 and beyond.

If developers intend to build an apex for use in R as before, they must set the flag APEX_BUILD_FOR_PRE_S_DEVICES=1, which will set the min_sdk to 30 as before. If not set, the new default behavior will set the min_sdk to 31.

This new variant will be post-processed and trimmed by Mainline infrastructure, and the resulting trimmed module can only be installed on S+ devices, requiring that we set the min_sdk to 31.

Test: APEX_BUILD_FOR_PRE_S_DEVICES=1 m com.android.tethering & verify
      sdk_version = 30
Test: m com.android.tethering & verify sdk_version = 31
Bug: 247762791
Change-Id: I2d6563867e3ca36f678fe0abadbe197946a82094

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

This reverts commit 53eb35cd.

Reason for revert: b/233081774, caused long build times in FrameworkNetTests

Change-Id: Ide01c994f694b55fc0e87bb0e81584ac44196e68
Merged-In: Ide01c994f694b55fc0e87bb0e81584ac44196e68
(cherry picked from commit ece3171c)
(cherry picked from commit 8e50171f)
Merged-In: Ide01c994f694b55fc0e87bb0e81584ac44196e68

This reverts commit 53eb35cd.

Reason for revert: b/233081774, caused long build times in FrameworkNetTests

Change-Id: Ide01c994f694b55fc0e87bb0e81584ac44196e68
Merged-In: Ide01c994f694b55fc0e87bb0e81584ac44196e68
(cherry picked from commit ece3171c)
(cherry picked from commit 8e50171f)
Merged-In: Ide01c994f694b55fc0e87bb0e81584ac44196e68

This reverts commit 53eb35cd.

Reason for revert: b/233081774, caused long build times in FrameworkNetTests

Change-Id: Ide01c994f694b55fc0e87bb0e81584ac44196e68
Merged-In: Ide01c994f694b55fc0e87bb0e81584ac44196e68
(cherry picked from commit ece3171c)

This reverts commit 53eb35cd.

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 53eb35cd)
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 d72a5a7a)
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

Gate presence of excluded routes in LinkProperties on target sdk T.

Bug: 186082280
Test: atest LinkPropertiesTest
Change-Id: If8fdb468a0a4968c5f2a878b7aacfeb4f7d9a9e5