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
Simplify running lint on a module by adding a per-module phony target,
e.g. Gallery2-lint.
Bug: 216462289
Test: m Gallery2-lint
Change-Id: I9d4ab362bb116d49f00fc3f79d61d7239528d575
Current CC/Rust Image variations are generated with target VNDK version.
However, this is no longer valid if VNDK is deprecated. This change
generates image variation without version ("vendor", "product") if VNDK
is deprecated.
Bug: 316829758
Test: m nothing --no-skip-soong-tests passed
Test: aosp_cf_x86_64_phone build succeeded
Change-Id: I2387ed8a2632bfd9462621f882a947695ae1653d
lintable modules currently pick up files named "lint-baseline.xml" to
use as the lint baseline implicitly. This is confusing because you could
end up using the baseline files in more modules than intended. Lint also
has a feature where it requests you remove unnecessary findings from the
baseline file, so something could be necessary for one module, but
unnecessary for another that accidentally picked up the baseline.
All modules that used to pick up the baseline implicitly have been
fixed to specify it explicitly already.
Fixes: 272769514
Test: Presubmits
Change-Id: Id17202e2d119b87ab82c18cb35410b93ed8d5071
This change disallows Java modules in the vendor partition to use System
SDK that is newer than API level 34; 34 is the latest allowed.
Background 1: with Trunk Stable, the system/vendor interface is released
at Q2 whereas the system/app interface is released at Q3. In other
words, at Q2, the APIs which will be added to the system SDK at Q3 are
not available. Since the system/vendor interface (which is fronzen at
Q2) is what the modules in the vendor partition will be building
against, they can't and shouldn't use those new APIs that will be added
in the future (Q3). Using those APIs is risky because there's a chance
that those APIs get removed or changed between Q2 and Q3. For example,
2024 Q2 is technically still Android U, not Android V.
Background 2: The use of Java APIs in the vendor partition had many
issues. Most significantly, those "vendor" Java apps are categorized as
part of the system partition because all Java app processes require
access to platform internal libraries that are prohibited to vendor
processes. Furthermore, since the Project Treble, the vendor partition
was re-purposed to a partition to host SoC-dependent bits - usually
HALs. Implementing HALs in Java has never been officially supported and
has had many loop holes.
We'd like to use both background 1 and 2 as a chance to disallow any
Java code in the vendor partition. However, since there are already some
Java modules in the partition, we can't suddenly ban it. The deprecation
will be made gradually, and this CL is the start.
Note that sdk_version: "current" or "system_current" is automatically
overridden into 34 or system_34. This is to prevent sudden breakage of
vendor modules that have been targetting the latest (i.e. current) API
level. They will however fail if they use APIs newer than API level 34.
Bug: 314011075
Test: m blueprint_tests
Change-Id: I59f5ac15ce9ac2ff7cc89e9c110169359077c37c
When --custom-package is specified as an aapt2 flag translate it to
--packageForR when running ResourceProcessorBusyBox.
Bug: 294256649
Test: m javac-check
Change-Id: I2c97c760ea8a0203790feda82b98e12c2dbd7b72
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 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
Since OtherModuleHasProvider will be deprecated soon, replace it with OtherModuleProvider
Test: go build ./java
Change-Id: I79736e44d85bc6e8c97f08ebf783b40533a3e6ae
