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
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
