android_packages_modules_Co.../Tethering/apex/Android.bp

232 lines
7.4 KiB
Plaintext
Raw Normal View History

//
// Copyright (C) 2019 The Android Open Source Project
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
package {
default_applicable_licenses: ["Android-Apache-2.0"],
}
prebuilt_etc {
name: "TetheringOutOfProcessFlag",
src: "out-of-process",
filename_from_src: true,
sub_dir: "flag",
}
// Defaults to enable/disable java targets which uses development APIs. "enabled" may have a
// different value depending on the branch.
java_defaults {
name: "ConnectivityNextEnableDefaults",
enabled: true,
}
java_defaults {
name: "NetworkStackApiShimSettingsForCurrentBranch",
// API shims to include in the networking modules built from the branch. Branches that disable
// the "next" targets must use stable shims (latest stable API level) instead of current shims
// (X_current API level).
static_libs: ["NetworkStackApiCurrentShims"],
}
apex_defaults {
name: "ConnectivityApexDefaults",
// Tethering app to include in the AOSP apex. Branches that disable the "next" targets may use
// a stable tethering app instead, but will generally override the AOSP apex to use updatable
// package names and keys, so that apex will be unused anyway.
apps: ["TetheringNext"], // Replace to "Tethering" if ConnectivityNextEnableDefaults is false.
}
enable_tethering_next_apex = true
// This is a placeholder comment to avoid merge conflicts
// as the above target may have different "enabled" values
// depending on the branch
apex_defaults {
name: "CronetInTetheringApexDefaults",
jni_libs: [
"cronet_aml_components_cronet_android_cronet",
"//external/cronet/third_party/boringssl:libcrypto",
"//external/cronet/third_party/boringssl:libssl",
],
arch: {
riscv64: {
// TODO: remove this when there is a riscv64 libcronet
exclude_jni_libs: [
"cronet_aml_components_cronet_android_cronet",
"//external/cronet/third_party/boringssl:libcrypto",
"//external/cronet/third_party/boringssl:libssl",
],
},
},
}
apex {
name: "com.android.tethering",
defaults: [
"ConnectivityApexDefaults",
"CronetInTetheringApexDefaults",
"r-launched-apex-module",
],
compile_multilib: "both",
bootclasspath_fragments: [
"com.android.tethering-bootclasspath-fragment",
],
systemserverclasspath_fragments: [
"com.android.tethering-systemserverclasspath-fragment",
],
multilib: {
first: {
jni_libs: [
"libservice-connectivity",
"libandroid_net_connectivity_com_android_net_module_util_jni",
],
native_shared_libs: [
"libcom.android.tethering.connectivity_native",
"libnetd_updatable",
],
},
both: {
jni_libs: [
"libframework-connectivity-jni",
"libframework-connectivity-tiramisu-jni"
],
Enable tethering to perform its own hidden API processing Previously, the hidden API encoding of the tethering boot dex jars, i.e. those dex jars that tethering contributes to the bootclasspath were done as part of the monolithic hidden API processing. This change causes the encoding to be done by the tethering's bootclasspath_fragment. This change involves the following: * Addition of the fragments property to the tethering's bootclasspath_fragment module to list all the other bootclasspath_fragment modules on which this depends. * Addition of the additional_stubs property to add stubs for APIs that are not provided by another bootclasspath_fragment. * Moving hidden API flag file entries related to tethering from the flag files in frameworks/base/boot/hiddenapi directory into the tethering directory with an appropriate OWNERS file to allow them to be managed by the Soong and compat team. * Addition of a PREUPLOAD.cfg hook script to ensure that the flag files are sorted. The build automatically checks that the hidden API flags which are computed by tethering and encoded into its boot dex jars match those that are generated by the monolithic processing so this is guaranteed to be safe. Bug: 179354495 Test: m com.android.tethering - ensure that the generated APEX is byte-for-byte identical before and after these changes. m out/soong/hiddenapi/hiddenapi-flags.csv - make sure that they are not changed by this. Change-Id: I4d9621325c7fcea5043cbca4c577ba2ac6125c0c Ignore-AOSP-First: merge conflicts
2021-05-26 09:46:20 +00:00
},
},
binaries: [
"clatd",
],
canned_fs_config: "canned_fs_config",
bpfs: [
"block.o",
"clatd.o",
"dscpPolicy.o",
"netd.o",
"offload.o",
enable btf for offload.o & test.o 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
2022-04-23 19:33:32 +00:00
"offload@btf.o",
"test.o",
enable btf for offload.o & test.o 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
2022-04-23 19:33:32 +00:00
"test@btf.o",
],
apps: [
"ServiceConnectivityResources",
"HalfSheetUX",
],
prebuilts: [
"current_sdkinfo",
"privapp_allowlist_com.android.tethering",
"TetheringOutOfProcessFlag",
],
manifest: "manifest.json",
key: "com.android.tethering.key",
// Indicates that pre-installed version of this apex can be compressed.
// Whether it actually will be compressed is controlled on per-device basis.
compressible: true,
androidManifest: "AndroidManifest.xml",
compat_configs: [
"connectivity-platform-compat-config",
],
}
apex_key {
name: "com.android.tethering.key",
public_key: "com.android.tethering.avbpubkey",
private_key: "com.android.tethering.pem",
}
android_app_certificate {
name: "com.android.tethering.certificate",
certificate: "com.android.tethering",
}
Use jarjar rule generator for connectivity rules (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
2022-04-20 06:59:16 +00:00
filegroup {
name: "connectivity-hiddenapi-files",
srcs: [
":connectivity-t-hiddenapi-files",
"hiddenapi/*.txt",
],
Use jarjar rule generator for connectivity rules (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
2022-04-20 06:59:16 +00:00
visibility: ["//packages/modules/Connectivity:__subpackages__"],
}
// Encapsulate the contributions made by the com.android.tethering to the bootclasspath.
bootclasspath_fragment {
name: "com.android.tethering-bootclasspath-fragment",
contents: [
"framework-connectivity",
"framework-connectivity-t",
"framework-tethering",
],
apex_available: ["com.android.tethering"],
Enable tethering to perform its own hidden API processing Previously, the hidden API encoding of the tethering boot dex jars, i.e. those dex jars that tethering contributes to the bootclasspath were done as part of the monolithic hidden API processing. This change causes the encoding to be done by the tethering's bootclasspath_fragment. This change involves the following: * Addition of the fragments property to the tethering's bootclasspath_fragment module to list all the other bootclasspath_fragment modules on which this depends. * Addition of the additional_stubs property to add stubs for APIs that are not provided by another bootclasspath_fragment. * Moving hidden API flag file entries related to tethering from the flag files in frameworks/base/boot/hiddenapi directory into the tethering directory with an appropriate OWNERS file to allow them to be managed by the Soong and compat team. * Addition of a PREUPLOAD.cfg hook script to ensure that the flag files are sorted. The build automatically checks that the hidden API flags which are computed by tethering and encoded into its boot dex jars match those that are generated by the monolithic processing so this is guaranteed to be safe. Bug: 179354495 Test: m com.android.tethering - ensure that the generated APEX is byte-for-byte identical before and after these changes. m out/soong/hiddenapi/hiddenapi-flags.csv - make sure that they are not changed by this. Change-Id: I4d9621325c7fcea5043cbca4c577ba2ac6125c0c Ignore-AOSP-First: merge conflicts
2021-05-26 09:46:20 +00:00
// The bootclasspath_fragments that provide APIs on which this depends.
fragments: [
{
apex: "com.android.art",
module: "art-bootclasspath-fragment",
},
],
// Additional stubs libraries that this fragment's contents use which are
// not provided by another bootclasspath_fragment.
additional_stubs: [
"android-non-updatable",
],
// Additional hidden API flag files to override the defaults. This must only be
// modified by the Soong or platform compat team.
hidden_api: {
max_target_o_low_priority: [
"hiddenapi/hiddenapi-max-target-o-low-priority.txt",
],
unsupported: [
"hiddenapi/hiddenapi-unsupported.txt",
],
// The following packages contain classes from other modules on the
// bootclasspath. That means that the hidden API flags for this module
// has to explicitly list every single class this module provides in
// that package to differentiate them from the classes provided by other
// modules. That can include private classes that are not part of the
// API.
split_packages: [
"android.app.usage",
"android.nearby",
"android.net",
"android.net.http",
"android.net.netstats",
"android.net.util",
],
// The following packages and all their subpackages currently only
// contain classes from this bootclasspath_fragment. Listing a package
// here won't prevent other bootclasspath modules from adding classes in
// any of those packages but it will prevent them from adding those
// classes into an API surface, e.g. public, system, etc.. Doing so will
// result in a build failure due to inconsistent flags.
package_prefixes: [
"android.nearby.aidl",
"android.net.apf",
"android.net.connectivity",
"android.net.http.apihelpers",
"android.net.netstats.provider",
"android.net.nsd",
"android.net.wear",
],
Enable tethering to perform its own hidden API processing Previously, the hidden API encoding of the tethering boot dex jars, i.e. those dex jars that tethering contributes to the bootclasspath were done as part of the monolithic hidden API processing. This change causes the encoding to be done by the tethering's bootclasspath_fragment. This change involves the following: * Addition of the fragments property to the tethering's bootclasspath_fragment module to list all the other bootclasspath_fragment modules on which this depends. * Addition of the additional_stubs property to add stubs for APIs that are not provided by another bootclasspath_fragment. * Moving hidden API flag file entries related to tethering from the flag files in frameworks/base/boot/hiddenapi directory into the tethering directory with an appropriate OWNERS file to allow them to be managed by the Soong and compat team. * Addition of a PREUPLOAD.cfg hook script to ensure that the flag files are sorted. The build automatically checks that the hidden API flags which are computed by tethering and encoded into its boot dex jars match those that are generated by the monolithic processing so this is guaranteed to be safe. Bug: 179354495 Test: m com.android.tethering - ensure that the generated APEX is byte-for-byte identical before and after these changes. m out/soong/hiddenapi/hiddenapi-flags.csv - make sure that they are not changed by this. Change-Id: I4d9621325c7fcea5043cbca4c577ba2ac6125c0c Ignore-AOSP-First: merge conflicts
2021-05-26 09:46:20 +00:00
},
}
systemserverclasspath_fragment {
name: "com.android.tethering-systemserverclasspath-fragment",
standalone_contents: ["service-connectivity"],
apex_available: ["com.android.tethering"],
}