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
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
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
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
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
The library file for a cc_shared_library dependency is added to the linkFlags of the rustc compilation action, but no explicit dependency was made on it from a Ninja perspective if a TOC was also present. This change adds the explicit dependency on the library file whether or not a TOC is present.
Test: m crosvm
Bug: 275416061
Change-Id: I625b62762d9ba7b4fd2b8362285528e47f728dd4
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
This reverts commit 9838acffdd.
Reason for revert: b/274947458
Broke CI.
Will reland with QEMU options once the host image is fixed.
Change-Id: I6ad847cde2a291b3dd5b92314b2011744de50883
These must be added in the soong_injection code as opposed to just
defined loosely in checked-in bzl files because the product_vars
select statement must be updated to support the new platforms.
Bug: 269577299
Test: b test --config=android //build/bazel/...
Change-Id: I7bba9af214896dd3b5938bae70b7c0cea4f75e41
There are no tests to verify the generated action for the canned fs
config entries, so add some.
Also update the prop's docstring to reflect the actual logic.
Bug: 275209284
Fixes: 275280970
Test: soong tests
Change-Id: I37f2a8640bf4c307068a77db7a635c9bbeb9f38f
This is a rework of commit 5bdf2d589c
which made implementation variant of prebuilts with stubs as not
installable except libclangrt. This change narrows the affected modules
to prebuilts/module_sdk because cc_prebuilt_library_shared with stub
implementation is a special case only used there. It's typical for
cc_prebuilt_library_shared to have implementation, not stub.
Bug: 220898484
Test: ART_MODULE_BUILD_FROM_SOURCE=false m nothing
Change-Id: I99e5213da8cc473901e23942b50f06c023d91f60
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
Mostly exporting variables to Bazel, but also allowlisting a BUILD
file.
Bug: 251217226
Test: Unit tests
Change-Id: Id87015a3cd5d970700c4058ec989bb0c14c36bcb
Note this doesn't entirely match Soong's logic but is an improvement to
allow linking against implementation when two cc modules are
apex_available to the same module.
It is not possible to recreate the logic for "directly in" without
significant changes to bp2build as we do not add dependencies nor run
apex mutators. Rather than trying to replicate this, we would be better
off refactoring Soong to no longer support the "directly in apex" logic
and require users to correctly specify apex_available.
Bug: 272378496
Test: go test conversion tests
Change-Id: I17ac426f9b4bdad0c2ab661484e5d994f63568ce
