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
Move overrides attribute from appProperties to overridableAppProperties
Bug: 220029162
Test: m
Change-Id: I6f527df3173f142311734333ad37018c83d5e279
Merged-In: I6f527df3173f142311734333ad37018c83d5e279
(cherry picked from commit a2ce78f80d)
Needed to allow change https://r.android.com/2089503 to be reapplied.
Bug: 232106778
Test: Apply the change and then run
m EMMA_INSTRUMENT=true nothing
Change-Id: I92d19c51cc828295ba13951e65911db707f0f2ba
Test: b build --platforms=//build/bazel/platforms:linux_x86
//external/jarjar:jarjar-binary and try to use on a jar
Change-Id: Id6f4e6937687fd575360fbacaeda55c41922636e
- 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
These two databases are (nearly) identical but the latter is generated
in a much more efficient way.
The diffs are very minor and it's not clear to me which versions is more
correct than the other, though I'm fairly confident they don't matter.
https://paste.googleplex.com/5567994005553152
Bug: 187398174
Test: diff api-versions.xml
Change-Id: I0fa35d4067bc06936b4a31bda0bca7fd41f26aae
Metalava has two different flags surrounding api-levels:
- one for generating api-versions.xml to a file
- one for applying api-versions.xml from a file
Previously, soong always applied both of these arguments at the same
time, such that framework-doc-stubs both generated and applied
api-versions.xml.
Add support for using api-versions.xml from another module name as well.
Bug: 187398174
Test: droidstubs_test.go
Change-Id: I8288fe4788336d5d5c60d09d48b00ca111449fba
The framework-doc-stubs annotations.zip is no longer the correct
zip to use after b/187397779. It doesn't contain the module annotations.
Test: presubmit
Change-Id: I50e0bcc026c97886a31256e2387632c19d4b287f
Soong does not write AndroidMk output if the default outputfile is
invalid. The default output file for droidstubs modules is the srcjar,
but not all droidstubs modules have srcjars. Make it also write
AndroidMk entries for droidstubs that only have an api-versions.xml
output.
A similar exception already existed for the api txt files, so use the
same mechanism.
Bug: 187398174
Test: m nothing && grep Android-${TARGET_PRODUCT}.mk
Change-Id: I5cbcf42d877ca166d172b727c0aa2bdf6d9af744
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
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
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
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
This CL also converts `external/rappor` (which already set `java_version` to `1.7`) to be bazelable to testify the changes.
Results from `b build //external/rappor && cat bazel-bin/external/rappor/librappor.jar-0.params`: https://paste.googleplex.com/5518725462622208.
Test: go test ./bp2build/...
Bug: 227618664
Change-Id: I8d370d4639f70fba51e6de6ceb7bcb5ace9ccd91
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).
Change-Id: Ie0f68482603adc7b4e3d7a5c81bf203d81a84a9e
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.
Change-Id: I9e1837edcca6f5fa84fc611274cf8fbba8a896b8
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
- 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
Change-Id: I8ef3137394011fb679a1129f80f6351fb05a4eff
- 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
