patch_module is currently only used for non-host targets, although
there's a slim chance that there might be use cases on host in
future.
Currently, the only use case is patch_module: "java.base" in
device targets. To avoid erroneously carrying the patch_module
attribute over into the host version of the target, this CL
lets them place it into the target: { android: { ... } } block.
Test: Treehugger
Test: EXPERIMENTAL_USE_OPENJDK9=true make android-icu4j-tests
Bug: 115604102
Change-Id: If025d503d9c5681748a502a1d7433e8dbec3cac1
- Register a singleton and implement GenerateBuildActions func in java/jdeps.go.
- Declare a interface and a struct to collect info in android/module.go.
- Implement IDEInfo for Library & Import module in java/jdeps.go.
- Implement IDEInfo for Genrule module in genrule/genrule.go.
- Implement IDEInfo for fileGroup module in android/filegroup.go.
- Test codes for jdeps.go in java/jdeps_test.go.
Bug: 111044346
Test: export SOONG_COLLECT_JAVA_DEPS=1;mmm packages/apps/Settings
out/soong/module_bp_java_deps.json will be generated
Change-Id: If61da77b4d7614c2c5da438b6af4c725ceccc5c3
Add a new sdk_version "core_platform_current"
value to java_library.
This adds the ability to compile system code against the
core platform API stubs. These stubs will contain the public SDK
API _and_ a selection of extra methods just intended
for use by system code (e.g. framework .jar) and
which must be preserved if "core" is modularized to
retain source and binary compatibility. Methods
outside of the core platform API must not be relied upon.
Future changes will adding methods to the core platform API and
switch targets over to use the stubs.
As soon as feasible, (hopefully) the default for when
unspecified will be changed to be the same as specifying
core_platform_current and build rules will have to explicitly
specify when they want to compile against the core library
implementation directly.
Bug: 113148576
Test: mmm libcore/mmodules/core_platform_api_client_demo
Change-Id: I72a03f28a4c38b4232e513a088c2d4e962c98868
Some logic in java.go was conditional on TargetOpenJDK9(), which in
turn relies on a global build flag (EXPERIMENTAL_USE_OPENJDK9=true).
This CL changes the logic in collectBuilderFlags() to check for
javaVersion greater or equal "1.9" instead, which is true when either
EXPERIMENTAL_USE_OPENJDK9=true (global) or javaVersion "1.9" (a
per-build target attribute).
Because the value of flags.javaVersion isn't available there,
TargetOpenJDK9()-dependent logic in Module.deps() was changed to
be unconditional; as far as I understand, this means that system
modules deps will be built regardless of whether they're needed
later in the build. This will probably slow down the build
unnecessarily until the first user of these system modules appears
(expected soon), but probably not by much.
There is some TargetOpenJDK9() related logic remaining in droiddoc.go,
but this doesn't seem to break the build of Java 9 language sources
and is probably no longer needed now that metalava is used for
generating the stubs (thanks to Nan!), and those do not contain any
Java 9 language features.
Bug: 112443425
Test: Checked that Java 9 language support works on AOSP after
this CL without a need for EXPERIMENTAL_USE_OPENJDK9=true,
ie. after also patching CL http://r.android.com/646840 ,
"make docs droid cts" completes, the device boots and
Java9LanguageFeaturesTest passes.
Change-Id: I393b97a7b3bb4c1c3d06580c639e94ff6cf916ff
I'm adding a annotation processor to the framework target that does not
run as part of the main build, but only for a parallel build target
framework-annotation-proc, which is identical to framework except that it
also runs an annotation processor. Update build rules to be aware of this
target so that it builds successfully.
Test: m framework-annotation-proc
Bug: 113853502
Change-Id: I8b20758dc8bd0e8cb2542414d7a45a2cd7d2e158
ctx.AddDependency will succeed if the named dependency only has a
single variant, even if that variant is the wrong architecture.
Use ctx.AddVariationDependency(nil, ...) instead, which requires
that all variations of the calling module match the dependency.
Bug: 112707915
Test: no change to out/soong/build.ninja
Test: using a device dependency in a host java module is an error
Change-Id: I70b661a57d4412eb63b8c9841febfb756e9e025d
If a module has kotlin sources the compiled kotlin clsases must be put
in the header jar for anything that depends on the module to use.
Bug: 113153312
Test: m checkbuild
Change-Id: Ibc44e9a97655937315b03b05e51e09c2954d7008
R8 complains when it gets dex files in the input jar, but some tests
use dex files or dex jars as resources. Keep resources separate
from classes until after r8 has been run.
Test: java_test.go
Test: m checkbuild
Change-Id: I1d9164d60d6b054ebb138648da07d80ee769177f
A few tests that have classes in the java.base module need to pass
--patch-module=java.base=<classpath> to javac.
Test: m checkbuild
Change-Id: I246bad92dcde976969b064aace5e2856e2bac971
Make :module on a java_library provide the output file, which is
normally the implementation jar. For java_library modules with
installable: true or compile_dex: true this will be the dexjar
instead. For android_app modules this will be the apk.
Bug: 80144045
Test: no change to out/soong/build.ninja
Change-Id: I739674aee60a38bfccb859369e4414b46f293d82
There is more variety of java tests than I expected, don't
default to including junit, that's just going to lead to
unexpected junit classes for module authors that don't know
to set junit: false. All existing uses of java_test are
already not using junit or setting static_libs: ["junit"],
and all test in Make are already specifying junit.
Bug: 70770641
Test: m checkbuild
Change-Id: I4393b70d87dd2b6e3bb719fdb758915053bee0c7
Files in the data property will be passed to
LOCAL_COMPATIBILITY_SUPPORT_FILES in Make.
Test: m checkbuild
Change-Id: Ifc074317f957aba8f55daa30abc5b9737d1eceac
Move autogenerating the test config for Soong modules into Soong
for java_test and android_test modules.
Bug: 70770641
Test: m checkbuild
Test: atest CtsUiRenderingTestCases
Change-Id: I02593add0407ef694b91c14cf27411a4f3cc4745
As it turns out, AIDL originally passed and returned success
when it was asked to compile an unstructured parcelable even
though no output files were created.
The build system currently can't handle this because it is
expecting outputs here, so I am adding this argument here
which will cause the compiler to exit and error earlier as
expected.
Notice also that the make implementation of the AIDL build
system also passes in this argument.
Test: m framework (which invokes this many times)
Bug: N/A
Change-Id: Ia9b5280dc3593756784035a523399545c9947d80
Since currently android.jar compile against to it.
Test: m -j metalava_android_stubs_current
Bug: b/78245848
Change-Id: Id5812f69125085821182295e577849b5f2c4bead
When the module type is SdkLibraryDependency, the classpath has been
gotten from headerJar
Becuase droiddoc uses src files when it builds, we should change to use
ImplementationJars instead of headerJar.
Bug: 77577799
Test: make -j
Change-Id: I1a072be69d7edff5636ea80af700be7796c3b0fc
Add a flag to be able to generate the Binder#getTransactionName method
Test: manual
Bug: 111200705
Change-Id: I3e8106261df5c63cdc005d07c9d8efcc6732db70
The files in kotlin jars seem to be called .kotlin_builtins, not
.kotlin_builtin.
Test: m checkbuild
Change-Id: I541aea758bbef6bb23632836cceb8339b82ffdff
merge_zips -stripFile was only considering the name of the file and
ignoring the path. Make it more useful by supporting blueprint style
globs. The previous behavior can be recreated by prefixing with **/.
Bug: 111389216
Test: m checkbuild
Change-Id: I25760fe3f1f77704dd9da9d107d9a38a415d681f
Prebuilt jars sometime contain files that we don't want. In Make
we would delete everything in META-INF when importing jars, but
that caused problems when there were necessary files in there,
so we added LOCAL_DONT_DELETE_JAR_META_INF.
Soong does the opposite, keeping everything by default. Add
properties to allow explicitly stripping unwanted files instead.
Bug: 111389216
Test: m checkbuild
Change-Id: I6d07f519ebc7d0e1bf0af93416bb569e3c2b1500
Very few java libraries need to be installed, most are statically
included in other modules. Device modules that are not installed
also don't need to be dexed, saving checkbuild time. Change the
default for java_library to not be installed, and allow libraries
that should be installed to specify installed: true. This makes
java_libary and java_library_static identical. It also simplifies
some corner cases when converting from Make to Soong if a module
is built for the host (which doesn't differentiate between static
and non-static/installable) and statically for the device, which
couldn't be represented in a single java_library in soong.
Bug: 110885583
Test: m checkbuild, compare presubmit target files
Change-Id: Idc0841c39a17cebd7bac3559c9408596d167a393
Add min_sdk_version properties and use it for aapt2
--min-sdk-version and --target-sdk-version flags. Add an sdkContext
interface that any function that needs an sdk version can take in
order to get the values for the current module.
Bug: 110848854
Test: m checkbuild
Change-Id: Ic69f1f935d8b865ec77689350407df08bfac5925
Currently Soong will only compile a Java library into dex if the
library has device support and is installable. For our use case of
inspecting the dex at build time this is not sufficient. Add a new
"compile_dex" device property which forces the creation of a dex
rule. In this case, the class jar remains the output file of the
module.
Bug: 79409988
Test: on related CL
Change-Id: Ia908a47148a03a0bdb0da4315cce6efc86c51865
Annotation processors should always have a common host variant, rather
than a device variant as the build was looking for before.
Bug: 110868826
Test: m
Change-Id: I2b7d0e7ed1af3f2f9ddb87d2bf36920737a507e9
Use the OpenJDK9 javac to run ErrorProne by adding it to
-processorpath and using -Xplugin:ErrorProne.
Bug: 69485063
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I0496006b71b70766ef16d57753cbcf037897799c
ErrorProne needs to be added to -processorpath, but once anything is
passed via -processorpath javac stops looking in the classpath for
annotation processors. Move annotation processors to -processorpath
in preparation.
This reapplies Ife06b3c7432ab971f5605dcc18a558bcbd99a675 with fixes
to processorpath in errorprone rules.
Test: m java
Change-Id: I188136771386a2183fb31f4b70b50c95ac419ff8
ErrorProne needs to be added to -processorpath, but once anything is
passed via -processorpath javac stops looking in the classpath for
annotation processors. Move annotation processors to -processorpath
in preparation.
Test: m java
Change-Id: Ife06b3c7432ab971f5605dcc18a558bcbd99a675
java_library, java_import, and android_library export SDK library names
that they are using directly or indirectly via its dependencies. When
building an apk, the manifest fixer uses the SDK lib names to
automatically add <uses-library> tags.
The SDK lib names are exported to the make world via
LOCAL_EXPORT_SDK_LIBRARIES flag.
Bug: 77575606
Test: m -j
Change-Id: I4fe606eb7ed23843c58eebe6a324405fe1da34e5
Java modules that have .kt sources may also use kotlin stdlib types
in their .java sources.
Bug: 78245848
Test: m checkbuild
Change-Id: I064cb76b8a641ad92d648febaa400bc01549a9c5
Add core-lambda-stubs to the bootclasspath for modules with no
sdk_version or with sdk_version: "current", and to the classpath
for modules that specify a specific sdk_version number. Use the
prebuilt sdk-core-lambda-stubs when using a prebuilt SDK.
Fixes compiling modules with lambdas against the SDK.
This reapplies I5e700f2dd86f1a6b84b7a55dd9bfe21a448d3fb6 with fixes
and tests for unbundled builds.
Bug: 80428539
Test: java_test.go
Change-Id: Ib7aaeebb93137270d7336a7293a08ed7064a3184
Add core-lambda-stubs to the bootclasspath for modules with no
sdk_version or with sdk_version: "current", and to the classpath
for modules that specify a specific sdk_version number.
Fixes compiling modules with lambdas against the SDK.
Bug: 80428539
Test: java_test.go
Change-Id: I5e700f2dd86f1a6b84b7a55dd9bfe21a448d3fb6
android_test module are APKs that can be run as tests, either
as standalone unit tests or as instrumentation tests for another
APK.
Test: m checkbuild
Change-Id: I16661701637e4048fd99442029c3e195ebf373a4
Add a platform_apis property. The logic to verify it isn't
hooked up yet, but this will allow translating modules to
Soong without losing the annotation.
Test: m checkbuild
Change-Id: I75ff2d7b94247873f5bb1547a9b347a8e73c3191
java_sdk_library is to make a Java library that implements optional
SDK APIs to apps. It is actually a wrapper for several modules: 1) stubs
library that clients are linked against to, 2) droiddoc module that
internally generates API stubs source files, 3) the real runtime shared
library that implements the API, and 4) XML file for adding the runtime
lib to the classpath at runtime if requested via <uses-library>.
Note: this is only the initial CL for the feature. Followings are features
currently missing and under development.
1) check for API consistency
2) install stubs libs as the dist artifacts
3) ensuring that apps have appropriate <uses-library> tag
4) disallowing linking to the runtime shared lib
5) HTML generation
Bug: 77575606
Test: m -j
Change-Id: I4a4ccf6e730e041703c63bb275d8860d0de96887
Add support for compiling android_library modules into AARs,
and refactor app support on top of it.
Bug: 73724997
Test: app_test.go
Change-Id: I1dfac5fffe577c6680bc4709147b2061eb7d819c
java_test is equivalent to a java_library with a default junit
dependency and marked as a test in Make for installation and
automatic AndroidTest.xml generation.
Bug: 70770641
Test: m checkbuild
Change-Id: I9ca97521e952d121db46abff6f24f274dd7a3ad7
