Given that now the droidstubs module generates the "exportable" stubs,
this change modifies java_sdk_library to generate the java_library
modules that compiles the "exportable" stubs per api scope.
The detailed naming scheme of the generated modules are available in the
bug linked in the footer.
Similar to the from-text java_api_library vs from-source java_library
static lib selection for the "everything" stubs, the "exportable" stubs
module can also toggle between the stubs java_api_library and the
java_library module. However, given that the "exportable" stubs
generation has not been implemented for from-text stubs, the module
always default to depend on the from-source "exportable" stubs compiling
java_library module.
Test: go test ./java
Bug: 315495926
Change-Id: I5798312c1338c55625b2030da728b056385171a4
This change adds support for the droidstubs module to export the
"exportable" artifacts via OutputFiles(tag string) method, while
supporting the current behavior of exporting "everything" artifacts via
a tag. With the support, a rdep module can depend on the "exportable"
(and "runtime" in the long run) artifacts by prepending the stubs type
in the tag. For instance, given that the currently supported tag
{.annotations.zip} exports the everything annotations.zip file,
{.exportable.annotations.zip} tag will export the exportable
annotations.zip file. For an unsupported combination (e.g. all runtime
stubs related artifacts as of now), an error will be thrown.
Test: m nothing --no-skip-soong-tests
Bug: 315490657
Change-Id: Idcefd9cdc02d323306fb8d7be2a2b34f67501f56
This change generates rules for "exportable" stubs in the droidstubs
module.
Given that there are a lot of overlap between the currently existing
"everything" stubs rule and the newly introducing "exportable" stubs
rule, the currently existing metalava rule commands are modularized to
be utilized in the "exportable" stubs rule commands.
The currently existing build actions are modularized in the followings:
- commonMetalavaStubCmd(...): metalava commands that are required for
generation of both "everything", "exportable", and potentially
"runtime" stubs
- everythingOptionalCmd(...): metalava commands that are dependent on
"everything" stubs and not dependent on flagged apis annotations, such
as api lint, released api check
Based on this modularization, the "everything" stubs are now generated
in everythingStubCmd(...), which calls commonMetalavaStubCmd(...) and
everythingOptionalCmd(...).
Similarly, the "exportable" stubs are generated in
optionalStubCmd(stubsType=Exportable, ...), which calls
commonMetalavaStubCmd(...) and appends additional flags. Runtime stubs
can be generated similarly in the future with
optionalStubCmd(stubsType=Runtime, ...).
"everything"-related artifacts will now be created in
`everything/` subdirectory, and "exportable"-related artifacts will be
created in `exportable/` subdirectory. For example, the outdir of a
droidstubs module "foo" would look like below:
```
foo
|-- everything
| |-- foo_api.txt
| |-- foo-stubs.srcjar
|
|-- exportable
|-- foo_api.txt
|-- foo-stubs.srcjar
```
The module generates the build rules for the "exportable" stubs
regardless of whether the module defines the `aconfig_declarations`
property or not. All APIs marked with `@FlaggedApis` annotations are
stripped out for the "exportable" stubs when the `aconfig_declarations`
property is not defined. On the other hand, only the `@FlaggedApis` that
are specified in the aconfig_declarations module and are enabled will be
included (and all others are stripped) when the `aconfig_declarations`
propety is defined.
Test: go test ./java && BUILD_FROM_SOURCE_STUBS=true m
Bug: 315490657
Change-Id: I300273cd2a62fa978b046c0268e3a67c35e22b08
In consideration of the incremental build performance, this change let
droidstubs and java_sdk_library (which generates droidstubs per api
scope) modules to specify `aconfig_declaration` modules where the
dependent flags are defined in via the "aconfig_declarations" property,
opposed to passing uniform "all_aconfig_declaration"-generated flag
arguments to metalava.
When "aconfig_declarations" property is defined for java_sdk_library
modules, the property is passed to the generated droidstubs modules.
When "aconfig_declarations" property is defined for droidstubs modules,
the all aconfig_declaration modules listed in the property are listed as
deps, all cache protobuf files are gathered and metalava-consumable
flags are generated in "revert-annotations.txt".
Although this change introduces scalable implementation to easily
support generation of the "runtime" stubs corresponding flags, actual
support of the runtime flags/stubs will be done in future changes. This
change mostly focuses on the generation of the "exportable" flags.
Utilization of the generated "exportable" flags will be done in future
changes.
Test: go test ./java
Bug: 315485740
Change-Id: I37becd1b9dd9069d7ac4abed130906df30b3fdf4
If there are lots of files to be packaged, it causes `Argument list too
long` error. So I extracted that as a separate script with
WriteExecutableFileRuleVerbatim, and the method do sharding for long input.
Bug: 314933937
Test: define large system_image definition
Change-Id: Ibf692d4db6da6b7a536cb5b53b15c545e07ff262
This intial list contains the directories that don't have any Android.mk file, and this will prevent new Android.mk file being added in these directories.
Bug: 318428689
Test: CIs
Change-Id: Ifde1b77ad17b8bb2e7ba962229cee6ba267d6316
Previously, Soong's phony simply added "required" or "host_required"
to LOCAL_REQUIRED_MODULES and `include BUILD_PHONY_PACKAGE` without
correctly adding them to the dependency list.
This change add a new `phony_rule` module type to Soong that acts like
`.PHONY` instead of `BUILD_PHONY_PACKAGE`
Bug: 316838256
Bug: 309730110
Test: 1. Use `phony_rule` and adding "phony_deps: [dep_modules]" to
Android.bp.
2. make target and check the dep_modules be built.
Change-Id: I3e9e9ac26ecc456668f1b6baf5c08f9c9139b3b2
n2 (a reimplemntation of ninja) adds a check that depfiles only add
dependencies on source files, not generated files, because generated
files are not guaranteed to exist before an action runs if there isn't
an explicit dependency between the two.
This is the case for our glob result files. However, we can rework the
build so that they're directly depended on instead of using a depfile.
Bug: 318434287
Test: rm -rf out && m nothing && m nothing
Change-Id: I513fa5536136e6bf19c347710f0722d696199612
LOCAL_STATIC_LIBRARIES, LOCAL_WHOLE_STATIC_LIBRARIES,
and LOCAL_HEADER_LIBRARIES are only exported to Make
so that it can generate module-info.json. Export
ModuleInfoJSONProvider from cc modules so that Soong can
generate the module-info.json entries, and remove the
properties from the generated Android.mk. This will prevent
Kati reanalysis when making some Android.bp changes.
Bug: 309006256
Test: Compare module-info.json
Test: Compare Kati's build.ninja
Change-Id: I6660f6802b9cea46eed553cac12f09a373eeb019
Generate module_info.json for some Soong modules in Soong in order to
pass fewer properties to Kati, which can prevent Kati reanalysis when
some Android.bp changes are made.
Soong modules can export a ModuleInfoJSONProvider containing the
data that should be included in module-info.json. During the androidmk
singleton the providers are collected and written to a single JSON
file. Make then merges the Soong modules into its own modules.
For now, to keep the result as similar as possible to the
module-info.json currently being generated by Make, only modules that
are exported to Make are written to the Soong module-info.json.
Bug: 309006256
Test: Compare module-info.json
Change-Id: I996520eb48e04743d43ac11c9aba0f3ada7745de
Determine the install location of vintf fragments and init.rc files
in Soong so that they are available to Soong-generated module-info.json
entries. Collect the vintf fragment and init.rc files requested by all Soong
modules, deduplicate the list, and install them in Soong.
Bug: 309006256
Test: Compare module-info.json
Change-Id: I491dc05a773d1a82e485475834d2669fc95cfa1e
The availability of these soong modules to com.android.tethering has
been made explicit in Android.bp files
Bug: 281077552
Test: m nothing
Change-Id: Ib96d5ecb8518628fda8c474b10e443abacc9bc21
hiddenapi processing require boot jars from apexes to determine the full
set of methods available at runtime.
When building with prebuilts, this comes via
java_import/java_sdk_library_import, which acts as a hook for
prebuilt_apex/apex_set. If we have multiple apexes in the tree, this
hook becomes 1:many. This CL prepares platform_bootclasspath to select the right
deapexerd .jar files when mutliple prebuilts exist.
Implementation details
- Create a dependency edge from platform_bootclasspath to
all_apex_contributions (DepsMutator)
- For every boot jar, query all_apex_contributions to get the path to
dexjar file (GenerateAndroidBuildActions)
Some other important details
- This CL does not drop the old mechanism to get the dex file (i.e. by
creating a dep on java_library). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
- This CL has a functional change when building with source apexes. At
ToT, the unecoded hiddenapi dex jar is used for package check and
generating the monolithic stub file. After this change, the hiddenapi
encoded file will be used for these operations.
This should be fine since the
package and dex signature do not change across the encoded and
unencoded dex file. In fact, we already have a split today. When
building with prebuilts, we use the encoded dex file. When building
with source, we use the unecoded dex file.
Test: Added a unit test
Test: Manual testing in internal described below
- lunch cf_x86_64_phone-next-userdebug
- flagged com.google.android.adservices using apex_contributions
- aninja -t commands out/soong/hiddenapi/hiddenapi-stubs-flags.txt # no
diff before and after
Bug: 308790777
Change-Id: I72c70f0ae1b587679203ea254c9c12a48e7aa782
This wasn't needed when fuzzers had their own
lib directories, but because the lib directories
were combined, this caused interactions because
system and vendor libraries were mixed in the
same folder, sometimes overriding each other.
Comments are left with some details about
future issues. Bug has a series of recommendations
to prevent issue again.
The main goal of this patch is to get the fuzzers
working, not fix every issue here.
Bug: 307611931
Test: run vendor fuzzer and check lsof:
android.hardwar 22719 root txt REG 254,94 4350056 3455 /data/fuzz/x86_64/android.hardware.drm-service.<name>.aidl_fuzzer/vendor/android.hardware.drm-service.<name>.aidl_fuzzer
android.hardwar 22719 root mem REG 254,94 4350056 3455 /data/fuzz/x86_64/android.hardware.drm-service.<name>.aidl_fuzzer/vendor/android.hardware.drm-service.<name>.aidl_fuzzer
android.hardwar 22719 root mem REG 254,94 1047232 3464 /data/fuzz/x86_64/lib/vendor/libbase.so
android.hardwar 22719 root mem REG 254,94 4027304 3460 /data/fuzz/x86_64/lib/vendor/libcrypto.so
android.hardwar 22719 root mem REG 254,94 4021632 3467 /data/fuzz/x86_64/lib/vendor/libbinder.so
android.hardwar 22719 root mem REG 254,94 329408 3466 /data/fuzz/x86_64/lib/vendor/libcutils.so
android.hardwar 22719 root mem REG 254,94 508968 3463 /data/fuzz/x86_64/lib/vendor/libutils.so
android.hardwar 22719 root mem REG 254,94 592944 3465 /data/fuzz/x86_64/lib/vendor/libclang_rt.ubsan_standalone-x86_64-android.so
android.hardwar 22719 root mem REG 254,94 2328616 3462 /data/fuzz/x86_64/lib/vendor/libc++.so
and run a system fuzzer
servicemanager_ 27878 root txt REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 4390560 4074 /data/fuzz/x86_64/lib/libvintf.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 11584 4086 /data/fuzz/x86_64/lib/libdl.so
and run a system fuzzer
servicemanager_ 27878 root txt REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 609736 67408 /data/fuzz/x86_64/servicemanager_fuzzer/servicemanager_fuzzer
servicemanager_ 27878 root mem REG 254,94 4390560 4074 /data/fuzz/x86_64/lib/libvintf.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 13872 4077 /data/fuzz/x86_64/lib/libvndksupport.so
servicemanager_ 27878 root mem REG 254,94 11584 4086 /data/fuzz/x86_64/lib/libdl.so
Change-Id: I91a51d2f1cb537cfaae8379998078188f2b10a98
`keep-flagged-apis` module generates a txt file that
contains annotations based on aconfig flags that are passed to metalava
when generating "exportable" or "runtime" stubs.
`keep-flagged-apis.sh` already exists under
`packages/modules/SdkExtensions` directory, but modifying the script
(and the bp module definition) will break the `udc-mainline-prod` branch
in downstream. Therefore, the modified script and the module definition
is defined here, and will be used in the long term.
Test: m keep-flagged-apis && manual
Bug: 315485740
Change-Id: I4ab8d4ea2c6c8ddba6d55b2b25e8c8d3b7c8fa07
There are no more callers to the non-generic provider APIs, remove them.
This reapplies I4d336340e630643f98531787a81e0f1f18ec108d after
I79736e44d85bc6e8c97f08ebf783b40533a3e6ae removed a newly introduced
usage.
Bug: 316410648
Change-Id: I152f8e5ef8330b811d3f42f8c2c73943ac0979bb
Test: builds
This doesn't do anything now, but we are using it
to document an API used to be in the LL-NDK. This
is important so that we know not to remove the
symbol (e.g. if it is only in the LL-NDK and not
in the NDK).
Bug: 317293882
Test: N/A
Change-Id: If67715be5572ade7ce1e7c3bd9bc7a98f3da39f5
The implicit //apex_available:anyapex seems to be unused, so we can drop
it
Bug: 281077552
Test: m nothing
Change-Id: I66fef50901bfd19237a9ef96b169ecefa01d76b9
Update the calls to dump aconfig caches; the new canonical name is
`dump-cache`, though `dump` is still an accepted alias (for now).
Bug: N/A
Test: m all_aconfig_declarations && printflags
Change-Id: I9f82d31666ced6bbd0f195f1422590547114e0f0
This is needed to be compatible with JDK 21+ which does not allow
other platforms (apart from the ones listed in the modules
plugin) when linking a system image.
Note the value of target platform doesn't matter to us, we just
choose a closest one to replace "android".
Bug: 313924276
Test: m EXPERIMENTAL_USE_OPENJDK21_TOOLCHAIN=true
Change-Id: Id805f31089fdbd78bf4db06c89ae391f25563448
hiddenapi and dexpreopt require boot and system server jars from apexes.
When building with prebuilts, this comes via
java_import/java_sdk_library_import, which acts as a hook for
prebuilt_apex/apex_set. If we have multiple apexes in the tree, this
hook becomes 1:many. This CL prepares dex_bootjars to select the right
deapexerd .jar files when mutliple prebuilts exist.
Implementation details
- Update prebuilt module types (prebuilt_apex/apex_set) and source
apexes to set a map of
library name to dex jar path on host.
- dex_bootjars will access the path of the .dex jar on host via the
provider. These then
copied/installed to the right locations.
This CL does not drop the old mechanism to get the dex file (i.e. by
creating a dep on java_library). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
Bug: 308790457
Test: git_master-art-host:art-gtest https://android-build.corp.google.com/builds/abtd/run/L21500030000926533
Test: git_main:art_standalone_dexpreopt_tests https://android-build.corp.google.com/builds/abtd/run/L99000030000891212
Test: Added a unit test that checks that the right .jar is selected
when multiple prebuilts exists
Change-Id: I6ef94135b9303a35135810930af4b641df13a583
