Most of the fields in the bootImageConfig/Variant structs are assigned
inside a Once func so are guaranteed to be only set once. However, some
are assigned outside. This change adds comprehensive tests for those
structs and verifies that the constant fields are preserved and the
mutated fields have the correct value.
The check for the constant fields is added in a new TestBootImageConfig
test.
The check for the mutated fields is added into
TestSnapshotWithBootclasspathFragment_ImageName as that test checks an
art bootclasspath_fragment in the following configurations:
* source on its own
* prebuilt on its own
* source and prebuilt with source preferred
* source and prebuilt with prebuilt
It reveals a couple of interesting facts:
* All the *installs fields are set to the same value irrespective of
whether the source or prebuilt is preferred. The information is
constructed solely from information already within the
bootImageConfig/Variant and so can be moved within Once.
* The licenseMetadataFile is incorrect when prebuilt is preferred.
That is due to both the source and prebuilt modules setting it and
the source module always wins as the source module depends on the
prebuilt so always runs its GenerateAndroidBuildActions after it.
Those issues will be cleaned up in following changes.
Bug: 245956352
Test: m nothing
Change-Id: If917cfbcb3b1c842a8682d51cc1ee1fed1c51add
Sometimes it is necessary for some functionality to be disabled while
running in unit tests, e.g. functionality that requires external
information such as error prone tools and configuration. Sometimes it
is necessary for some functionality to be enabled while running in
unit tests, e.g. functionality that makes state available for
testing but which is not necessary at runtime.
Previously, that was done by checking to see if TestProductVariables
was nil. This change adds a method to abstract that.
Bug: 245956352
Test: m nothing
Change-Id: I7845b79328e7180623161a9bf897568089da4e4f
Previously, CommonOs was not added to Config.Targets for the test which
caused AndroidMk to crash when trying to determine if a target needed
the 2ND_ prefix added to some make variables.
Bug: 245956352
Test: m nothing
Change-Id: Ia815537ee5ce8e83df9a01c57250aa888453d138
Bug: 233660582
Test: Manually verified the lib and related flags are present when
coverage is enabled.
Change-Id: I7f03fbe56acd31016687751d10c73f2e92b2fa8c
* changes:
Move fuzzer's CollectAllSharedDependencies into GenerateAndroidBuildActions
Support AllowMissingDependencies in prebuilt_apex modules
Support AllowMissingDependencies for apex dependencies
Add AllowMissingDependencies support for prebuilt_etc module with no src property
Make OutputFileForModule work for AllowMissingDependencies
Fix panics when target arch is riscv64
Report missing output files as missing dependencies when
AllowMissingDependencies is enabled. This will fix
AllowMissingDependencies builds where a dependency module is
present but missing support for a specific architecture.
Bug: 250918230
Test: lunch aosp_riscv64-userdebug && m ALLOW_MISSING_DEPENDENCIES=true nothing
Test: TestOutputFileForModule
Change-Id: I95e96e3e7cb3df7bf678ed628b45baf659addbad
The module types in scope are
1. ndk_library
2. ndk_headers, versioned_ndk_headers
3. api_domain
These modules will no longer generate Bazel targets in bp2build
workspace. A new soong mode `api_bp2build` will be used to generate API
specific targets in a separate Bazel workspace at out/soong/api_bp2build
Test: go test ./bp2build
Change-Id: I01d06b6d8b8364c0d56d6d3f07f8f8bf21db31d7
The generated Bazel workspace will only contain api specific targets.
This is feasible since these targets do not have any cross dependencies
with the targets in the bp2build workspace
The advantages of a new mode are
1. Does not pollute bp2build workspace with api targets
2. Does not block api targets with the current allowlist conversion
mechansims in bp2build
(In the future we might want to combine these two workspaces)
A Soong module type will generate a Bazel target if it implements
ApiProvider interface
Test: m apigen
Test: m nothing
Change-Id: I69c57ca6539f932e0ad554ce84a87fb7936fdba0
Context
- Android-<target>.mk currently does not contain information about partition for its dependent unembedded jni libraries, but only lists the name of the unembedded jni libraries.
- If an android_app module depends on an unembedded jni library that is located in a different partition, make cannot find the library.
Implementation
- Create a string field partition in jniLib struct.
- Add variable "LOCAL_SOONG_JNI_LIBS_PARTITION_<target>", an array of mappings of the name of the jni library to its partition.
Bug: 154162945
Test: m
Change-Id: I6b8e1272ff59dc70e3dd6ce8c6c8e4686dad76df
Add barebones riscv64-linux-android support. This should be enough
to add riscv64-specific entries to Android.bp files, but can't
actually compile anything until there are riscv64 toolchains.
Test: arch_test.go
Change-Id: I0dcc7e797d9352dd38243be908a7f19004ff3db1
This makes mixed builds resilient to a recent backward-incompatbile
Bazel feature which explicitly adds the main repository (`@`) prefix to
all labels which are stringified by `str(target.label)` in Starlark.
This implementation is compatible with both current Bazel and
Bazel@HEAD.
After a new Bazel release to AOSP, we can clean up this code a little to
only support Bazel with this feature active (and that we need not hedge
on either Bazel behavior).
Bug: 248106697
Test: `m --bazel-mode nothing` with both current Bazel and a new Bazel
Change-Id: Id53c8505bb9080d5073c844de7f1ee57ceceae46
Previously, only the prefer property was copied from the
java_sdk_library_import module to its child modules which meant that if
the use_source_config_var property was used to control the prefer
property that the child modules would never be used. That can cause
build breakages when building against prebuilts as some parts of the
build will use prebuilt files from java_sdk_library_import and some
will use source files from the corresponding java_sdk_library.
This change copies the use_source_config_var property too.
It also adds tests to verify that dependencies on child modules of a
java_sdk_library use the prebuilt child modules of the corresponding
java_sdk_library_import. That revealed a bug with the handling of stub
sources where the prefer property was set after creating the module
which has also been fixed.
Bug: 249192297
Test: m nothing
# Cherry pick into branch broken by previous behavior and make
# sure that it fixes it.
Change-Id: I5719c257f8457bcb2238bc7965215512a20f1095
..except minadbd itself, which depends on 'adbd_system_api_recovery', a
phony module type that doesn't have a bp2build converter.
Test: bp2build.sh
Bug: 243025934
Change-Id: I48db09f8028a04089ed6fa6afac00007c3de4b31
Add it to the `CommonAttributes` struct and handle it in fillCommonBp2BuildModuleAttrs
Bug: 190817312
Test: treehugger
Change-Id: I7b21056e680384d4046372ee844512029721026e
bazel_path conversion would treat "./" as a package boundary
which would be incorrect
Bug: b/243072036
Test: unit test build_conversion_test.go and `m libc`
Change-Id: I0fc44d2fd7a4270442c8755219a11fd585244c5c
Fields tagged with `sdk:"keep"` will keep the value even if it would
normally be cleared because it was common across a number of structs.
This will allow a module type to specify the same value across all
structs populated directly from variants and have it be copied into all
common property structs without clearing it from the variant specific
structs.
Bug: 248258460
Test: m nothing
Change-Id: I147d946b11fd8766a7d875d9206e8f5034f585d6
"ignore" is a better description of the effect that this tag has on the
optimization that is done as part of the sdk snapshot generation.
"keep" implies that something special is done with the field during the
optimization process but actually the optimization process completely
ignores the property, just as it does with unexported fields.
Bug: 248258460
Test: m nothing
Change-Id: Idfdfd87f927d641d4d301cbbde72b463c89155bf
Add a filter for cyclic references in required module names in bp2build.
Test: CI
Bug: 247985196
Bug: 225291837
Fixes: 234748998
Change-Id: Id1cfd0b2e5f217cdb01218ec3bbe11d5070cc9df
This is an improvement over directly referencing the prebuilt because
bp2build can now emit BUILD files that contain a dep to
//build/soong/zip/cmd:soong_zip even though we're not converting the
soong_zip module.
It helps to make progress despite not having go rules support to
convert/build soong_zip. This unblocks many modules, like genrules and
gensrcs that use soong_zip in tools. soong_zip doesn't change often, so
it's not risky to depend on the prebuilt instead of source version.
Bug: 194644518
Bug: 248222296
Test: bp2build CI
Change-Id: Idef0c27ec0fb43a9097d750ec72fba00644c9f2a
For directories without an Android.bp file, if they contain a merged
checked in BUILD file, it becomes a package boundary in the symlink
forest. However, the current glob expansion is only aware of Android.bp
files, but not merged BUILD files, so it generates glob expansions
incorrectly for files that cross the package boundary.
This CL fixes that by making the package boundary function aware of the
keepExistingBuildFile allowlist. See the new test cases for example.
Also stop using the same global bp2buildConfig for every test case to
allow each test to define their own bp2build allowlists.
Bug: 185358476
Test: new unit tests
Change-Id: Ifcd1283480a09a642ef4343e5bbc599583524577
