Previously, this setting environment variable to false reverted to an
OpenJDK 9 toolchain. This change removes that option.
Test: m core-all-system-modules
Test: zcat out/verbose.log.gz | grep 'prebuilts/jdk/jdk[0-9]*'
Test: EXPERIMENTAL_USE_OPENJDK11_TOOLCHAIN=false m core-all-system-modules (fails)
Bug: 131683177
Change-Id: I0d679648e1236925ce3ef7e1652379127e846b00
This reverts commit bf0e47648a.
Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true
is fixed by inspecting the environment variable and not generating
boot image in case it is set.
Dexpreopt artifacts for the libcore part of the boot class path are
now packaged in the ART apex. The system image still contains
dexpreopt artifacts for the full set of boot class path libraries
(both libcore and framework); the libcore part will be removed and
boot image extension will be used in a follow-up CL.
Since this is specific to the ART apex and makes no sense for other
apexes, the implementation adds a boolean flag "is ART apex" rather
than a new apex module property.
Build rules for the new set of dexpreopt artifacts are created using
a new variant of the global boot image config. Previously we had two
variants: "default" (for the system image) and "apex" (for the
JIT-zygote experiment). This patch adds a third "art" variant.
Test: m
Test: m art/build/apex/runtests.sh
Bug: 144091989
Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
This is a counterpart to the existing OVERRIDE_ANDROID_JAVA_HOME,
which is not very useful by itself in a Java module world. All jlink
commands will fail if a user sets OVERRIDE_ANDROID_JAVA_HOME without
setting OVERRIDE_JLINK_VERSION_NUMBER to the corresponding value
(unless they happen to be specifying a different OpenJDK 11
toolchain).
Test: OVERRIDE_ANDROID_JAVA_HOME=my-jdk10 OVERRIDE_JLINK_VERSION_NUMBER=10 m core-all-system-modules (with an OpenJDK 10 toolchain symlinked at my-jdk10 just for testing)
Test: zcat out/verbose.log.gz | grep 'jmod create'
Bug: 131683177
Change-Id: I31542e7f46303bba538d998171a3efe6d0215c7b
The constraint requires the previous_api property to be specified
unless validating nullness. However, there is no reason within the
Soong code why that should be.
The only use of previous_api is as the argument to the metalava
--migrate-nullness option which is only added when previous_api is
specified. So, there is no reason in the Soong code for the
constraint.
Metalava also does not require the --migrate-nullness option to be
specified unless validating nullness. So, there is no reason in
metalava for the constraint.
It is therefore safe to remove the constraint.
Bug: 142113521
Test: m checkbuild
Change-Id: I189071e215e928fdf43a39a03d540732743b7a32
This fixes a bug where unsigned split apks were installed instead of
their signed counterparts.
Fixes: 140795853
Test: app_test.go
Test: m Split && apksigner verify --print-certs
Change-Id: I12cdbcaff9932b6388f920d7e03301d687c3bfdb
This reverts commit 24babe3a66.
Build failures are fixed after reworking the patch:
- 'missing dependencies' on aosp-master-art branch is fixed by
disabling profile generation in case default profile is not
found (it is part of framework absent in aosp-master-art)
- invalid dex2oat invocation should no longer happen after
disabling dexpreopt on targets that do not use default ART config
(fixed in CL If2d4fe2cdcb6a81c7c6d730d18c2b681a74fb0b7)
Dexpreopt artifacts for the libcore part of the boot class path are
now packaged in the ART apex. The system image still contains
dexpreopt artifacts for the full set of boot class path libraries
(both libcore and framework); the libcore part will be removed and
boot image extension will be used in a follow-up CL.
Since this is specific to the ART apex and makes no sense for other
apexes, the implementation adds a boolean flag "is ART apex" rather
than a new apex module property.
Build rules for the new set of dexpreopt artifacts are created using
a new variant of the global boot image config. Previously we had two
variants: "default" (for the system image) and "apex" (for the
JIT-zygote experiment). This patch adds a third "art" variant.
Bug: 143594594
Bug: 143593500
Test: m
Test: m com.android.art deapexer \
&& find $ANDROID_BUILD_TOP -type f -name 'com.android.art.*.apex \
| xargs deapexer | grep boot \
Expect to find javalib/$ARCH/boot*.{art,oat,vdex} files.
Test: m art/build/apex/runtests.sh
Change-Id: Ib37acaec8401bd23c8d547dadf773565406ef448
We were passing "--classpath foo.jar --classpath bar.jar" to turbine,
it now wants (and may always have expected?)
"--classpath foo.jar bar.jar".
Test: m checkbuild
Change-Id: Ib7e0ca64a34e236110f7b785d6a0fb51ed75567e
Silence the dep-ann warnings until there is an effort to do
something about them.
Test: m framework-minus-apex doesn't print dep-ann warnings.
Change-Id: Ic172e840dded4564fecfb91e96cba0c54358e20a
Only if PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE is set,
every app and java library in product cannot use hidden APIs anymore.
checkSdkVersion() checks if sdk_version of app and library is narrow enough,
checkLinkType() checks every library that app links agianst
Bug: 132780927
Test: m
Test: set PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE, and check whether build
error occurs.
Change-Id: Ic630503b875040f730feda4fef826ed6d71da111
Prior to this change, the default was to use and OpenJDK 9 toolchain,
with the EXPERIMENTAL_USE_OPENJDK11_TOOLCHAIN=true environment
variable available to opt into OpenJDK 11. After this change, the
default is to use OpenJDK 11, with
EXPERIMENTAL_USE_OPENJDK11_TOOLCHAIN=false available to opt out.
This change affects:
- The version of javac used.
- The version of javadoc used.
- The version of other tools used during the build process (e.g. jar,
jmod, and jlink).
- For Java bytecode executed on the host, the version of the java
executable used, and so the versions of the JVM and the OpenJDK
libraries in the system module (or bootclasspath).
This change does not affect:
- The Java language level, i.e. the version of Java expected in
source code (the -source option to javac) or the version of Java
bytecode produced (the -target option to javac).
- Anything to do with code execution on the device.
Bug: 131683177
Test: make java droid docs cts tests
Test: zcat out/verbose.log.gz | grep 'prebuilts/jdk/jdk[0-9]*'
Test: make RunBluetoothRoboTests RunCarSettingsLibRoboTests
Test: cts-tradefed help
Test: atest CtsHostTzDataTests
Test: atest CtsLibcoreTestCases
Change-Id: I09dc22f1af4d1f2d7d3b85c08cb0ed9a1105aaca
Merged-In: Iaae89ef25c92ec099575c026fc50e41da4e143e8
Adds reported lint errors to dist. This lets us track them and
build tooling on top.
Bug: 138440867
Test: make dist droid; ls -l out/dist/apilint
Change-Id: I75629e3d9e1a53d161d844dfac121a5998429e04
Dexpreopt build commands should only be generated on targets that
include build/make/target/product/runtime_libart.mk, which sets the
necessary variables such as PRODUCT_SYSTEM_DEFAULT_PROPERTIES that
contain default values passed to dex2oat. This file also sets a
variable PRODUCT_USES_DEFAULT_ART_CONFIG that is used in
build/make/core/dex_preopt.mk to decide if boot images should be
installed.
On some targets build/make/target/product/runtime_libart.mk is not
included. Prior to this patch, on such targets invalid dexpreopt
commands were generated, but not used, so they did not cause any
visible build failures. The invalid commands can be grepped as:
lunch qemu_trusty_arm64-userdebug && m nothing \
&& fgrep -e '-Xms ' $ANDROID_BUILD_TOP/out/soong/build.ninja
In this case '-Xms ' is an ill-formed option passed to dex2oat (the
option expects one argument, but none is passed).
This patch makes the DisablePreopt variable passed from make to
soong more strict: it not only requires WITH_DEXPREOPT, but also
PRODUCT_USES_DEFAULT_ART_CONFIG. This means that dexpreopt commands
will not be generated on targets that do not include
build/make/target/product/runtime_libart.mk.
Test: lunch aosp_walleye-userdebug && m \
&& find $ANDROID_BUILD_TOP/out -name 'boot.art'
# expect to find files in /out/target/product/walleye/system/framework/$ARCH/
Test: lunch qemu_trusty_arm64-userdebug && m \
&& fgrep -e '-Xms ' $ANDROID_BUILD_TOP/out/soong/build.ninja
# expect empty output
Change-Id: If2d4fe2cdcb6a81c7c6d730d18c2b681a74fb0b7
62c7829595c0df53e96addcd347c11ac01012eee introduced the new stem
property to java modules, but it wasn't propagated to Make. Fixing the
problem.
This change also fixes a problem that (module name) == (file name) is
assumed in dexpreopt_config.go, which no longer is the case. A mutator
runs to build a map from module name to its stem. The map is then used
when filling up the file paths in the bootImageConfig struct.
Bug: 139391334
Bug: 143494499
Test: m
Test: BootImageProfileTest
Change-Id: Idbc894f877692401471130de6cbfe5e0dd129da9
This reverts commit d5df949385.
Bug: 143594594
Bug: 143593500
Reason for revert: Some builds are failing.
Change-Id: I69986b472bce39266095e526fcd7ef5f48ece85e
Exempt-From-Owner-Approval: Going back to green.
* changes:
Use java language 1.9 for sdk_version: "current"
Remove special case for sdk_version: "none"
Use system modules for turbine
Make javaVersion an enum
Move TestConfig sdk versions forward
Split java 8 and 9 classpaths in TestClasspath
Java language was set for 1.8 for anything building against the
current SDK because the stubs were not built in Soong, so the
system modules could not be built. The stubs have been built
in Soong since Iabd32b30954b3f4a6d9a779fde52a032b684807e, but
I5e870c34dd0ebc8ae3f888ec627da590c846a76f missed updating
this TODO.
Use 1.9 when building against the stubs, but continue using
1.8 for unbundled builds until we have prebuilt system modules.
Always use the core-current-stubs-system-modules to avoid
splitting android.* packages between the system modules and
the classpath, which would cause new classes in android.*
packages in classpath jars to be ignored. Add a new
java9Classpath field to sdkDep that will contain the stubs jar
when targeting Java language level 1.9, and plumb it through
to javac and turbine. Rename the modules field to bootclasspath.
Bug: 142896162
Test: m checkbuild
Change-Id: Icfd32d0a863b2303a997c7cf03cb3708aade4724
The dependency handling for sdk_version: "none" (which propagated to
!sdkDep.hasStandardLibs()) was very similar to the normal useModule
case. Combine the cases by making decodeSdkDep set useModule: true
and put the system modules in modules for the sdk_version: "none"
case.
Test: TestClasspath
Change-Id: Icc9ff4d43a38da25cc0e3628be95951d61773ad5
turbine supports taking system modules on the command line,
now that we target Java language level 1.9 and use system modules
by default switch turbine to match javac.
Test: m javac-check
Change-Id: Ieee07502151da0d5693bb8929213d495c039106b
Remove the hardcoded checks against "1.9" by making javaVersion
an enum and implementing javaVersion.usesJavaModules().
Test: TestClasspath
Change-Id: I559eeb1f45880bb8177269c6d977ee4dfbadce57
The SDK version in TestConfig is very old, move it forward to trigger
the newer javaVersion code paths.
Bug: 142896162
Test: all Soong tests
Change-Id: Iaf2a6f6dfef43b006b0a09f193fbc2d2e103d90d
In preparation for adding the system modules jars to the classpath
for java 9, split the expected java 8 and java 9 classpaths into
separate fields. Also replace the system: "bootclasspath" special
case with a bool that specifies that the module will always be
built using a java 8 style command line.
Test: TestClasspath
Change-Id: I661ec50d77a039c435c03bc8e6443cc5a57c206e
