AAPT2 is used everywhere now, remove support for AAPT1. Also
removes dpi_specific_apk.mk, it was never updated to use AAPT2
and has been generating bad APKs (resource ID mismatch between
the dex files and the resources) since AAPT2 was made the default
in May 2018 (I9b67fd2a9b3234798b2aac879b5242c2097b3863).
Bug: 80450981
Test: m checkbuild
Change-Id: I2ff768897360ff866dbae5562455bab22be270f7
To solve AIDEGen issue: DocumentsUI have no dependency libcore.
Bug: 122557164
Test: 1. m `build/soong/soong_ui.bash --dumpvar-mode PRODUCT_OUT`/module-info.json
2. open $ANDROID_PRODUCT_OUT/module-info.json
"out/target/common/obj/JAVA_LIBRARIES/core-lambda-stubs_intermediates/classes-header.jar",
"out/target/common/obj/JAVA_LIBRARIES/core.platform.api.stubs_intermediates/classes-header.jar",
"out/target/common/obj/JAVA_LIBRARIES/ext_intermediates/classes-header.jar",
"out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes-header.jar"
will be added to DocumentsUI's dependencies.
Change-Id: I6b20c315f3367ff2a016d305ec6fe2a8de620a14
The impl lib name of java_sdk_library is changed to {module_name}.jar
instead of {module_name}.impl.jar
Bug: 110404779
Test: m -j
Change-Id: I275cd40e3682640b96425e56698cea770888cbb1
Merged-In: I275cd40e3682640b96425e56698cea770888cbb1
(cherry picked from commit 0372f189ac)
Mainline modules are tightly coupled to the platform, and should
build against the current SDK from source and not prebuilts. Add
a flag UNBUNDLED_BUILD_SDKS_FROM_SOURCE to specify that a
TARGET_BUILD_APPS build should build the current SDK instead of
using the prebuilts.
Bug: 121194841
Bug: 121231426
Test: no change to out/build-aosp_sailfish.ninja
Test: forrest unbundled build
Test: forrest master apps build
Test: forrest mainline modules build
Change-Id: I9ebc08745409a817d831817cb282aba1de6d81bb
This fixes a bug where cross host OS notice dependecies were incorrectly
added and caused missing file errors.
Bug: 36073965
Test: Manual build + inspection
Change-Id: I3983ad6158acf939842f836fe3f44cecf9187087
Protobuf 3.5.2 does not natively support lite protos, instead they
are generated by the protoc-gen-javalite plugin compiled from
external/protobuf-javalite.
Bug: 117607748
Test: m checkbuild
Change-Id: I166d55111435762f099503db83c1a658f78e98e9
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
Colin Cross