Currently, there is little verification around allowlisted modules
actually being mixed-built. This flag would allow us to verify
that a module allowlisted is mixed-built for at least one variant.
Bug: 278910100
Test: m nothing --bazel-mode-staging --ensure-allowlist-integrity
Test: m nothing --bazel-mode-staging --ensure-allowlist-integrity
--bazel-force-enabled-modules=com.google.android.neuralnetworks (This
fails, as expected)
Test: build/soong/test/mixed_mode_test.sh
Change-Id: Icd5976f4f44f1a8caca1e5247d986642f7995f97
Environment variables HWASAN_INCLUDE_PATHS and
PRODUCT_HWASAN_INCLUDE_PATHS can be used to enable HWASan for multiple
modules, by just adding the module directory to the env variable.
Bug: b/271948407
Test: Set specific module directory to above env variable and check the
assembly codes of output elf files after building, finding hwasan
related symbols inside.
Change-Id: Ic49b515830c4469ca5fa94f547b26c0fb602fc54
We don't want rules to load the product variables directly, because
then they won't be able to transition on them.
Break constant information that is safe to load outside of the
product vars file, so that we can make the product vars file have
more restricted visibility later.
Bug: 269577299
Test: m nothing
Change-Id: I848bff33e4f5798f51296ea3a2600615cab36985
Introducing fdo_profile module type to reimplement the afdo support in cc moduels. This change allows the feature to be compatible with Bazel migration.
How it works:
PreDepsMutators:
* BeginMutator: If non-static cc modules sets afdo prop, search and add corresponding fdo_profile module as a dep with fdoProfileTag
* fdoProfileMutator:
* If in fdo_profile module, set FdoProfileProvider with full path to profile
* If in cc module, read FdoProfileProvider from dep with fdoProfileTag and set FdoProfileInfo.Path to FdoProfilePath field
PostDepsMutators:
* afdoDepsMutator: If a module has FdoProfilePath set, walk to its static deps and set itself to the deps' AfdoRdeps
* afdoMutator: If a static dep has AfdoRDeps set, create afdo variant.
Ignore-AOSP-First: Other CLs in the same topic are internal-only
Test: go test
Bug: b/267229065
Change-Id: I687d798a02d9743c92804fea36fb4ae3a7a0e5e3
Merged-In: I687d798a02d9743c92804fea36fb4ae3a7a0e5e3
Context
- from-text android.jar files are built using Metalava, and these can be
utilized in `decodeSdkDep` so that any modules that depends on APIs
can be compiled using from-text android.jars
- This change removes dependency on source java files when compiling
stub android.jar files
Implementation
- Modify java_api_library module to create system modules using the
generated android.jar
- Replace modules in decodeSdkDep to link against java_api_library
modules
- Add --build-from-text-stub flag to hide the feature behind a flag
Test: m --build-from-text-stub
Bug: 271154441
Change-Id: I104df595edc65c0006820d5ae5b15f1fb167e190
When the branch is configured as something less than the max codename
(for example, right now AOSP is U but V is also in development), the
active codenames list will not include V.
Bug: None
Test: None
Change-Id: Ia22388a8ba94ff00d053acb33363c3cdce7677d0
Soong analyzes the entire source tree even though not every lunch target
needs to know about every module. For example, OEM sources can be
ignored for cuttlefish products. This functionality allows blueprint to
ignore a list of undesired directories.
Bug: 269457150
Change-Id: I1eec5d7b6a268cae4c633d8d89ed485598ebca45
This relands aosp/2470068. The original CL was submitted as part of a
stack that broke tm and udc. Those branches still contain soong modules
with min_sdk_version of type (kind+level).
Test: m nothing on tm and udc (via go/abtd)
Bug: 208456999
Change-Id: I8e013ec10530372f70f0ab0505b7eebeee2b360b
InvalidApiLevel:
This will be used for error handling if a user provided api level is
not recognized
PrivateApiLevel:
This will be used to differentiate the api level of sdk_version:"" from
sdk_version:"current" or sdk_version:"<active_codename>" (all used to be
FutureApiLevel previously). This was not necessary previously since the
type of min_sdk_version was SdkSpec(kind+level). Since it had access to
kind, it could check that it was not SdkSpecPrivate
Test: m nothing
Change-Id: I628b443c34bf2ec258d947dfec09f38b126bc6bb
Add a flag that enables logic specific to multitree-build builds.
Bug: b/266730267
Test: treehugger, manual
Change-Id: Ia6f392525faa9d66bb6e0692b2a2e9c3b8493b0d
Except if BUILD_BROKEN_USES_SOONG_PYTHON2_MODULES is set, and except for
some core py2 modules that can't be removed until python2 is fully gone.
Bug: 203436762
Test: m nothing
Change-Id: I62ccb6f5687eab1e79c372ffc234a90ca5b566ac
- Create the alias under the module-libapi directory. This is the
api_surface that cc_stubs_suite maps to.
- Create the alias only for "current" (atleast for now)
- Create one alias for the stub shared lib, and another for its headers
Test: b build @api_surfaces//... (with aosp/2475091)
Change-Id: Ib004c2c34256f971e74d75317fa5fbbe7273720e
This feature is toggled on with USE_PERSISTENT_BAZEL, which is off by
default. Those that opt-in will have a bazel server running between
builds (with a 3hr default TTL) which will greatly improve analysis on
subsequent builds. (As Bazel maintains a cache of analysis results).
Bug: 266983462
Test: Manual `m nothing` runs (timing with and without the feature)
Test: New integration test
Test: Presubmits
Change-Id: I3af4948baa0c490e9b87c48ffdbe9f67732586c7
This reverts commit 1fbf7f21a4.
Reason for revert: broke docker image, pinning is incomplete it seems
Change-Id: I7102cb233a4fe5ce0f5a1ead98cfc661c3d82ce5
Test: Manually verified artifact timestamps are unchanged on a second
invocation of `m nothing` (with bp changes)
Test: Presubmits
Change-Id: I6bdf106a464597a07ac290cb575425d700721ffe
variable.go:
add a new product variable TrimmedApex which is controlled by
environment variable PRODUCT_TRIMMED_APEX
config.go:
all config to check if trimmed build is turned on or not
apex.go:
add overridable apex module property:
use_DCLA: <DCLA apex module>
"use_DCLA" allows user to just use the lib list in DCLA to determine
which native shared libraries to trim. This property is no-op if
TrimApexEnabled is set to false.
builder.go
1, if it is to produce a trimmed variant, fix the default version code
by making the last variant digit to 2. this is only useful in local
build. in production build, there is apex manifest injection by
coastguard that determines the actual version code.
2, create a new apex rule called: "TrimmedApexRule", this rule invokes
an apexer wrapper called apexer_with_trim_preprocessing which will
properly trim the target libs.
BUG: b/259381334
TEST: adbd banchan build for both static and trimmed variant
Change-Id: I38a91cdef86a3c9185d00610ab3dd7acd07fd90a
Create a
build/bazel/product_config/generated/products/<product_name>/BUILD
file that contains the platform definitions needed for
a particular product. Currently we just create it for the
current lunch target, but the idea is that eventually when
all product config is in starlark, all the products will
have their platform definitions in the tree at once.
Bug: 249685973
Test: Presubmits
Change-Id: I08c82ff28dcf62f09d3b1d2e3186a6b961e12f6e