When the passed release name is an alias, write
release_config-PRODUCT-RELEASE.mk using the alias, since that is where
core/release_config.mk is going to look for it.
Bug: 328495189
Test: manual
Change-Id: I4e6909f43bf136974323754e06fa538e39e0faab
Non-transition mutators that don't create a variant for a given module
cause no change to DebugMutator and DebugVariation. TransitionMutators
don't have a concept of skipping a module, so Mutate is called on
every module. This causes extra entries in DebugMutator and DebugVariation,
which will confuse error message around missing variations, and require
updating variant strings in some tests.
Skip updating DebugMutator and DebugVariation for empty transition
mutator variations. This isn't entirely correct, but transition mutators
don't currently have a concept of an unaffected module.
Bug: 319288033
Test: all soong tests pass
Flag: NONE
Change-Id: Ia4e659b1e90ffe4320074c9b49528d00fa302c6a
Update docs for ReplaceDependencies[If] to match changes in blueprint.
Bug: 319288033
Flag: NONE
Test: all soong tests pass
Change-Id: I7c79d3ac8dd80946760eb89b6577dc9965cb1541
Change https://r.android.com/3068903 adds some extra
`android-plus-updatable.jar` files in `module-lib` and `system-server`
directories of API versions 30 through 34 in `prebuilts/sdk`. This
change modifies the build to pass those files, along with appropriate
`--android-jar-pattern` options to Metalava so it can use them when
generating `api-versions.xml` files for the different API surfaces.
The extra patterns are only passed when `extension_info_file` is
specified as there is no point in including the updatable modules that
contribute to SDK extensions without providing information about the
SDK extensions as well.
Bug: 337836752
Test: See https://r.android.com/3068903
Change-Id: I439179a9d35a4bb677e3bf87a3aea4a983724534
Restructures the code a little to make it clear that extensions
directories are distinct from dessert release directories.
Bug: 337836752
Test: m --no-skip-soong-tests nothing
Change-Id: I8ad68f0d112e62f8f1ddda1b6718119fe18eb8a9
If build_logtags is set to true, etc/event-log-tags will be built by
collecting all logtags files from all dependencies.
Note that this is different from Makefile's current behavior that
collects all logtags files, including ones from uninstalled modules. But
the behavior is probably unintended, and ideally each partition image
should have its own logtags, rather than putting all tags to /system.
Bug: 336189540
Test: m aosp_cf_system_x86_64
Change-Id: I72b384cbb65e812af909eacd18799bd86f1dab13
The apex tests sometimes hit the default 10 minute timeout when running
with the race detector enabled in the aosp-build-tools builds.
Test: treehugger
Flag: NONE
Change-Id: I6092a0c68c3b79cd24cdd4a6a8614f7eced7dc1a
Disallow setting the flag via protobuf files, and adjust it internally
to be more like any other build flag. This makes the generated output
more consistent.
Also default to TARGET_RELEASE if no release is given to `build-flag`.
Bug: 328495189
Test: manual
Change-Id: I9db57137fc4e5ed42a38adc939c430826afe4f63
If false, then we output an empty file, which will cause
release_config.mk to do the old process.
Bug: 328495189
Test: manual
Change-Id: I4aa82301f3bbb29633a275a801431a6667feb48d
This was already done for target.recovery, but was forgotten for
target.vendor and target.product.
Test: add exclude_header_libs to a target with export_header_lib_headers and build successfully
Tags:
Change-Id: Ib206f54b2176830e32af33b9b093b71d4f1351ac
Signed-off-by: Abhishek Gadewar <abhishekgadewar@meta.com>
This adds a cfg flag `android_platform` which can be used
to indicate there's some conditional compilation need specific to
AOSP.
Test: New flag is emitted on builds
Change-Id: I833a7d68db2dad7ab2d32a5eb51d764f0d66b849
So far, we have used `instalable: false` to avoid collision with the
other modules that are installed to the same path. A typical example was
<foo> and <foo>.microdroid. The latter is a modified version of the
former for the inclusion of the microdroid image. They however both have
the same instalation path (ex: system/bin) and stem (ex: foo) so that we
can reference them using the same path regardless of whether we are in
Android or microdroid.
However, the use of `installable: false` for the purpose is actually
incorrect, because `installable: false` also means, obviously, "this
module shouldn't be installed". The only reason this incorrect way has
worked is simply because packaging modules (ex: android_filesystem)
didn't respect the property when gathering the modules.
As packaging modules are now fixed to respect `installable: false`, we
need a correct way of avoiding the collision. `no_full_install: true` is
it.
If a module has this property set to true, it is never installed to the
full instal path like out/target/product/<partition>/... It can be
installed only via packaging modules.
Bug: 338160898
Test: m
Change-Id: Iee9be674951d0bf3d5e26432fcbae9afebb6007b
When switching from an initially found host module to a later found
device module, we passed `cInfo.Deps` through. This actually suppresses
addition of some modules, which was not the intention.
Bug: 336695421
Test: SOONG_GEN_RUST_PROJECT=1 m blueprint_tests
Test: check rust-projects.json manually afterwards for deps
Change-Id: Ib90f9c755e07f88e85a3b3cbd9bc698cce8af038
- Allow scl and textproto data to coexist for now
- Print warnings to stderr instead of stdout.
- Improve formatting of output
- Set displays the new value for all configs, and what file changed.
- Use prettier error messages for better UX
- put build-flag on the path.
Bug: 328495189
Test: manual
Change-Id: I4c38860c2fb24db5111e0cecf790660a4ff2b8b2
Release configs with `aconfig_flags_only: true` can inherit build flag
values, but cannot set them.
Bug: 328495189
Test: manual
Change-Id: I2bdc88761d61fb20f10dc734f2ba87114f51b859
With this change, filesystem modules (android_filesystem,
android_system_image, etc.) follow the installation semantic which means
output from modules which don't produce installable files (i.e. modules
that return false on IsSkipInstall()) are not included in the filesystem
module.
Note that this bug has been there since the beginning but didn't trigger
an error due to another bug (b/335506668) which allowed multiple
packaging specs to contribute to the same path. That bug prevented the
non-installable variant of a module (e.g. stub) from being installed
simply because because it was "luckly" clobbered by the installable
variant of the same module (e.g. impl lib).
Bug: 335506668
Test: go test ./...
Change-Id: I2a42d178701d74bf6ccc5f33ba33918f8c608d40
This fixes a bug that different PackagingSpecs having the same
installation path were silently allowed. Previously, a PackagingSpec
that comes the first for the given installation path won, effectively
eclipsing other PackagingSpecs destined for the same installation path.
Bug: 335506668
Test: go test ./...
Change-Id: Ia36f656e8364f95c4be78fff6e9dc16966307526
I misunderstood our desire to eventually migrate all
`test_module_config` modules -> "general-tests" for the requirement that
it must be used now.
While working on converting these modules to use symlinks rather than
copies of data files, I noticed a problem if the derived test was in
"general-tests", but the base test was in "device-tests". The symlink
would not have a base to point to in general-tests.zip.
Allow the derived tests to be in other suites for now.
Test: go test ./tradefed_modules/
Test: m blueprint_tests
Change-Id: I9524d6c3964db6de38fc3c4cb4c5bc493dadc0db
