The previous PATH=$PATH:out/... logic was incorrect, since the version
in $PATH would override the one out. And now that we're limiting what's
accessible via $PATH, that caused an error.
Instead, ensure that all protoc plugins are specified explicitly with
--plugin, then remove the PATH modification.
Test: cd frameworks/base/cmds/am; mma (with protoc-gen-javastream in $PATH)
Change-Id: I6690727504f67f84fdc95ed93eabdf3351e5cb0b
Soong doesn't support LOCAL_JNI_SHARED_LIBRARIES yet, add it to the
problems list.
Bug: 80095087
Test: examine soong_to_convert.txt
Change-Id: I44f7a486b1e9de276416f74a4cb2b7f4eafce4ef
Track transitive static dependencies of native binaries, and
and direct and transitive static dependencies of java and app
modules.
Bug: 112331930
Test: m checkbuild
Change-Id: I0e19971033d6254bfbb6555f0e68fd5e529569c6
Run ErrorProne as a processor in javac from OpenJDK9.
Bug: 69485063
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I2dde597430b47c440df22d248809233a6ade1625
A java module exports SDK library names that it is using directly or
indirectly via its dependencies. Manifest fixer uses the SDK lib names
to automatically add <uses-library> tags for the apk.
The SDK library names are exported via exported-sdk-libs file in make.
From Soong, they are exported via LOCAL_EXPORT_SDK_LIBRARIES flag.
Bug: 77575606
Test: m -j
Change-Id: I4e7a9bdc5bf845af85168abf55f8063900bacc72
LOCAL_PRIVATE_PLATFORM_APIS := ture means that the apps or packages can
use the private API. So, if LOCAL_PRIVATE_PLATFORM_APIS := true, they
are linked to ".impl" instead of ".stub".
Bug: 77577799
Test: build
Change-Id: I782e52078bb8c4139c3a24862cb381f6a84e53fe
There was a bug that when an unbundled app is built without SDK
(LOCAL_SDK_VERSION isn't set), it is linked to the nonexisting stubs
library from java_sdk_library. The built stubs libs are not created for
unbundled builds. For unbundled builds, we need to use the prebuilt
stubs lib.
Bug: 77575606
Test: m -j
Test: make -j dist
ANDROID_BUILDSPEC=vendor/google/build/app_build_spec.mk
Change-Id: I70cced1c872053e151fea157e3a6d218b1fab9dc
Building with FORCE_AAPT2=true will turn on AAPT2 for all modules
unless they set LOCAL_USE_AAPT2 := false. The build system will
attempt to rewrite common AAPT patterns into AAPT2 patterns,
including removing --extra-packages for support library packages,
removing LOCAL_RESOURCE_DIR point to support library resources,
adding a default empty manifest file if it doesn't exist, and
converting LOCAL_STATIC_JAVA_AAR_LIBRARIES to
LOCAL_STATIC_ANDROID_LIBRARIES.
Bug: 79481102
Test: m checkbuild
Change-Id: I8d9d55fe4d5d5c965c64b0407efe74e0afc35c3a
They should be depended on by specifying LOCAL_SDK_VERSION. Depending
on them directly makes it difficult to rename or modify these targets,
as I've found when working on b/77525052.
This list can be further extended to other libraries that should not
be depended on directly.
Bug: b/77525052
Test: make
Change-Id: I911bcc8a5a90995b3607599388dc6119eb88ea96
When an sdk lib name (a module defined with java_sdk_library{...}) is
listed in LOCAL_JAVA_LIBRARIES or LOCAL_STATIC_JAVA_LIBRARIES, the name
is translated to the stubs lib name of the sdk lib.
We have to support this at least until all existing references to sdk
libs are all correctly converted to LOCAL_SDK_LIBRARIES.
Bug: 77575606
Test: m -j
Change-Id: I8cff668afd6b5f265cc7ae6fe6f5fa36b76b8334
When a module built with LOCAL_SDK_VERSION := test_current, then
it is linked against test variant of the sdk stubs library.
Bug: 77575606
Test: m -j
Change-Id: I08ce120d8e4774722a95bfc4e200ad7d123abc70
Resolve these using the naming scheme from sdk_library.go, added
in I4a4ccf6e730e041703c63bb275d8860d0de96887.
Also re-write the LOCAL_SDK_VERSION logic, as it was becoming a
real mess.
Bug: 77575476
Test: With uiautomator in a follow-on CL
Change-Id: I11bd10c02df3d458a4ed6de90114e27fabe8d9e0
This new variable allows specifying libraries like this:
LOCAL_SDK_VERISON := 25
LOCAL_SDK_LIBRARIES := org.apache.http.legacy,
which would automatically pick up the prebuilt OAHL prebuilt
from prebuilts/sdk/25/public/org.apache.http.legacy.jar
Test: In master with uiautomator.
Bug: 77575476
Change-Id: Id8d92176f5b608c2bcea622b6aed4aa27c32e000
I'm making some changes to it, and found the names are scattered
in various places. Make a macro and re-use the logic instead.
Bug: 77525052
Test: make droid
Change-Id: I0f2da80b8b4d427353509b27ec720d024eee7a6e
Move java renderscript support to java_renderscript.mk in
preparation to moving it before aapt. Filter *.rs files
out of LOCAL_SRC_FILES and forbid them in java_common.mk
so that using *.rs files is an error if java_renderscript.mk
was not included.
Bug: 73885582
Test: m checkbuild
Change-Id: Ib37ce89daee58b025dec98f733c5a08149641afd
Merged-In: Ib37ce89daee58b025dec98f733c5a08149641afd
(cherry picked from commit 71822d6fb9)
Allow java modules to take jars containing .java files as an input.
For turbine, pass them directly to turbine. For javac, extract them
to a directory and pass a list of the files to javac.
Bug: 73885582
Test: m checkbuild
Change-Id: Ib4351a5b4b165a55e5fb02ee2680466db368983a
Merged-In: Ib4351a5b4b165a55e5fb02ee2680466db368983a
(cherry picked from commit 11e2d55c0f)
RS_FILES and AIDL_FILES were used for cleaning up the intermediate
src dir, but are no longer used after
If7529979de6fa62a651933a3a974f47b033851d6 and
I01feff7cc399ac5b88b83333a1ac86928d0a81e6.
Bug: 73885582
Test: m checkbuild
Change-Id: If2653f846b568fd2587c8e055ef820e17760f133
Merged-In: If2653f846b568fd2587c8e055ef820e17760f133
(cherry picked from commit c3e7074df1)
The aapt flags were being set in java_common.mk, which is used by
various entry points. host_dalvik_java_library.mk and
host_java_library.mk, and java_library.mk don't support aapt, only
package_internal.mk and static_java_library.mk do. Move the aapt
flags into aapt_flags.mk, and include it from package_internal.mk
and static_java_library.mk.
Bug: 73885582
Test: no change to build-${TARGET_PRODUCT}.ninja
Change-Id: I124393846d37b9bbc941272cce4274121ac235ef
Merged-In: I124393846d37b9bbc941272cce4274121ac235ef
(cherry picked from commit b6013af085)
PRODUCT_AAPT_FLAGS was removed by Iacc914114616b5bd19d9a1011802f4f9bca9bc19,
remove one more that it missed.
Bug: 73885582
Test: m checkbuild
Change-Id: I31ea4954f5af5af37f13210925ed5d622625d71b
Merged-In: I31ea4954f5af5af37f13210925ed5d622625d71b
(cherry picked from commit 8dad6c62d4)
Move java renderscript support to java_renderscript.mk in
preparation to moving it before aapt. Filter *.rs files
out of LOCAL_SRC_FILES and forbid them in java_common.mk
so that using *.rs files is an error if java_renderscript.mk
was not included.
Bug: 73885582
Test: m checkbuild
Change-Id: Ib37ce89daee58b025dec98f733c5a08149641afd
Merged-In: Ib37ce89daee58b025dec98f733c5a08149641afd
(cherry picked from commit 71822d6fb9)
Allow java modules to take jars containing .java files as an input.
For turbine, pass them directly to turbine. For javac, extract them
to a directory and pass a list of the files to javac.
Bug: 73885582
Test: m checkbuild
Change-Id: Ib4351a5b4b165a55e5fb02ee2680466db368983a
RS_FILES and AIDL_FILES were used for cleaning up the intermediate
src dir, but are no longer used after
If7529979de6fa62a651933a3a974f47b033851d6 and
I01feff7cc399ac5b88b83333a1ac86928d0a81e6.
Bug: 73885582
Test: m checkbuild
Change-Id: If2653f846b568fd2587c8e055ef820e17760f133
The aapt flags were being set in java_common.mk, which is used by
various entry points. host_dalvik_java_library.mk and
host_java_library.mk, and java_library.mk don't support aapt, only
package_internal.mk and static_java_library.mk do. Move the aapt
flags into aapt_flags.mk, and include it from package_internal.mk
and static_java_library.mk.
Bug: 73885582
Test: no change to build-${TARGET_PRODUCT}.ninja
Change-Id: I124393846d37b9bbc941272cce4274121ac235ef
It has been allowed that a java module built with Android SDK or System
SDK to link against other java module built with broader API surface.
For example, an app that is building with SDK (LOCAL_SDK_VERSION :=
current or <number>) can link libs like telephony-common or bouncycastle
which are built without SDK but in fact exposing private APIs.
From now on, this is no longer allowed because it prevents the app from
being unbundled. In general, a Java module A cannot be linked to Java
module B if B is built with broader API surface than A.
Bug: 69899800
Test: m -j checkbuild on walleye, sailfish, and crosshatch
Test: m -j ANDROID_BUILDSPEC=vendor/google/build/app_build_spec.mk
Test: ./vendor/google/build/build_test.bash --dist
Change-Id: Ibfdb1a6777f4e0606927d834d56f808639eb91f0
PRODUCT_AAPT_FLAGS was removed by Iacc914114616b5bd19d9a1011802f4f9bca9bc19,
remove one more that it missed.
Test: m checkbuild
Change-Id: I31ea4954f5af5af37f13210925ed5d622625d71b
The module name of system_$(VER) prebuilt file is system_sdk_v$(VER).
But this is inconsistent with sdk_v$(LOCAL_SDK_VERSION) in prebuilts/sdk.
So, system_sdk_v$(VER) is changed to sdk_vsystem_$(VER) to use the same
naming policy.
Bug: 72031391
Test: build
Change-Id: I379c0f9aa0de7407489eeec2b07ee7727e81d69d
core_current is a pseudo SDK version which is a core Java API subset of
the Android API. It is expected to be mainly used for external Java
projects which are agnostic to Android; such as junit, guava, etc.
A module built with this SDK version can only link to java modules of
the same kind. It can't depend on modules built with LOCAL_SDK_VERSION
:= current or without LOCAL_SDK_VERSION.
Bug: 72206056
Test: m -j
Change-Id: I34a9696393aa6704fd6684a40ea5b05d3fb46b23
When building with OpenJDK 9's javac with -source 1.9 -target 1.9,
a runtime image (with system modules) is used via the --system
command line flag, instead of --bootclasspath.
The runtime image only contains the default libraries (libcore)
but is missing other libraries that might be on the bootclasspath
for a particular build target.
This CL fixes compilation for this case by adding the missing
jars onto the classpath instead.
This already used to work but was broken by CL [1]. I attempted
to conditionally revert some of that CL's changes to java_common.mk
for the case of language level 1.9, but couldn't get it to work.
Therefore this CL follows a different approach.
[1] http://r.android.com/519552
Bug: 38177569
Test: Treehugger
Test: Ran "EXPERIMENTAL_USE_OPENJDK9=true make checkbuild docs"
and spot-checked some javac invocations to confirm that the
system modules libs were not included in the bootclasspath,
but other libs were.
Change-Id: I48fd11aac9b310bfa58dee0f9cfb3ef33f10bca8
Specifying this option causes the make target's sources
and classpath dependencies to be patched into the specified
module via --patch-module (if the build toolchain implements
the module system, ie. when targeting 1.9). This allows tests
to compile that have classes in packages under test.
Currently, only java.base is on the module path (everything
else is on the classpath), and only when using -target 1.9
(ie. EXPERIMENTAL_USE_OPENJDK9=true).
Bug: 71699916
Test: Treehugger
Test: Checked that I was able to compile some ojluni & icu
test sources that had classes in (libcore) packages
under test.
Change-Id: I044fb9d904754ed281f574ab3dd52235cf0d7fec
Host (as opposed to hostdex) tools compile and run against OpenJDK's
core libraries. Before this CL, the core libraries of the default
toolchain were always used, even when targeting an earlier language
version.
This meant that code that uses APIs from a later version of OpenJDK
than corresponded to LOCAL_JAVA_LANGUAGE_VERSION would compile, but
would fail to run under that earlier version of OpenJDK. It also
meant that calls to existing APIs might be reinterpreted; for
example, the return type of java.nio.ByteBuffer.clear() changed from
Buffer in OpenJDK 8 to ByteBuffer in OpenJDK 9. At compile time, this
was noted via the warning:
bootstrap class path not set in conjunction with -source 1.8
After this CL, when targeting a language version <= 1.8 (which is
always the case when building with OpenJDK 8), some of OpenJDK 8's
core library/tools jars are now passed on the bootclasspath. The
decision to include the bootclasspath argument when building with
OpenJDK 8 was somewhat arbitrary, but has the advantage that we
discover any issues before we switch to OpenJDK 9.
Even when compiling with OpenJDK 9, use of OpenJDK 9 APIs will now
fail at compile time rather than at runtime; calls to existing APIs
will now be interpreted in OpenJDK 8 rather than 9 fashion. For
example, this means that dx and host-side CTS tests built with
OpenJDK 9 javac -target 1.8 will be runnable under OpenJDK 8.
Bug: 70521453
Bug: 70862583
Test: Checked that the bootclasspath argument was passed
in the javac invocation targeting 1.8 during:
make showcommands compatibility-common-util-hostsidelib
Test: make checkbuild
Change-Id: I9b6081edfdd2c3e9a450ae8a39c4e32c3d2cda92
With LOCAL_PROTO_OPTIMIZE_TYPE set to one of the lite variants, the build system thinks
the proto should be compiled with lite, and will link in the line runtime libs. But if
the .proto files don't contain the directive to compile the source as lite
(option optimize_for = LITE_RUNTIME;), then the generated code will be full and the
libraries will be full, and it won't link.
Test: make
Merged-In: Ib8a135218d62fa42fa6448c49c97f7aeb2755c42
Change-Id: Ib8a135218d62fa42fa6448c49c97f7aeb2755c42
Fix the build error when TARGET_BUILD_APPS is set
Bug: 67724799
Test: m -j TARGET_PRODUCT=full TARGET_BUILD_APPS=TVTestInput
Merged-In: I981b0a245d7e8f2dabbd4e51db52d17aeacc6106
Change-Id: I981b0a245d7e8f2dabbd4e51db52d17aeacc6106
(cherry picked from commit 8e7a4c413f)
The system_$(VER) can be set in LOCAL_SDK_VERSION, and the apk will use
android_system.jar at build time.
If LOCAL_SDK_VERSION is not defined and this module is installed in
vendor.img, LOCAL_SDK_VERSION is set to system_current.
Bug: 67724799
Test: 1. build && run on taimen
2. LOCAL_SDK_VERSION:=system_27 in ims.apk && build ims.apk && check
the vsdk_v27_intermediates.
Merged-In: I5b11c78b8fcd4a2f2a5e3b141527cd34dbe80018
Change-Id: I5b11c78b8fcd4a2f2a5e3b141527cd34dbe80018
(cherry picked from commit ef212cbe8d)
This allows modules to specify that they may only be used from modules
using aapt2. Using aapt2 removes absolute path references to modules, so
this can be useful if a module is preparing to move its sources, or
replace itself with a prebuilt aar.
Test: m
Test: Label frameworks/support/design; m
Test: Label frameworks/support/v4; m
Test: build/soong/build_test.bash
Change-Id: Icfb3d4b19a6a0e3a3bb00091d2a97a4d88c0c761
This CL topic breaks the single flag value EXPERIMENTAL_USE_OPENJDK9
into two flags USE_OPENJDK9 and TARGET_OPENJDK9 which are computed
independently in config.mk and config.go; this means that later
build logic no longer depends on / duplicates the semantics of an
unset EXPERIMENTAL_USE_OPENJDK9, because that later build logic
can use USE_OPENJDK9 and TARGET_OPENJDK9 instead. Thus, it becomes
slightly easier to change this default in future CLs (touching
only config.mk and config.go).
It also makes it more straightforward to convert .mk files
to .bp.
This CL also introduces a new allowed value "false" for
EXPERIMENTAL_USE_OPENJDK9. This fourth possible value currently
has the same semantics as a default/unset
EXPERIMENTAL_USE_OPENJDK9, but allows people to explicitly
switch back to the old semantics when the default changes.
Test: make showcommands core-oj (in environments with
EXPERIMENTAL_USE_OPENJDK9 set to "", "1.8", and "true").
Bug: 38177295
Change-Id: Iaade9610b237722e5d175143808b8653b1e98996
When LOCAL_SDK_VERSION is not set, frameworks.jar is put
in the classpath for javac. If it is also in the classpath
(as opposed to the bootclasspath) for desugar then desugar
tries to rewrite classes that implement interfaces with
default methods to contain calls to the generated companion
classes for those interfaces. frameworks.jar will not
contain the companion classes, which causes proguard to
fail.
Move frameworks.jar to the bootclasspath, which matches more
closely with builds against the SDK stubs jars.
Also remove the static libraries from the classpath, they have
already been merged into the input jar.
Test: m checkbuild
Change-Id: If30943efcaea44b2db1b38a6c1d558113324757f
Soong has support for building system modules. Use the directories
produced by Soong with --system to replace -bootclasspath arguments
when using javac -target 1.9.
Since soong can't generate current SDK stubs yet, and no existing
SDK stubs need -target, only use -target 1.9 for modules that are
not compiling against the SDK. That means in practice the only
system modules that will be used for now is the default one,
core-system-modules.
Bug: 63986449
Test: m -j EXPERIMENTAL_USE_OPENJDK9=true makes some progress
Change-Id: I350ef50aedf36fdd72458c23d4fe8a2edf1a9a02
