MTS tests built on unstable branches (e.g. git_master) should be testable on
old system images (e.g. S). However, they run into an error during installation
on older images:
`Requires development platform $<current_codename>, but this is a
release platform`
This CL fixes this issue by updating the target_sdk_version of MTS test apps
targeting current to the magical sdk_version 10000
Bug: 227473065
Test: go build ./java
Test: TH
Change-Id: Ic0358a48a19dc239defbb4ee8ec99225cce75584
This allows targets to opt-in to running R8 without the -ignorewarnings
flag. Ignored warnings can cause code to be optimized incorrectly, so
this makes the build safer for such targets.
Ideally ignore_warnings should default to false, but all targets need to
be fixed for that to happen. As a first step, provide a mechanism for
individual targets to ensure they do not introduce regressions.
Bug: 229727645
Bug: 180878971
Bug: 226127213
Bug: 239990030
Test: m (runs dex_test)
Change-Id: Ic0eef29598c1ee47e958da8a5048d9696165a235
JNI libs present in AAR files are ignored in the build. If those
libraries are necessary, they must be manually extracted and a
prebuilt_cc_library module must be created for them. Instead, we can
extract these libraries and copy them to an output APK as part of the build.
Bug: 228848794
Test: created android_app that depends on an android_library_import with
JNI embedded, and verified that .so libs are present in APK
Test: created android_app that depends on an android_library which
depends on android_library_import with JNI embedded, and verified
that .so libs are present in APK
Test: verified that multiple .so's from a single architecture are copied
to APK
Test: verified that the absence of a jni/<arch> folder or files in the
folder will cause the Ninja action to error
Change-Id: I242a862d7bd881f7a4a8c23493924d8fe441ea25
Bug: 220168131
Test: go test ./java -run TestImportMixedBuild
Test: USE_BAZEL_ANALYSIS=1 m CtsManagedProfileApp && verify jars are
included from execroot/__main__ directory
Test: build/bazel/ci/mixed_droid.sh
Change-Id: I6d35a2389ea35525d532efc8474c71d2c8825646
This looks like it may have been a typo'd copy paste or maybe a name
change that got forgotten about.
Test: CI
Change-Id: I9f5c17f8e2d11b9cf6cd0da4685d719cdbbdcc11
Previously, the platform_compat_config modules needed to be explicitly
listed in the sdk snapshot and the apex. This change will automatically
export them to the sdk snapshot when the apex is listed in its apexes
property.
Bug: 232401814
Test: m tethering-module-sdk
# Before this change the generated snapshot did not contain the
# platform_compat_config, after this change it did.
m art-module-sdk
# As that explicitly specifies the platform_compat_config in its
# compat_configs property this change has no effect.
Change-Id: Ia854b9a52db2b1619fca41a387ce98d7f9f9efe9
While enabling prebuilts in T we hit b/229932396 which was caused by
some parts of the build depending on the prebuilt updatable-media jar
which used to be a full implementation jar but which is now an invalid
jar as the snapshot must not be including implementation details. We
fixed the issue in T but we are hitting the same problem in S with the
M-2022-07.
That is the first train in which the prebuilt updatable-media module
provides an invalid jar, prior to that it was always providing an
implementation jar. This change tweaks the sdk snapshot generation
code to use an implementation jar for updatable-media in the S
snapshot to avoid partners having to cherry pick changes similar to
those needed to fix b/229932396 in T.
Bug: 239121291
Test: packages/modules/common/build/mainline_modules_sdks.sh
# Check that S media snapshot includes implementation jar.
# Check that S art snapshot includes invalid jar.
# Check that T media snapshot includes invalid jar.
Change-Id: Ib49484d00a60b4ed7f8268e04f9c10a3498edb56
Lint is being updated, and some of the
new checks have many failures or false
positives in the current android tree.
Bug: 215567981
Bug: 238784089
Test: Presubmits
Change-Id: I33a47d3c0404ca37f0334421a02bb80f745ae792
In that file, we can list methods which we want to compile but that our
boot image profiling implementation did not cover.
Test: m
Bug: 235557326
Change-Id: I839727c231a09b9208d00f3205996f2add8779bd
The files were added in https://r.android.com/2085466. They do not
affect the build because they are not added to Android.bp.
Bug: none
Test: treehugger
Change-Id: Ibb42212e12249835c569e7d88365344ca599d8f3
Specifying an apex in the apexes propety will cause all the
*classpath_fragments that are contents of the APEX to be automatically
added as members of the sdk and appear in the snapshot.
The purpose of this change is to dedup the APEX and sdk definitions and
try and avoid some of the issues that we have been finding while
attempting to build against the prebuilts.
Two tests, one each for bootclasspath_fragment and
systemserverclasspath_fragment, have been refactored to compare the
output when adding the *fragment to the sdk directly of via the APEX.
That ensures switching to use the APEX will not change the sdk snapshot
unless it was previously missing a *fragment.
There was also a slight difference in where the hidden API flags were
copied from. That should have no impact on the output as the flags are
identical.
The sdk snapshot generation needed some tweaks to avoid generating a
prebuilt for the APEX.
Bug: 232401814
Test: m nothing
Change-Id: I7aaf16a3a0ab4bebf97765d1484215cc008dc4b8
Previously, when targeting the S release the generated sdk snapshot
would contain prebuilt_systemserverclasspath_fragment modules even
though they were only added in T.
This allows SdkMemberTypes to specify the set of target build releases
they support and ignores them when targeting an unsupported target
build release.
Test: m nothing
packages/modules/common/build/mainline_modules_sdks.sh
# Check that the for-S-build snapshots do not include SSCPFs.
Bug: 237718221
Change-Id: I2df08c2fcebf9b866695d691572a9d3783758b17
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
* changes:
Pass -fno-sanitize=vptr,function for musl
Use musl rust prebuilts for USE_HOST_MUSL=true
Don't package host cross modules in javaFuzzPackager
Add rust musl arm and arm64 toolchains
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
This is a partial revert of aosp/541879.
In that cl, the kotlin jvm version was always
set to 1.8 because that's what the kotlin
complier supported at the time, but now
it supports more versions:
$ ./external/kotlinc/bin/kotlinc -jvm-target foo
error: unknown JVM target version: foo
Supported versions: 1.6, 1.8, 9, 10, 11, 12, 13, 14, 15, 16, 17
Bug: 69160377
Bug: 236431222
Test: Treehugger
Change-Id: I273e0b4d1f484013889e17c60bc1b299a3f975a1
Normally the host cross OS is windows, which only builds a few opted-in
modules. When the host cross OS is set to linux_musl it builds all
modules that haven't explicitly opted out, producing linux_musl_common
variants of java modules. Filter these out of javaFuzzPackager to
avoid conflicts with the linux_glibc_common modules.
Host cross common variants targets were missing the HostCross flag,
so also set it in getCommonTargets.
Bug: 236052820
Test: builds with linux_musl arm64 host cross enabled
Change-Id: I58c846076091bee7df50016c240a176c039c42e9
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
Allow listing rust_ffi_shared modules as a jni_libs dependency
in conjunction with platform_api: true. This allows inclusion by
android_app modules.
Bug: 237304791
Test: android_app module builds with a rust_ffi_shared dependency.
Change-Id: I3a28e1baa522ad8f9c2aa86f1d23b19ce9f967e1
The embedded notice file generation for apps was moved below the aapt
rules, which meant the added asset path was ignored. Move the code
to pick the notice file path selection back above the aapt rules,
and leave the code to generate the notice file rule where it is.
Bug: 236006463
Test: m NetworkStack ALWAYS_EMBED_NOTICES=true
Change-Id: I1421fb0dbcdb759281259abfae7bddc9aecdaa56
Merged-in: I1421fb0dbcdb759281259abfae7bddc9aecdaa56
Some targets need to be able to specify the specific architecture for a
data_device_bin module. This commit adds new properties to allow
specification of first, both, 32, or 64 multilib properties.
Bug: 231448797
Bug: 232408185
Test: go test ./java -run TestDataDeviceBinsBuildsDeviceBinary
Change-Id: I457cf4b1a9ccb28b46042f874c96bd0a87009fab
This reverts commit 4e445be558.
Reason for revert: GtsExoPlayerTestCases now uses multidex.
Test: m + manual builds for test_suites_x86_64_coverage
Change-Id: I608b3b79137b216f546446e1c4f89f4542572581
Bug: 192032291
