rbc_dashboard.py is an alternative implementation of
rbc_regression_test.sh. These tests both run soong 2 times with
starlark product config enabled/disabled and diff the resulting ninja
files. However, the shell script test runs the soong invications in
series and the python one runs them in parallel, meaning the python
one is faster. On my computer the shell one takes ~7 minutes and the
python one takes ~4 minutes.
Bug: 291548757
Test: Presubmits
Change-Id: I20fd6ca09f47dd0547f2681fbd78ba70991493b0
The only difference between preprocessed + presigned vs just presigned
is that just presigned will zip align the apk, and preprocessed +
presigned will instead check that the apk is already aligned and has
uncompressed jni and dex libs. This should be the default to ensure
we're getting valid apk imports from external sources.
Presigned alone also won't work for apps with target sdk >= 30, because
on those target sdks you have to use apk signature v2, and having the
build system align the zip file will break that signature.
Bug: 185811447
Test: Presubmits
Change-Id: Ie825ab2eab4feeda5c266233a9dca7bbf9559be7
Instead of rolling assets and manifests up through each static lib,
provide them as a DepSet. This will help with the next patch, which
needs to pass all the transitive manifests and R.txt files together.
This relands Id8b3aa2bed3771e82ab6bde192c9b43baa38b54c with a fix
to include additional manifests from dependencies in the final
manifest merger.
Test: app_test.go
Test: TestManifestMerger
Change-Id: Ied0a6cfee2f18e87188db145b9411d4a903ab6c9
Add a test for the manifest merger command line that would have prevented
b/291252863.
Bug: 291252863
Test: TestManifestMerger
Change-Id: I8c025efe7ccb06ad97b405e2927a4df07f9d3f27
Regarding aosp/2624311, `blkid_path` was removed from the command, so the number of parameters should be reduced by 1.
Test: MODULE_BUILD_FROM_SOURCE=false m (in internal-main branch)
Bug: 279858383
Change-Id: Iad494b757e2a4152a6867098c3eb7419c3bba71b
* changes:
Add a Make variable to determine ART boot image jars for testing.
Add a Make variable that overrides configured jar locations.
Refactor dexpreopt for boot jars to make it flexible to config changes.
We had hardcoded logic to override "framework-minus-apex", but we need
to override more jars, so this CL adds a general solution for this.
Bug: 290583827
Test: m nothing
Change-Id: I211ebda7aa2803886ab6e6d081d26327665e49a6
In the past, dexpreopt for boot jars was very inflexible, and it was
incredibly hard to make a change that is as simple as adding a jar to a
boot image. Boot image generation was handled by
"platform_bootclasspath" and "bootclasspath_fragment" separately. This
caused not only code duplication but also the inflexiblity as such a
design did not fit today's use cases, where a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. The design casued a huge
maintenance burden as any change to the boot image cost multi-week
efforts.
In recent years, efforts have been made to improve this a bit by a bit.
This change is another step towards making dexpreopt reasonable.
After this change, all boot images are generated by "dex_bootjars",
which is in build/soong and is therefore available on both the full
source tree and the thin manifest (master-art). The change decouples
profile generation/extraction from boot image generation. Profiles for
mainline modules are still handled by "bootclasspath_fragment"
because they need to be packed into APEXes when building mainline
modules and extracted from APEXes whem building the system image from
prebuilt modules. Boot images are not handled by
"bootclasspath_fragment" anymore.
Bug: 290583827
Test: m (all existing tests are still passing)
Test: Manually checked that the boot images are exactly the same as
before.
Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
This reverts commit bce5507c02.
The update of LLVM to clang-r498229 resolved the error with sext.w as
resolved in D143594.
Bug: 275574215
Test: Verified boot of riscv64 phone target.
Change-Id: Ie31b7db03004c5aafb6067713ef5f819e0706b64
Fixes the error
```
fmt.Errorf call has arguments but no formatting directives
```
Test: go test ./android
Change-Id: Ic589d6133ccdc88e77dedd4b8a5a56166f62efa9
We want to measure how much of build time is spent on writing large
zips to disk. We can do this by doing the rest of the work but
skipping the write itself.
Some local and trivial testing shows this is probably a lot of the
cost of these rules:
$ python -m timeit -s "import os" -r 10 "os.system('soong_zip -write_if_changed -o foo.zip -D prebuilts/sdk')"
1 loop, best of 10: 8.37 sec per loop
$ python -m timeit -s "import os" -r 10 "os.system('soong_zip -o foo.zip -D prebuilts/sdk')"
1 loop, best of 10: 5.39 sec per loop
$ python -m timeit -s "import os" -r 10 "os.system('soong_zip -n -o foo.zip -D prebuilts/sdk')"
1 loop, best of 10: 3.66 sec per loop
Bug: None
Test: treehugger
Change-Id: I43acdb08d0e00efaba9e5d7add972a7ec41646d2
product SBOM of cuttlefish devices, ignore these diffs for now in the
SBOM integration test to fix the CI breakage.
Bug: 291073898
Test: build/soong/tests/sbom_test.sh
Change-Id: Idf5569f67642784ee422847301c59dddc8ff0907
* changes:
Respect package boundaries in bp2build conversion of go modules
Create a temporary denylist for go binaries used in mixed builds
Partial bp2build conversion of blueprint_go_binary
Partial bp2build conversion of bootstratp_go_package
A heuristics is implemented in the build/bazel/scripts/bp2build_progress/bp2build_progress.py script to determine the reason for why a module is not converted.
Test: b build //build/bazel/scripts/bp2build_progress:bp2build_progress
Change-Id: I9d4eaf309dbf26bbb6de18e1af0d9cdc8fe09e94
In preparation for adding the ability to check all genrules in the tree.
Bug: 290816499
Test: ./build/soong/tests/genrule_sandbox_test.py extensions_db.pb
Change-Id: I6454be7e88a876a2ab1105c04f5ecda03ecd7771
bp2build's codegen context does not implement
BazelPathConversionContext. To reuse the utility function
transformPackagePaths, update its signature
(Also make deps of go_library unique to make the conversion resilient)
Test: go test ./bp2build
Change-Id: I126b1057d2b26bc6c7d3be2780f1b62d28323cf0
This allows us to rollout building _some_ go targets using rules_go
without affecting mixed builds.
Test: Presubmit
Bug: 284483729
Change-Id: I0ccb4c9b90614369147a380f44f7ae372ef9396e
The Java compiler may generate sources when processing annotations.
These sources are currently not included in the IDE project model, which
results in unresolved symbols when using Hilt and other annotation
processors. These sources are not passed to the Java compiler for
compilation, so they cannot be handled like other Java module sources.
This change archives the generated sources and appends them to the
existing srcjar list in module_bp_java_deps.json.
Test: go test .
Test: Verified that module_bp_java_deps.json contained srcjar entry
Test: with path/to/android_common/javac/anno.srcjar.
Test: Verified that IntelliJ can resolve generated symbols after
Test: invoking aidegen.
Change-Id: I6a3011f9140fd25f785178baee0cd6074ad94600
metalava no longer prints an ASCII banner, and has removed its
--no-banner argument. Update all call sites accordingly.
Test: presubmit
Bug: 286023667
Change-Id: I61cf5f1125dfbd93496e6a59eb1ea62886b32046
This module type does not implement android.Module, and therefore we
cannot write a conventional bp2build converter for this module type.
Instead this has been special-cased inside bp2build/build_conversion.go.
There is one major deviation between Soong and Bazel's
go_binary/go_library. Soong
collects the deps in the transitve closure and puts them on compile/link
paths. Bazel OTOH, requires the direct imports to be listed in deps of the binary
explicitly (AFAIK). Since bp2build cannot determine the list of direct
imports from the list of transitive deps, put all the transitive deps in
`deps`
Test: unit tests
Test: TH
Bug: 284483729
Change-Id: I004aaf8607fef1697a0d9e7d018ad657b67778ac
This module type does not implement android.Module, and therefore we
cannot write a conventional bp2build converter for this module type.
Instead this has been special-cased inside bp2build/build_conversion.go.
Because of the above, we also do not have access to useful functions
available in the ctx object of ConvertWithBp2build. This includes
1. Finding the package (directory) of a dep. This requires getting a
handle of the underlying module from its name (string). To solve, we
do a pre-visit to collect this information. This did not increase the
wall time. On my machine, `m bp2build --skip-soong-tests` takes ~14s
before and after this CL
2. Converting srcs to labels. This requires glob and package boundary
resolution. This CL introduces a partial implementation for this
function. (glob patterns are not used in go tools)
For (1), I considered creating a `ModuleFromName` on
`blueprint.Context` instead of a pre-run, but this increased the time to ~27s.
Test: unit tests
Test: TH
Bug: 284483729
Change-Id: Ifeb029103d14947352556dba295591dd7038b090
