After this change, if profile-guided compilation is enabled for an APEX
system server jar, the profile will be installed next to the jar with
the ".prof" suffix, ("javalib/<name>.jar.prof"). This file will later be
used by odrefresh and dexpreopt from prebuilt APEX.
Bug: 241823638
Test: m nothing
Test: -
1. Patch ag/20581649 PS2.
2. banchan com.android.btservices x86_64 && m
3. Check that "javalib/service-bluetooth.jar.prof" exists in the APEX.
Change-Id: Ibcfc6257dade92bd40a6d4b7368148717d0863b9
apex_name was used to install symbol files under /apex/<apex name>,
which caused duplicate rules when there's two apexes with the same
apex_name. (e.g. override_apex or multi-install apexes)
Since symbol files can be looked up via ELF Build-Id, we don't have to
install symbol files with the actual "apex name", but instead we can
install them with soong module name.
Bug: 267581665
Test: m (soong test)
Change-Id: I1cbe5c86d287f180c7deef93ba85ea5552680011
Ideally we'd stop ignoring warnings entirely, but this helps de-risk
optimized targets that may be more sensitive to side effects from
suppressing such warnings.
Test: m
Bug: 215530220
Change-Id: Iccd124a347d55cd8f9474ebca7e41eca27882066
This is not the correct bug link. It should be removed when enabling
-Wxor-used-as-pow in external. See: aosp/2356123
Bug: None
Test: None
Change-Id: I6bc1d35e07ed11fc0c70a625b0035348a6428678
Previously in mixed builds, only the tidy files for the boundary module
were built, whereas all of its transitive dependencies' tidy files were
not being built. Instead we should export the list of transitive tidy
files for a module so that we can run clang-tidy for the boundary module
as well as its dependencies.
Bug: 195029134
Test: WITH_TIDY=1 DISABLE_ARTIFACT_PATH_REQUIREMENTS=true mss tidy-packages-modules-NeuralNetworks --bazel-mode-dev
Change-Id: I463646d2ae1fc4aa075a54c264e1c34571c3fd5c
This test confirms the behavior when LTO is disabled generally but
then enabled for a specific target.
Bug: 261733821
Test: Unit test
Change-Id: I415cd0146f2b83d85654239550d129f87e9001bc
Currently, droidstubs module create java_api_contribution module, but
when a java_sdk_library module dynamically creates a droidstubs module,
java_api_contribution is not created as the hook inside droidstubs get
lost. Therefore, call hook inside sdk_library after creating the
droidstubs module.
Test: m
Change-Id: I68bf1d796f6f9a6f81011ae35e4991b6ed1421ea
Pass -C panic=abort to rustc when targeting linux bionic to match
device bionic builds. Fixes building on master-art-host when a
rust dependency is added to the linux bionic target.
Bug: 268035710
Test: master-art-host linux bionic build
Change-Id: I411a8622002709030dfd207b9decb8846a1ccef3
Perform a single pass over pathComponents in both validatePath and
validateSafePath instead.
Test: presubmits
Change-Id: I1499183e345ca180900c54a18f9dc8bd534f2588
Previously, symlink forest generation involved removing the entire
symlink forest and recreating it from scratch. With this change,
a) symlinks which need not change are untouched,
b) symlinks pointing to the wrong location are fixed, and
c) symlinks which should no longer exist are removed.
On AOSP on my local machine, this reduces the symlink forest generation
step from 2.5s to 1.1s clean, and 0.6s when a single file is added to
a source directory.
Bug: 257528847
Test: m bp2build, touch `fakefile` under the forest, remove a file
from the source tree, rerun m bp2build. Manually verify the new forest
does not retain the link to the deleted source file, and that fakefile
no longer exists in the forest.
Change-Id: I481371ae487e9419af6a3a4370c552578b07d650
This has been a workaround to avoid duplicate build rules for
multi-install apexes. The reason for duplicate errors was that apex_name
was used to install symbol files.
We don't need to rely on apex_name for symbol files, hence no need for
the workaround.
Note that symbol files for apexes are still available via the paths
based on "soong module name".
Bug: 267581665
Test: cuttlefish (which uses multi-apex) build & run
Change-Id: Icaca667e139ef2aca32339a75b54b12a00449c2d
VNDK APEX has been using "apex_name" property to set "name" field in
apex_manifest. But setting apex_name had a side-effect of emitting
duplicate rules for symbol files for VNDK APEX and its override_apex.
(Please see the removed comments for more details about error)
Not using "apex_name" fixes the duplicate errors.
There're a few more vendor apexes with the same issue, which I will
handle in follow-ups.
Bug: 267581665
Test: m (soong test) && boot
Change-Id: I00f617cef8af4d21880d4e8b9c0b9ab9322ba15c
Revert submission 2421642-rust-update-prebuilts-1.66.1
Reason for revert: Missing riscv support and out of date base64 crate causing brekages
Reverted changes: /q/submissionid:2421642-rust-update-prebuilts-1.66.1
Change-Id: I6c0d6c3539e766012570e4542f529706fe49928c
Previously, Bazel was invoked during mixed builds with a stripped down
environment. This CL adds an allowlist of environment variables that are
passed to Bazel.
Test: WITH_TIDY=1 DISABLE_ARTIFACT_PATH_REQUIREMENTS=true mss tidy-packages-modules-NeuralNetworks --bazel-mode-dev
Change-Id: I23147bec59f6522953cf623e7bcaa0f1f99a75a3
Fix an issue where rust_fuzz modules were
not correctly packaging and copying their
dependencies.
This is done by extending the CC fuzz packager
to simply handle both Rust and CC modules,
ensuring this doesn't get out of sync again.
Fuzzer related functions are added to the
Linkable interface to facilitate this.
There was a bug where the Make definitions for
Rust fuzzers were not being created as well,
and that is addressed here.
Bug: 249551848
Test: m android_log_fuzzer #check $OUT/data/fuzz/arm64/libs
Change-Id: I9b41153e0cf08ab510476b75003c3a3baccc3858
Since fe4ff29b4d47fa8ae242fb7e084215d3afada4b5 (in system/apex), apexer
doesn't check keyname (--key vs --manifest.name). So, passing
--do_not_check_keyname doesn't make any sense.
This is a preparation to remove (or deprecate) "apex_name" property from
"apex" module.
Bug: 267581665
Test: m
Change-Id: I3737d1e36d305375a523a23a6bbeb2d23586e578
parent modules' visibility
By default, dynamically created module inherits the parent module's
visibility. When the parent module's visibility is set to
"//visibility:private" or has any other specified visibility
restrictions in the module definition, the created
java_api_contribution module is not visible to java_api_library.
Thus, override any inherited visibility properties and set the visiblity
of the created java_api_contribution module to public.
Test: m
Change-Id: I5db60a5a1800e2ae28c9650eeb9a2f1c3b4f8989
This also fixes determinism of these files (by ensuring that bazel
requests and their configurations are sorted, as these are used in the
soong_injection file output)
Bug: 266983462
Test: Manually verified soong_injection files are the same among
multiple runs
Test: Unit test
Test: m nothing
Change-Id: I1568930549cff0bc5676825434cc448d16ebdd4e
