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
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
https://android-review.git.corp.google.com/q/topic:limit_systemsdk
introduced a new check for preventing the use of system SDKs above 34
from Java modules in the vendor partition.
As this may break some unprepared targets, introduce
BUILD_BROKEN_DONT_CHECK_SYSTEMSDK as a temporary escape hatch.
This flag will be deleted eventually.
Bug: 314011075
Test: Add BUILD_BROKEN_DONT_CHECK_SYSTEMSDK := true to BoardConfig.mk
Change-Id: Id7901f85c221bc03fa1c15ef15dbec14b783a79a
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
libz is a stub library, but needs to be available to runtime apex
because it gets statically linked into bionic linker
Bug: 281077552
Bug: 277651159
Test: m nothing
Change-Id: I04f6f13768d8f9c160ce84202e2003b195176355
In case any of the commands fail.
Also skip writing out empty preparer.sh files.
Bug: 314933937
Test: Presubmits
Change-Id: Ia94d032bc4800379608d8a3cf594f25951a3ab32
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
