This applies to updatability attributes of shared libraries.
Bug: 235318264
Test: atest UpdatableSharedLibsTest
Change-Id: Id2c2b769a99ca1debb5d8525e46d37698ef2fc6c
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
Merged-In: I457cf4b1a9ccb28b46042f874c96bd0a87009fab
AndroidApp had its own HideFromMake method and flag that shadowed
the one in ModuleBase. This caused performOverrideMutator to set the
AndroidApp flag, but ModuleBase.skipInstall to read the ModuleBase
flag, resulting in a conflicting install rule being created. Remove
AndroidApp's HideFromMake in favor of the ModuleBase one.
Bug: 232788722
Test: TestOverrideAndroidAppWithPrebuilt
Change-Id: I8c0dfcb50ff4dc1e4d0574f150b10d79908f46aa
Merged-In: I8c0dfcb50ff4dc1e4d0574f150b10d79908f46aa
(cherry picked from commit aaa0c1ffcd)
- Update apex_info (a topdown mutator) so that it sets updatable=true on
apps of updatable apexes
- Write a unit test that tests different combinations of
updatable/non-updatable apks-in-apexes
- Update an existing unit test that asserts a different error
Test: go test ./java
Test: m nothing (in internal)
Bug: 209409604
Change-Id: Ie8881b857afcec44addf27fc360c5b8abf726bd2
Merged-In: Ie8881b857afcec44addf27fc360c5b8abf726bd2
(cherry picked from commit 42e89508ee)
With aosp/1640364, all variants of a cc_* module use min_sdk_version as
the version part of the clang triple. Therefore, checking
min_sdk_version of jni_libs should be sufficient to ensure that there is
no unintended access to symbols in newer Android versions
Test: go test ./java
Test: TH
Bug: 155209650
Bug: 209409604
Change-Id: I6c064f8a6ea12c8aa40165a9063380306a180c9b
Merged-In: I6c064f8a6ea12c8aa40165a9063380306a180c9b
(cherry picked from commit 2e8c044b2c)
Make sure we select the proper API level number for the REL
platform version when generating the classpath protos
Bug: 231272086
Test: build + boot emulator
Change-Id: Ib3b711dc05dd6136a68e6de414d806687a849bc9
The kapt rule uses kotlincFlags but was not using kotlincDeps,
causing the rule to get the -Xplugin argument on the compose
compiler plugin jar, but not have a dependency on it.
Bug: 231222079
Test: TestKotlinCompose
Change-Id: I4c2cf30fb7d8cad4eededa29f67f4ffd459caa41
(cherry picked from commit 08b0a1cd79)
Merged-In: I4c2cf30fb7d8cad4eededa29f67f4ffd459caa41
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.
Change-Id: Ic95cf11a05f59b67e623474ed3dd9be6b4442c42
- Making newapi disabled by default will ensure that this lint check
does not run on the platform. This prevents noisy lint warnings like b/228956345#1
- This lint check will continue to be enforced on the transitive deps of
apexes, since lint.strict_updatability_linting will be true for those
Soong modules
Test: TH
Test: m
out/soong/.intermediates/frameworks/base/services/core/services.core.unboosted/android_common/lint/lint-report.xml
// file no longer contains "Call requires API level ..." warning
Bug: 228956345
Merged-In: I8ef3137394011fb679a1129f80f6351fb05a4eff
Change-Id: I8ef3137394011fb679a1129f80f6351fb05a4eff
(cherry picked from commit 397e910835)
- 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
Merged-In: Ic408857db7760d912ef4694d2ed72c0b7106eb04
Change-Id: Ic408857db7760d912ef4694d2ed72c0b7106eb04
(cherry picked from commit ba7e532a11)
The Q and R runtimes can handle Q/R flags but not S flags. So, this
change verifies that any library that can run on Q/R
(min_sdk_version <= R) by adding --max-hiddenapi-level=max-target-r
to the "hiddenapi encode" command. That will cause a failure if any
S+ flags are found in the flags to encode.
Bug: 172453495
Test: m droid && launch_cvd
Cherry pick changes in https://r.android.com/q/topic:max-target-s
Add @UnsupportedAppUsage maxTargetSdk=S in classes in framework-permission (for r/q)
and framework-permission-s (nominally for S+). I had to incresed the min_sdk_version
in the latter to 31 (S) as it was still set at 30 (R).
Merged-In: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
Change-Id: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
(cherry picked from commit 09817d66de)
Bug: 230846030
Test: m nothing
# Cherry pick into build with prebuilts enabled to verify.
Merged-In: I5ac9b1cdd2fc61efbc988e84556202ff6cd57146
Change-Id: I5ac9b1cdd2fc61efbc988e84556202ff6cd57146
(cherry picked from commit 1e940d5b44)
(cherry picked from commit 77590a8263)
The framework-media java_sdk_library is currently api_only for legacy
reasons. This change allows it to also build the framework-media.impl
library by making the following changes:
* Adds impl_only_static_libs to allow the implementation to statically
include other libraries, something no other java_sdk_library has
needed to do.
* Passes the apex_availability property through to the impl library so
it can be statically included in the updatable-media which is what is
included in the apex, again for legacy reasons.
Bug: 190807367
Bug: 229932396
Test: m com.android.media media-module-sdk
# Compare before and after this change (and corresponding change
# to updatable-media/framework-media.
Merged-In: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
Change-Id: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
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
Metalava increments the SDK level by one when it's not "REL", so we
temporarily force the build to be "REL" while we're still in the
process of finalizing it.
This CL must be reverted as part of actually declaring "REL".
Bug: 171506470
Test: Build
(cherry picked from commit 05597c0cc4)
Change-Id: I18405cdd27769598f5e7a6a968f0dd473f936f6c
Previously, the build applied the same filtering to remove
implementation details from the sdk snapshot's stub-flags.csv file as
it did for its all-flags.csv, i.e. removing the signatures that only
had a "blocked" flag. Unfortunately, that had no effect on the stub
flags as the implementation signatures had no flags, not a single
blocked flag. That meant that the sdk snapshot's
filtered-stub-flags.csv file contained a lot of implementation details.
This change removes signatures from stub-flags.csv that have no flags
which removes all implementation details from the sdk snapshot.
Bug: 194063708
Test: atest --host verify_overlaps_test
m out/soong/hiddenapi/hiddenapi-flags.csv
m art-module-sdk
# Check contents of its filtered-stub-flags.csv file
Change-Id: I30edc77348fad118ea732e787ae8e206c8841f84
Getting the first certificate will panic if there are no certificates,
which can happen when AllowMissingDependencies is set and the
certificate property is a module reference to a missing module.
Only get the first certificate if the list is not nil.
Bug: 228379411
Test: TestAppMissingCertificateAllowMissingDependencies
Change-Id: I046d75dbbd4f21f4a2b6851f558e430e9879fcff
The proguard test files are duplicated in apex and sysprop and will
be needed by app tests, move them to the java package.
Test: run all soong tests
Change-Id: Ie13817dcda8d98801d16a97ffceef1100c7d5380
Some java_* modules contain .logtag files in their srcs, but we should
separate these out into their own targets.
Test: enabled QuickSearchBox and build
Change-Id: I595722ca59686d450ff522987a15ce283d3607e0
Previously, verify_overlaps used positional arguments, the first was
the monolithi flags and the rest were the module flag pairs (filtered
flags file and signature patterns file). This change makes them use
named options to make the purpose of the arguments clearer on the
command line.
Bug: 194063708
Test: atest --host verify_overlaps_test
m out/soong/hiddenapi/hiddenapi-flags.csv
Change-Id: Ife0af0016eb0f91416e8330d5d98cb53c97d68a4
