Revert submission 3207854-ensure-c-ndk-headers
Reason for revert: Droidmonitor created revert due to b/358445530.
Reverted changes: /q/submissionid:3207854-ensure-c-ndk-headers
Change-Id: I649941a4d063d76a1c6a8e58fb885da2c44331c0
`Jars` property in module_bp_java_deps.json should be relative to the
android build top, and not relative to the Android.bp file
Bug: 356572093
Test: m out/soong/module_bp_java_deps.json and verified that `jars` in
an arbitrary java_import module is relative to android top
Change-Id: Ifc905b14500dfa4254b27505fcc8af8f18349587
The information will be used for IDE autocompletion.
Test: {
"jars": [
"out/soong/.intermediates/prebuilts/misc/common/androidx-test/androidx.test.core-nodeps/android_common/turbine-combined/androidx.test.core-nodeps.jar",
"out/soong/.intermediates/prebuilts/misc/common/androidx-test/androidx.test.core-nodeps/android_common/busybox/R.jar"
],
"path": [
"prebuilts/misc/common/androidx-test"
]
}
Bug: 356572093
Change-Id: I62166c6d5cfa1cf0c49adf42d5d8b4ca40ab5a11
During some migration, I created some modules where the derived module
and base module were in different suites (one was in general-tests, one
was in base-tests).
This had the potential to create dangling symlinks for partial downloads
from the test suites in tradefed.
Bug: b/357880359
Test: go test ./
Test: m nothing
Test: modified a Android.bp with test_module_config to change the suite
to "device-tests" from "general-tests" and got the error as expected:
error: cts/tests/libcore/luni/Android.bp:70:1: module "CtsLibcoreTestCases_dalvik_system" variant "android_common": Suite: [device-tests] listed but does not exist in base module: CtsLibcoreTestCases
Change-Id: Ia8fa991914a47336fc2d0148f066824433db2ecd
Support long classpaths by passing the classpath in a file to the script
that generates build.xml.
Bug: 308016794
Test: builds
Flag: EXEMPT refactor
Change-Id: Ib238a83a26acba7ede8e55298397dbeb9a57a866
A future CL is going to change transitive classpath behavior when
jarjar is enabled. In preparation, split the jarjar rules out
of compileJavaHeader into a separate jarjarIfNecessary method, and
use it on the classes and resource jars too.
Also tweak the naming of the output files in repackageFlagsIfNecessary
to be prettier.
Bug: 308016794
Test: all soong tests pass
Flag: EXEMPT refactor
Change-Id: I2b182cd30631f2bd7925341b9171e6b3c0e8d450
A future CL is going to treat local jars separately from dependency
jars. Rearrange the order of the kotlin standard library jars to
come after the local jars produced by javac, which will better match
the future ordering and ease ninja file comparisions.
Bug: 308016794
Test: all soong tests pass
Flag: EXEMPT refactor
Change-Id: I9ed6a649350451bf1788077752db5222f50c0247
Convert JavaInfoProvider to return a *JavaInfo instead of a JavaInfo.
This will reduce copying when reading the provider, and also allows
JavaInfo to recursively contain a depset of JavaInfos from
dependencies.
Bug: 308016794
Test: go test ./java/...
Flag: EXEMPT refactor
Change-Id: Ibf6d9b797f760ad1fe815d59839839fdfad91733
The list no longer need to be maintained given that `java_sdk_library` modules generate from-text stubs by default.
Change-Id: I18c94731d0a337c8815fd589868377fc8933437c
Test: m nothing
Bug: 276958307
This CL adds moves the installation rules of boot images to soong. This
will eventually allow us to build devices by skipping `katiBuild` and
moving straight to `katiPackaging`
Details
1. Drop `no_full_install` from dex_bootjars singleton. This ensures that
the files installed by this singleton module does not get skipped
when generating the soong installs file (out/soong/installs-*)
2. Replace PackageFile with InstallFile. This registers the installation
rules for both make-built and soong-built images (e.g.
aosp_cf_system_x86_64)
3. Implement `AndroidMkEntries` for dex_bootjars singleton. OutputFile
needs to be non-nil so that this module does not get elided when
generating out/soong/Android-*. `OutputFile` was abritrarily set to one
of the many files installed by this singleton.
Test: no diff in
target/product/vsoc_x86_64/obj/PACKAGING/system_intermediates/file_list.txt
(top of stack)
Bug: 355700341
Bug: 355703904
Change-Id: I3531defa6bba58ef78f6d66e881502a8222fc229
ResourceProcessorBusyBox generates the R.jar binary from R.txt without
creating an intermediate R.srcjar file. Disable this behavior in kythe
builds (ctx.Config().EmitXrefRules()) to support xrefs to R imports
Test: XREF_CORPUS=$internal_corpus m nothing
Test: aninja -t query out/soong/.intermediates/frameworks/libs/systemui/animationlib/animationlib_tests/android_common/animationlib_tests.kzip
Test: verified that an R.srcjar is present in its deps
Bug: 354854007
Change-Id: I2d63c3393c5bc58103c267c4593172ce77fbc79c
https://github.com/android/ndk/issues/1920 recently reported a handful
of NDK headers where C-incompatible syntax had slipped in which wasn't
caught by review. This is also something that we often manually catch
in API review, but the manual inspection is, as can be seen from that
bug, error prone.
This check is pretty stupid. I've tried on other occasions to do a
more thorough check that would build each header using the same flags
as cc_library or similar would, but was never able to get that
working. This isn't as thorough, but that's maybe not such a bad
thing, since it saves on build time to only check on variant. In
practice the rudimentary approach I've taken here would have caught
every instance reported in the bug above, and probably all the other
cases that we'd previously caught in API review as well, so it's
definitely a step in the right direction if not good enough forever.
Bug: http://b/113359184
Test: m ndk
Change-Id: Id4e8cc511413acc61c4f625f25c3004d7439263c
Revert submission 2982300-java_api_library_non_sdk
Reason for revert: DroidMonitor: Potential culprit for b/357648959 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted changes: /q/submissionid:2982300-java_api_library_non_sdk
Change-Id: I5ef7afd9ec3e10ea99f82d02172843ad9b2cfda9
Partner worksapces contain two versions of mainline prebuilts - BigAndroid
and Go. These two prebuilts export dexpreopt'd system server artifacts
to be installed in system image. Since the install paths are same, we
run into duplicate installation rules issue unless one of them is
hidden.
This hiding was previously done by creating a dependendency between
source aosp apex to BA and Go google prebuilts. However, this
implementaion had the unfortunate side effect on the packaging name of
the Google mainline prebuilts - the name becomes the aosp apex name.
Instead of creating the dependency to aosp apex, this CL hides all
mainline apex_set(s) if it has not been flagged using
RELEASE_APEX_CONTRIBUTIONS_*. Since there are some non mainline apex
prebuilts, apex_name will be used to determine whether the prebuilt is a
mainline module.
Test: m nothing --no-skip-soong-tests
Test: In partner workspaces, downloaded the CLs in b/355682304#comment7
Test: m out/target/product/generic/obj/PACKAGING/system_intermediates/file_list.txt
verified that aosp apexes are not installed, but mainline prebuilts are
installed
Test: unset RELEASE_APEX_CONTRIBUTIONS_ADSERVICES to build from source
Test: m out/target/product/generic/obj/PACKAGING/system_intermediates/file_list.txt
verified that aosp adservices is installed, and adservices prebuilt is
**not* installed.
Bug: 355682304
Change-Id: Idacb65313553bdea5c0593976694de478034229e
This works around an incompatibility between coverage and the
-fdebug-info-for-profiling flag.
also moved -fdebug-info-for-profiling flag so that it is only applied to
the libraries that enabled AFDO.
Test: gzip -cd out/verbose.log.gz | grep debug-info-for-profiling
Bug: 345593672
Change-Id: I68493511da1e61091209d0ed1b2c86c7ba0e21f4
As some partitions have build.prop under etc/, this change adds
relative_install_path property to build_prop module. Also this change
adds system_ext related Soong variables and system_ext support in
gen_build_prop.py.
Bug: 322090587
Test: build and compare system_ext/etc/build.prop
Change-Id: I416662b8bae09383af0cdd3d8444a5c300006b7b
The installation rules for soong built system images are generated by
soong, but the installation rules rules for make built images are still
generated by make in dex_preopt_libart.mk. There is an existing
discrepancy between the two. Make built images generates three
installation rules for
1. system/framework/<primary_arch>/$bootjar.vdex (symlink)
2. system/framework/<secondary_arch>/$bootjar.vdex (symlink)
3. system/framework/$bootjar.vdex (actual file)
Soong copies the file to (1), creates a symlink from (2) to (1) and
skips (3) altogether. This CL makes the Soong installation rules match
Make installation rules. This will eventually allow
us to build devices by skipping `katiBuild` and moving straight to
`katiPackaging`.
Test: no diff in make built installed files
target/product/vsoc_x86_64/obj/PACKAGING/system_intermediates/file_list.txt
(top of stack)
Test: debugfs out/target/product/vsoc_x86_64/system/etc/aosp_cf_system_x86_64.img
verified system/framework/boot-apache-xml.vdex exists
verified system/framework/x86/boot-apache-xml.vdex exists as a symlink
verified system/framework/x86_64/boot-apache-xml.vdex exists as a symlink
Bug: 355700341
Change-Id: I52853c07674b77a984b5a5ac5dcd69236b642b46
Also remove the tests in sbom_test.sh for product SBOM generated by Make.
Bug: 324467079
Test: m sbom
Test: m dist
Test: banchan com.android.adbd module_arm64 userdebug && m sbom && m dist
Test: build/soong/tests/sbom_test.sh
Change-Id: Ie3f405f0a09a3b1f1176dba67167773801b9337a
It doesn't need to be a Makefile variable exported from Soong as it's
hard-coded.
Bug: 353429422
Test: boot shiba with SANITIZE_TARGET=hwaddress
Change-Id: I4a98eaaf1002aa7aba5d5131ff251bdcbdd2e0ef
* changes:
Revert^6 "Use Soong-built system/build.prop"
Revert^6 "Sync gen_build_prop.py to sysprop.mk"
Revert^2 "Conditionally pass kernel version to build.prop"
Revert^6 "Add TARGET_SYSTEM_PROP to system build.prop"
Revert "Revert "Revert^2 "Set output for build_prop even on Soon..."
Resource_dirs is queried using PathsWithOptionalDefaultForModuleSrc,
which includes all the infrastructure to resolve module references,
but needs to be tagged android:"path" to be able to add the module
references as dependencies.
Test: Manually
Change-Id: Ie3f75332c9a4cc0ee4b4c93268188440ff7ce249
