Otherwise when other modules use the apex as data (for example, in
tests) they get the full path from the root of the workspace to the
apex.
Fixes: 276416485
Test: atest timezone_data_e2e_tests:com.android.tests.apex.TimezoneDataHostTest#testStageActivateUninstallApexPackage -- --abi x86_64 then tree out/host/linux-x86/testcases/timezone_data_e2e_tests
Change-Id: Id740856794770df2edc55dfff5f6f938fc31d0c5
Users can pass the jar-file creating module via dep_api_srcs property in
java_api_library to create the jar file not by compiling the stubs
generated from metalava but by extracting and zipping the class files
from the jar file of the input module.
Test: m android-non-updatable.stubs.from-text
Bug: 273381329
Change-Id: Id1b75179111cc7ff45faaff58388db1347bb18e5
The cache directory stores files that should persist between builds.
Currently it will contain reproxy.creds, which caches the authentication
mechanism and token used to make subsequent builds faster.
Test: m nothing build takes 7s
Change-Id: Iaaa20b92630405918e5e91e09eca6c798b8fc872
Some Rust crates with no src_deps have generated files checked in in an
"out" subdirectory and included via a reference to $OUT_DIR, such as
external/rust/crates/userfaultfd-sys.
Astonishingly, some people must be leaving $OUT_DIR set to the default
value of "out", because with $OUT_DIR set to this value, building these
crates would presumably succeed. For everyone else, the build fails
when building one of these crates because it will attempt to load from
the wrong directory. Presumably these crates should be using src_deps
instead (and once that's fixed, we should probably *unset* $OUT_DIR in
rustc invocations to prevent the same thing from happening again), but
for now, fix the build with non-default OUT_DIR by explicitly setting
OUT_DIR to "out" if there are no src_deps.
Change-Id: I09f99424fc01a1e42e910622c77ab8f7312819bd
Ignore-AOSP-First: The parent CL is internal
Bug: 267229065
Test: go test
Change-Id: Ia14679285b92f3f14ff269392a61f978c71311b2
Merged-In: Ia14679285b92f3f14ff269392a61f978c71311b2
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
* changes:
Create core_platform system modules from .txt files
Create system modules using .txt stubs
Create a defaults module for stripping out annotations
This system module is used to compile conscrypt and icu stubs. These
have migrated to java_sdk_library that set `annotations_enabled: true`
explicitly.
Test: m
Test: TH
Change-Id: I65ceb1fbf0dcdbb3504b69ebce6ca8f0b67e964d
Currently, ApiLevelFromUser calls ReplaceFinalizedCodename(raw).
This function checks whether raw is in the getFinalCodenamesMap which is
equivalent to ApiLevelsMapReleasedVersion with an additional entry for current.
Since ApiLevelFromUserWithConfig already returned on the raw = "current"
we only care about ApiLevelsMapReleasedVersion and can avoid the unecessary
use of strconv.Atoi(strconv.Itoa(raw)) that calling ReplaceFinalizedCodename
ends up doing.
Also makes the function look more like the Bazel version in
build/bazel/rules/common/api.bzl
Change-Id: I8c03fc159d7f63298273624f030d1956e2307615
Test: m bp2build
We must pass pointer of pointer to correctly cash snapshotInfo and
register provider only once.
Bug: 271215084
Test: build
Change-Id: Ia7b43c7b97a8fcabd3b4d6ac8b990c622b6ceb6e
This change causes us to stop building the CVD host package during
the default `m` build, as this is one of the most time consuming steps
of incremental builds, taking around a minute on my machine. Instead,
we build a directory containing the host package contents. A companion
change to acloud teaches it to upload the directory if it exists.
The host package tarball will continue to be built with `m dist` and `m
hosttar`. When building the host package, just create it from the package
contents directory instead of going through a zip file as we were before.
Bug: 273862156
Change-Id: Id7ab47cd5a2e96d073fcc21ed82d3719119df6b9
Previously, warnings about missing modules were printed directly to
stderr. Instead we can pass these messages along as errors using the
existing pathways.
Bug: 269457150
Test: m nothing
Test: add -external to PRODUCT_SOURCE_ROOT_DIRS and observe missing
module errors
Change-Id: I7273c427f38024e3c288f1ecb31175ed04ac44a6
In scope:
- core.current.stubs
- system modules generated for core's public stubs
- system modules generated for core's module_lib stubs
The system modules generated for core_platform api surface will be
handled in aosp/2514755
Test: go build ./java
Change-Id: I34134f79c8ae6e5b218d0b85553de5a748a8cc3f
Create a parallel set of java_system_modules that build using stubs from
.txt files. decodeSdkDep will be updated to use these system modules
behind a flag.
Since stub generation from .txt is not available at ToT yet, these
modules have been marked "enabled: false"
Test: None (will test when the enabled flag is turned on)
Change-Id: Ie9d465f5542a5430f03ba2e0861325011ac8e8c5
Hiddenapi processing uses the stub libraries to determine the api
surface boundaries. Use JavaLibraryName function to redirect the usage
of stubs from .txt files based on config.
This should be a no-op for now.
Bug: 271443071
Test: go test ./java
Change-Id: I1ed3ab2485c903bc57f627dc1acf1a3fbc0a3c4d
Create a parallel set of java_system_modules provided by the SDK. This
parallel set will build using stubs of core libraries generated from
.txt files. Since stub generation from .txt is not available at ToT yet,
these modules have been marked "enabled: false". decodeSdkDep will be
updated to use these systemModules behind a flag.
(Will create java_system_modules for core_platform in a future CL)
Test: None (will test when the enabled flag is turned on)
Change-Id: Idd89d656fcbc87e8698fe05d65a685ade4488546
The "FromText" suffix is an implementation detail. Having this suffix in
the name can be also confusing because in certain settings (e.g. when
not run with --build-stub-from-text) it returns the name of the stub
module generated from source files
Test: go build ./java
Change-Id: I68678ddfaa3d68c8e1a945632e7512b5de33d9af
This reduces code duplication in preparation for checking in a
java_system_modules created using stubs from .txt files
Test: No diff in the 4 java_system_modules
Change-Id: I0a13a0e7bf402cbe8f0dd3942b1f737cc6ac0de7
This CL removes the `default_alloc_error_handler` feature from the
allowed feature set passed to rustc. This feature was stabilized in
Rust 1.68.0 and now that that has been deployed we can remove the
feature annotations from our codebase.
Bug: 267698452
Test: m rust
Change-Id: Ifc543ec83d3221cc8bcb6c83658abe09696b51ea
