We needed this proguard flag because
ThreadNetworkService#onLocalNetworkInfoChanged will otherwise be
stripped. We need to keep the method to ensure the border routing
feature works.

Initially we put the flag in thread/service/proguard.flags. However,
this seems not working on udc-mainline-prod branch. After moving it to
Connectivity/service/proguard.flags, it works as desired.

Bug: 313539492

Change-Id: I33cb0602095a617dbb1cfe3d9002f9c68e93cccf

Jarjar com.android.server* and adjust the test by jarjar
FrameworksNetTestsLib to make sure the test cases still can access
package sope fields. Don't auto-jarjar non-connectivity module tests
in FrameworksNetTests because some non-connectivity module test cases
rely on service.core and service.net. The reason why not auto-jarjar
whole ConnectivityCoverageTests because tethering doesn't adopt
auto-jarjar-gen yet. The coverage test must jarjar the same as module so
that test coverage can calculate correctly.

Remove com.android.server* from proguard becasue it already be covered
by android.net* after jarjar'ed.

Move MetricsTestUtil to non connectivity module test group because it
only be used for IpConnectivityEventBuilderTest which is non connectivity
module test. Only jarjar the util without jarjar the caller make the test
failure.

Bug: 248001529
Test: atest ConnectivityCoverageTests FrameworksNetTests

Change-Id: I8439341ef4c03f29697fdf34557ea8ef2825d691

This includes in particular {Full,Network}Score.POLICY_* members
which were removed recently.

Before :
  Policies : 55&62&63
After :
  Policies : EVER_EVALUATED&EVER_VALIDATED&IS_VALIDATED

This patch also unifies the directives under Tethering/ for
simplicity.

Test: adb logcat & dumpsys connectivity & dumpsys tethering
Change-Id: I3d231fbaaebe233b2633da8bb880b5ad1613a32f

This change enables R8 shrinking, and R8 full mode of standalone system
server jar service-connectivity. Keep rules are specified based on the entries in
frameworks/base/services/java/com/android/server/SystemServer.java. Keep rules of classes extending SystemServer is inherited from "standalone-system-server-module-optimize-defaults", https://cs.android.com/android/platform/superproject/+/master:packages/modules/common/proguard/Android.bp, which is a set of common rules for standalone system server jar. Keep rules of proto is inherited from "proguard_basic_keeps", https://cs.android.com/android/platform/superproject/+/master:build/make/core/proguard_basic_keeps.flags, which is the common set of keep rules for all dex target.

The
size of service-connectivity will be reduced by 31% from 2094301B to 1426485B.

Test: Presubmit and MTS. Run MTS locally with command `mts-tradefed run` with `mts-tethering`, `mts-network`, `mts-cellbroadcast` on  Pixel 4 with sunfish-userdebug image.
Bug: 233746531
Change-Id: I291c9d880a1ffc7dc87f932f9d27ce3740b9dc36

(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

(clean cherry-pick of downstream change)

Test: build and check classes in service-connectivity.jar.
Bug: 217115866
Merged-In: I9f7db4509bf8fe736f5d9fc08b164a20b2274aa8
Change-Id: Ia97b7ab645e3425780b335c699b57a6dc7589f2a

Test: build and check classes in service-connectivity.jar.
Bug: 217115866
Ignore-AOSP-First: nearby_not_in_aosp_yet
Change-Id: I9f7db4509bf8fe736f5d9fc08b164a20b2274aa8
Merged-In: Ifd73882c804d3c8a998cd4b9a263fdecbc0f98f7

See go/fp-chre for details. This change has been verified on device with
mock BLE event to support Fast Pair fitler update, device discovery, and
screen on notification to CHRE.

Test: unit tests and on device tests.

Fix: 232286342
Ignore-AOSP-First: nearby_not_in_aosp_yet

Change-Id: Ifd73882c804d3c8a998cd4b9a263fdecbc0f98f7

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

The optimizer has been enabled in downstream branches (including those
used for upcoming module releases) for a few months. This brings aosp in
line with them.

This is a cherry-pick of change:
I3be9422a431a5b5bc1478960ce332a89377bd632

where proguard.flags have been replaced with the most up-to-date version
used in downstream branches.

Test: m
Merged-In: I3be9422a431a5b5bc1478960ce332a89377bd632
Change-Id: I55455eb58d3fdc4dbf3ea81961d5c7756fea0046

Test: build and check classes in service-connectivity.jar.
Bug: 217115866
Change-Id: Ibf8d3ee5274a709479b9ab7f0af2b3e0a7e7fa7b
Ignore-AOSP-First: nearby_not_in_aosp_yet

Add a proguard rule to prevent proguard from stripping out
fast-pair-lite-protos classes/fields.

Fix: 218607668
Test: atest CtsNearbyFastPairTestCases and manual steps in b/218607668#comment2
Ignore-AOSP-First: Nearby is not yet in AOSP. This introduces minimal
                   unavoidable merge conflicts until it is merged there.
Change-Id: I947c9e3b6ebc232e230782f6345c5cb6893138e6

Keep classes in android.net, as a followup change will have
some utility classes in that package in service-connectivity.

Ideally only "entry point" classes would be listed in the flags,
and the optimizer would figure out what is unreachable and
can be stripped out; but to be safe for now, list all classes.

Ignore-AOSP-First: Proguard rules not yet cherry-picked
Bug: 204830222
Change-Id: I45954f3bd23e84bacfd0f94875e10687e3e9cbc9
Test: m

Nearby will be merged together with the tethering/connectivity APEX, so
that module maintenance efforts can be reduced, and the two codebases
can evolve the interfaces that they expose to each other over time.

Bug: 189355156
Test: m
Ignore-AOSP-First: Nearby is not yet in AOSP. This introduces minimal
                   unavoidable merge conflicts until it is merged there.
Change-Id: If4b40689a257d2806f895cd2dded97fc699adc5f

The current proguard rules keep all classes currently in the jar, so
this does not strip any classes, but it applies optimizations on the
code.
Enabling proguard will be useful when adding service-nearby to the jar.

Bug: 189355156
Test: m service-connectivity; check list of classes in jar unchanged
Change-Id: I3be9422a431a5b5bc1478960ce332a89377bd632