platform_build_soong/android/Android.bp

120 lines
2.9 KiB
Text
Raw Normal View History

Add LOCAL_LICENSE_KINDS to build/soong Added SPDX-license-identifier-Apache-2.0 to: Android.bp android/Android.bp android/soongconfig/Android.bp androidmk/Android.bp apex/Android.bp bazel/Android.bp bp2build/Android.bp bpf/Android.bp bpfix/Android.bp cc/Android.bp cc/config/Android.bp cc/libbuildversion/Android.bp cc/libbuildversion/tests/Android.bp cc/ndk_api_coverage_parser/Android.bp cc/ndkstubgen/Android.bp cc/symbolfile/Android.bp cmd/dep_fixer/Android.bp cmd/diff_target_files/Android.bp cmd/extract_apks/Android.bp cmd/extract_jar_packages/Android.bp cmd/extract_linker/Android.bp cmd/fileslist/Android.bp cmd/host_bionic_inject/Android.bp cmd/javac_wrapper/Android.bp cmd/merge_zips/Android.bp cmd/multiproduct_kati/Android.bp cmd/path_interposer/Android.bp cmd/pom2bp/Android.bp cmd/pom2mk/Android.bp cmd/sbox/Android.bp cmd/soong_build/Android.bp cmd/soong_env/Android.bp cmd/soong_ui/Android.bp cmd/zip2zip/Android.bp cmd/zipsync/Android.bp cuj/Android.bp dexpreopt/Android.bp dexpreopt/dexpreopt_gen/Android.bp env/Android.bp etc/Android.bp filesystem/Android.bp finder/Android.bp finder/cmd/Android.bp genrule/Android.bp jar/Android.bp java/Android.bp java/config/Android.bp kernel/Android.bp linkerconfig/Android.bp linkerconfig/proto/Android.bp makedeps/Android.bp partner/Android.bp phony/Android.bp python/Android.bp python/tests/Android.bp remoteexec/Android.bp rust/Android.bp rust/config/Android.bp scripts/Android.bp sdk/Android.bp sh/Android.bp shared/Android.bp symbol_inject/Android.bp symbol_inject/cmd/Android.bp sysprop/Android.bp tradefed/Android.bp ui/build/Android.bp ui/logger/Android.bp ui/metrics/Android.bp ui/metrics/proc/Android.bp ui/status/Android.bp ui/terminal/Android.bp ui/tracer/Android.bp xml/Android.bp zip/Android.bp zip/cmd/Android.bp Added SPDX-license-identifier-Apache-2.0 SPDX-license-identifier-BSD to: finder/fs/Android.bp third_party/zip/Android.bp Bug: 68860345 Bug: 151177513 Bug: 151953481 Test: m all Exempt-From-Owner-Approval: janitorial work Change-Id: Ia47ca14f16b8c9f84f9d533a07e5b00e2c04e8d4
2021-02-04 03:08:28 +01:00
package {
default_applicable_licenses: ["Android-Apache-2.0"],
}
bootstrap_go_package {
name: "soong-android",
pkgPath: "android/soong/android",
deps: [
"blueprint",
"blueprint-bootstrap",
"sbox_proto",
"soong",
"soong-android-soongconfig",
"soong-bazel",
"soong-cquery",
"soong-remoteexec",
"soong-response",
"soong-shared",
"soong-ui-metrics_proto",
"golang-protobuf-proto",
"golang-protobuf-encoding-prototext",
],
srcs: [
"androidmk.go",
"apex.go",
"api_levels.go",
"arch.go",
"arch_list.go",
"bazel.go",
"bazel_handler.go",
"bazel_paths.go",
"config.go",
"csuite_config.go",
Export dex implementation jars from prebuilt_apex Dexpreopt and boot jars package check all require access to dex implementation jars created for java_library and java_sdk_library. They were available when building from source but not when building from prebuilts, even though they are embedded within the .apex files that are referenced from prebuilt_apex. This changes adds support to prebuilt_apex to export the dex implementation jars and updates java_import to use those exported dex implementation jars. In a source build dexpreopt/boot jars package check access the apex (or platform) specific variant of a java_library, e.g. core-oj, from which it retrieves the dex implementation jar path. After this change in a prebuilt build dexpreopt/boot jars package check behave in the same way except in this case they retrieve the dex implementation jar path from the apex (or platform) specific variant of the java_import, e.g. core-oj. The work to export files from a `.apex` file for use by other modules is performed by a new `deapexer` module type. It is not used directly in an `Android.bp` file but instead is created implicitly by `prebuilt_apex`, In order to do that this contains the following changes: * Adds a new `dexapexer` module type to handle the exporting of files from the `.apex` file. * Adds an exported_java_libs property to prebuilt_apex to specify the set of libraries whose dex implementation jars need exporting. * Creates apex specific variants of the libraries listed in the exported_java_libs property. * Adds the set of exported files to the ApexInfo to make them available to the apex specific variants. * Prevents the prebuilt_apex variants from being merged together as they will not be compatible. * Modifies java_import to use the exported file for variants of a prebuilt_apex. * Adds a ninja rule to unpack (using deapexer) the contents of the prebuilt_apex's apex file, verify that the required files are present and make them available as outputs for other rules to use. * Some minor refactorings to support these changes. * Adds tests to cover prebuilt only, prebuilt with source preferred, and prebuilt preferred with source. Test: m nothing Bug: 171061220 Change-Id: Ic9bed81fb65b92f0d59f64c0bce168a9ed44cfac
2020-11-02 18:32:38 +01:00
"deapexer.go",
"defaults.go",
"defs.go",
"depset_generic.go",
"depset_paths.go",
"deptag.go",
"expand.go",
"filegroup.go",
"fixture.go",
"hooks.go",
"image.go",
"license.go",
"license_kind.go",
"license_sdk_member.go",
"licenses.go",
"makefile_goal.go",
"makevars.go",
"metrics.go",
"module.go",
"mutator.go",
"namespace.go",
"neverallow.go",
"ninja_deps.go",
"notices.go",
"onceper.go",
"override_module.go",
"package.go",
"package_ctx.go",
add PackagingSpec Currently, installation of a module is defined as an action of copying the built artifact of the module to an install path like out/soong/host (for host modules) and out/target/product/<device>/<partition> (for device modules). After the modules are installed, the installed files are further processed to create packages like system.img, vendor.img, cvd-host-package.tar.gz, etc. This notion of installation seems to have originated from the old time when system.img is the primary product of the entire build process (modulo a few more like root.img). Packaging the installed files as the filesystem image was considered as a post-build step then. However, this model doesn't seem to fit well to the current and future environment where we have a lot more filesystem images (system, vendor, system_ext, product, ...). The filesystem images themselves are even grouped together to form a higher-level filesystem image like super.img. Furthermore, things like cvd-host-package.tar.gz requires us to be able to group some of the host tools in a format that isn't filesystem image. Lastly, we are expected to have more filesystem images that are subsets of system.img (and their friends) for the Android-like mini OS that will be running on on-device virtual machines. These all imply that the packaging (which we call installation today) is not a global post-build step, but a part of the build rules for creating the package-like modules. A model better fits to the new sitatuation might be this; a module specifies its built artifact and the path where it should be placed. The latter path is not rooted at out/. It's a relative path to the root directory which will be determined by another module that implements the packaging. For example, cc_library will have ./lib (or ./lib64), not out/target/product/<device>/<partition>/lib as the path. Then packages like system.img, cvd-host-package.tar.gz, etc. are explicitly modeled as modules and they have deps to other modules. Then the modules are placed at the relative path under the package root, and the entire root directory finally is packaged as the output file (be it img, tar.gz, or whatever). PackagingSpec is the first step to implement the new model. It abstracts a request to place a built artifact at a certain path in a package. It has extra information about whether the path should be a symlink or not, and whether the path is for an executable. It currently is created when InstallFiles (and its friends) are called, and can be retrieved via the new method PackagingSpecs(). In this CL, no one is using PackagingSpec. The installation is still done by the existing rules created in InstallFiles, etc. and the structs are not used for the filesystem images like system.img. Bug: 159685774 Bug: 172414391 Test: m Change-Id: Ie1dec72d1ac14382fc3b74e5c850472e9320d6a3
2020-11-09 06:08:34 +01:00
"packaging.go",
"path_properties.go",
"paths.go",
"phony.go",
"prebuilt.go",
"prebuilt_build_tool.go",
"proto.go",
"register.go",
"rule_builder.go",
"sandbox.go",
"sdk.go",
"sdk_version.go",
"singleton.go",
"singleton_module.go",
"soong_config_modules.go",
"test_asserts.go",
"test_suites.go",
"testing.go",
"util.go",
"variable.go",
"visibility.go",
],
testSrcs: [
"android_test.go",
"androidmk_test.go",
"apex_test.go",
"arch_test.go",
"bazel_handler_test.go",
"bazel_test.go",
"config_test.go",
"csuite_config_test.go",
"defaults_test.go",
"depset_test.go",
"deptag_test.go",
"expand_test.go",
"fixture_test.go",
"license_kind_test.go",
"license_test.go",
"licenses_test.go",
"module_test.go",
"mutator_test.go",
"namespace_test.go",
"neverallow_test.go",
"ninja_deps_test.go",
"onceper_test.go",
"package_test.go",
"packaging_test.go",
"path_properties_test.go",
"paths_test.go",
"prebuilt_test.go",
"rule_builder_test.go",
"singleton_module_test.go",
"soong_config_modules_test.go",
"util_test.go",
"variable_test.go",
"visibility_test.go",
],
}