Allow genrules to access the turbine header jar outputs
from java_library modules using the .hjar output file
tag.
Bug: 251871740
Test: m checkbuild
Change-Id: Ib1ec9734323a51583057fb458f791e1e0bd0d767
Follow-up to aosp/2065271. "private" is a Soong internal `SdkKind`
definition and is probably more meaningul for devs who work on
the build system. Changing it to "private platform APIs" should
hopefully make it more meaningful to a wider audience.
(Context: https://yaqs.corp.google.com/eng/q/4927173287831666688)
Test: None
Change-Id: Ied7198bb529eeaa85bc741177b414e06a7262365
Currently, Robolectric test written in Kotlin may not run, especially
when shards are in used, for example SettingsRoboTests has 10 shards.
This is because Robolectric test currently only recognize java files,
adding kt files to fix.
Rename current uniqueSrcFiles to uniqueJavaFiles, and compiledJavaSrcs
to uniqueSrcFiles. uniqueSrcFiles will contains both Java and Kotlin
files.
Note: android.FirstUniquePaths cannot be used, seems the behavior is
different and cause build error.
Bug: 252355400
Test: cd build/soong && mm
Test: m RunSettingsRoboTests with Kotlin tests
Change-Id: Id530ae4dcabffe01a06f44fe4234ffc67b73a601
Sometimes it is necessary for some functionality to be disabled while
running in unit tests, e.g. functionality that requires external
information such as error prone tools and configuration. Sometimes it
is necessary for some functionality to be enabled while running in
unit tests, e.g. functionality that makes state available for
testing but which is not necessary at runtime.
Previously, that was done by checking to see if TestProductVariables
was nil. This change adds a method to abstract that.
Bug: 245956352
Test: m nothing
Change-Id: I7845b79328e7180623161a9bf897568089da4e4f
On coverage builds, R8 will fail to properly optimize and fail the build
if ignore_warnings: false, because jacoco injects dependencies on
jacocoagent classes, but the jacocoagent library is not part of the
classpath libraries passed in to R8 in its arguments.
Instead we can add jacocoagent as a libs dependency for these modules so
that it will get pulled into the r8 flags.
Bug: 243903417
Test: m
Change-Id: Icc24cc260b896fc800125a0318308d823ccf7a83
This will enable AIDL tags in perfetto traces for the following SDKs:
1. SdkSystemServer
2. SdkCore
3. SdkCorePlatform
SdkModule requires exposing some Trace methods as
@SystemApi(MODULE_LIBRARIES). This will come as a follow up
Test: Manual
Bug: 161393989
Change-Id: I01d520afa8e26eabb97318192151b707b002c28b
On coverage builds, R8 will fail to properly optimize and fail the build
if ignore_warnings: false, because jacoco injects dependencies on
jacocoagent classes, but the jacocoagent library is not part of the
classpath libraries passed in to R8 in its arguments.
Instead we can add jacocoagent as a libs dependency for these modules so
that it will get pulled into the r8 flags.
Bug: 243903417
Test: add optimize.ignore_warnings: false to NetworkStackAppDefaults &&
make SKIP_ABI_CHECKS=true PRODUCT=cf_x86_phone-userdebug \
EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true \
CLANG_COVERAGE=true COVERAGE_PATHS="" \
TARGET_USERDATAIMAGE_PARTITION_SIZE=17179869184 \
SKIP_BOOT_JARS_CHECK=true \
NetworkStack
Change-Id: I71313b1fd35437ec52890f5c30b3fd1381c7c3d2
* changes:
add bp2build unit tests for aidl_interface
AIDL source generation accounts for Bazel paths
convert .aidl srcs for java_library
add Partition method to LabelListAttribute
The AIDL source generation rule sets include flags based on the relative
path of .aidl sources. For .aidl sources provided by Bazel targets, e.g.
in a filegroup, the same directory could be added to the include path
twice. Instead we need to ensure that if a Bazel source provides the
include path, that we don't add it again from a Soong source.
Bug: 229251008
Test: USE_BAZEL_ANALYSIS=1 m api-stubs-docs-non-updatable
Change-Id: I4997039003242b43e0e52ccf41729acb4ad11324
Some protobuf modules like perfetto_trace-full take a long time
to analyze with errorprone, in that case it took over 10 minutes.
Skip errorprone on protobuf or aidl-only modules because having
warnings on generated source code isn't useful anyways.
Bug: 242630963
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I5e73accd0b56a0a71e75927778c5c04a0d358e67
Previously, hidden API properties were only allowed on
bootclasspath_fragment and platform_bootclasspath module types. This
change allows them to be specified on java_sdk_library modules too. It
involves the following changes:
1. Add the properties to the java.Module.
2. Populate and provide a HiddenAPIPropertyInfo struct from
java_sdk_library modules.
3. Modify bootclasspath_fragment to merge information gathered from its
content libraries as if it was specified on the fragment itself.
Bug: 240406019
Test: m nothing
packages/modules/common/build/mainline_modules_sdks.sh
# Ran the previous command with and without this change to make
# sure that this change does not change the sdk snapshot
# contents.
Change-Id: I64eb71c2039ddc14cf380689d0cec7ec221f5b88
This reverts commit 5d80d895b6.
Reason for revert: The issue that broke the build the first time this was submitted has been fixed in ag/19125702. Also the errorprone build was added to presubmit for changes to these files so we should hopefully catch any other issues at presubmit now: cl/458501206
Change-Id: I80ca08df49c58a1ad70de917822301368d49fc67
Previously, the code would modify the Compile_dex property to set it to
true if the module was part of an APEX as the APEX needs the dex file.
That lost information about whether the Compile_dex property was
specified in the .bp file and also meant that the APEX variant had
different properties to other variants which could result in unexpected
differences in behavior between them.
One of those differences can occur in the sdk snapshot generation code
which uses the Compile_dex property to determined whether to write a
compile_dex property in the generated snapshot. If it uses an APEX
variant then it will always add compile_dex: true but if it used a non
APEX variant then it would depend on the setting of compile_dex in the
source. That leads to the generated snapshot being affected not just
by the set of modules that are included but also how they were
specified.
This change stops modifying the properties and just uses a local
variable to store the updated value. All the other (4) uses of the
Compile_dex property were checked and 1 accesses the property before
it is updated, 2 access the property from a module type (Import) that
does not update the property and the other is in the sdk snapshot
generation code which accesses it after it has been modified but needs
to access the unmodified value.
This is needed for the follow up change that allows an sdk module to
reference an apex to automatically add exportable parts of the apex
contents to the sdk snapshot avoiding duplication which can lead to
errors.
Bug: 232401814
Test: m nothing
Change-Id: Ibc80d93473a266dc9f9900ec1cb175b51460b5e9
This causes kotlinc to output default methods
instead of DefaultsImpl inner classes. It's required
for code that depends on other libraries using
@JvmDefault. It will be the default in a future
version of kotlin.
Bug: 236431222
Test: treehugger
Change-Id: I67a7cb3b816b41a441af7ec78cc64bc358c6889d
If max_sdk_version is included in Android.bp that value will now be
propagated to manifest_fixer.py. This value will then be used to
override any maxSdkVersion attribute set on permission or
uses-permission tags in the android manifest if maxSdkVersion="-1".
Bug: 223902327
Test: add max_sdk_version to Android.bp for test app
Test: create permission in test app manifest with maxSdkVersion="-1"
Test: run test to check maxSdkVersion=max_sdk_version
Change-Id: Ic533ef2a41b9ecc9ee68c69399026df47ee945b7
Soong made the assumption that any .srcjar was generated source, for
which the lints were not executed. It may not be the case for .srcjar
that are manually created. Run the linter on any .srcjar that has been
provided within the src attribute, but ignore any source generated
.srcjar (such as .proto or .aidl).
Test: m lint-check
Bug: 228774926
Change-Id: If214fb57f54049fce54297ee6bf65d734b3d2e6d
Upgrading dagger uncovers an issue where java-only modules with
kotlin-containing dependencies may see org.jetbrains.annotations.NotNull
annotations. Include the kotlin-annotations in the output jar the
same way kotlin-stdlib is included.
Bug: 227669740
Test: TestKotlin
Change-Id: Ifc33a32b121c1b9a9d1911bdec332264b78b571c
This reverts commit 0b1c70efbc.
The reverted commit was based on the idea that uses-libraries that are
explicitly specified in build files should not be implicitly added to
the manifest, as that would mean that anything added to the build files
will flow to the manifest.
Although this logic is correct, it prevents propagation of
uses-libraries from dependencies, which is wrong: if a library has an
explicit uses-library property in Android.bp, this property is expected
to be propagated to the library's dependencies. Failing to do so would
mean that every user of that library has to add uses-library property to
their build files, which doesn't scale (see b/214255490 for example).
Bug: 214255490
Test: lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd \
&& adb wait-for-device && adb root \
&& adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty output, no errors at boot
Change-Id: I6f420e76a89aa2f37be99f877711736640f2c361
(cherry picked from commit 3953153c9e)
Previously, the .impl library of java_sdk_library modules would end up
with the jacocoagent statically included. That is because their
Instrument flag was set to true when created by their parent. As that
was before the deps were added that meant that they ended up with a
static dependency on jacoagent (at least when UnbundledBuild() was
true).
That was not previously a problem because the .impl files were only
used at build time. However, a recent change to make updatable-media
statically include framework-media.impl (which statically included the
jacocoagent classes) broke the coverage build because the jacocoagent
classes are not in the permitted packages for the updatable-media.
When instrumenting the bootclasspath the jacocoagent library is added
to the art-bootclasspath-fragment.
The jacocoagent should only be statically included in apps, or test
apps. This change adds an extra flag to specify whether the module type
supports statically including the jacocoagent. This is set to true by
apps and test apps but not when the java_sdk_library creates the .impl
java_library preventing it from statically including jacocoagent.
Bug: 230967146
Bug: 229932396
Test: COVERAGE_MODULES=media \
PRODUCT=mainline_modules_x86 \
TARGET_BUILD_APPS=com.google.android.media \
vendor/google/build/build_unbundled_coverage_mainline_module.sh
# Fails without this change, passes with it.
Merged-In: Ic95cf11a05f59b67e623474ed3dd9be6b4442c42
Change-Id: Ic95cf11a05f59b67e623474ed3dd9be6b4442c42
Bug: 215567981
Bug: 204776549
Test: m out/soong/.intermediates/frameworks/base/framework-minus-apex/android_common/lint/lint-report.xml, then check that that file doesn't have any of these warnings
Change-Id: I39aa2228474630c93250bf5833ac6bd9bbadcc7f
This field is provided by the `dexpreopter` struct, which is a part of
`java.Module` and also had an identially named field. This created
confusion when the latter field was not properly copied into the former,
which resulted in not propagating class loader context, e.g. for static
library "androidx.preference_preference". This didn't cause class loader
context mismatch errors at boot previously, because the library didn't
have any uses-library dependencies before a recent prebuilt update.
Bug: 214255490
Test: lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd \
&& adb wait-for-device && adb root \
&& adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch'
# empty output, no errors at boot
Change-Id: Ib818c5d2934d28817bb7a04b6114ae8b82a5c04d
- NewApi check should be enforced only if min_sdk_version is less than
the compile_sdk_version (the opposite direction should be a different
build-time error)
- Change the datatype of *sdkVersion to android.ApiLevel (from string)
to support version comparisons
Test: go build ./java
Test: no changes in ninja file
Bug: 228956345
Change-Id: Ic408857db7760d912ef4694d2ed72c0b7106eb04
Write `static_libs` and `libs` of Java library and Android app modules to module_bp_java_deps.json. This enables downstream tools to correctly set up the runtime environment. Note that while static libraries don't need to be on the Java classpath these modules could have non-static library dependencies that do need to be present.
Test: m out/soong/module_bp_java_deps.json
Bug: 227538646
Change-Id: I7c4aecb2fb03c890f0d2aaae80e619f6176809ef
This reverts commit c6ef485370.
Reason for revert: Multiple systemui presubmits are broken due to this change
Bug: 228262695
Change-Id: I1efed519c49d8d0583815c7bf2b3801bf0ba12fa
When compling kotlin code with annotation processors we are generating
java stubs for the kotlin sources using kapt, and parsing them in
turbine when running the annotation processors. Passing --output
to turbine will also compile the stubs into a header jar that can
be used as a dependency to javac, allowing the javac and kotlinc
rules to run in parallel. The turbine-apt header jar can't be used
as the header jar for downstream modules as it doesn't contain the
kotlin metadata needed by kotlinc rules, so the kotlinc gen-jvm-abi
plugin output is still used for the module's final header jar.
Test: TestKapt
Bug: 222095735
Change-Id: I82d0900f3dc30f3e3ebd7cab0693dfe741d9b955
Normally turbine is disabled when an api generating annotation processor
is in use because the annotation processors are run in javac, so any
generated api would not be present in the turbine header jar. When
compiling with kotlin and annotation processors, the annotation processors
(including any that generate api) are run in an extra turbine invocation
to generate sources to make the results visible to kotlinc, and so can
also be compiled by the normal turbine invocation. Force turbine enabled
when kotlin sources are present.
Test: m SystemUI
Bug: 222095735
Change-Id: I5fcfe67e46cb4a4e90388f088327488959b6571f
Kotlin's jvm-abi-gen plugin can generate header jars similar to the
turbine output for java sources, which can be used to avoid recompiling
downstream modules when the ABI hasn't changed. Unlike turbine, the
plugin runs as part of the main kotlinc invocation, so it doesn't allow
the downstream modules to start compiling any sooner.
A future possible optimization is to use turbine to compile the kapt
stubs, at least for the kotlin+annotation processor modules that already
generate them, which would allow compiling downstream modules before
invoking kotlinc or javac, as well as invoking kotlinc and javac in
parallel with each other.
Bug: 222095735
Test: TestKotlin
Test: m SystemUI
Change-Id: Ib1bb2ecea47c851a108a26f9ed4f827f289d1321
r8 gets the static libs in the program jar, it shouldn't also get
them as library jars. Keep a separate classpath for dexing that
includes libs but not static_libs.
Bug: 222468116
Test: m checkbuild
Test: TestD8
Test: TestR8
Change-Id: Icca3393f496cbcadcc633f3b156761e6c145f975
