Explicitly pass the list of tests as LOCAL_ROBOTEST_FILES, and
support sharding the list of tests into multiple test runners.
Also filter out BaseRobolectricTest.java, which covers the only
use of LOCAL_ROBOTEST_FILES in Android.mk files.
Bug: 133878985
Test: m RunSettingsLibRoboTests runs the same number of tests before and after
Test: m RunSettingsLibRoboTests runs the same number of tests when sharded
Change-Id: Id85ffe03c98e722303eaa6def17812ed2244c6a6
Merged-In: Id85ffe03c98e722303eaa6def17812ed2244c6a6
Explicitly pass the list of tests as LOCAL_ROBOTEST_FILES, and
support sharding the list of tests into multiple test runners.
Also filter out BaseRobolectricTest.java, which covers the only
use of LOCAL_ROBOTEST_FILES in Android.mk files.
Bug: 133878985
Test: m RunSettingsLibRoboTests runs the same number of tests before and after
Test: m RunSettingsLibRoboTests runs the same number of tests when sharded
Change-Id: Id85ffe03c98e722303eaa6def17812ed2244c6a6
Where possible this duplicates any tests that use no_standard_libs:true
with ones that use sdk_version:"none". If not possible (e.g. in the
default targets included in java/testing.go) it switches some to use
sdk_version:"none" to ensure that there is no regression in the
behavior of no_standard_libs:true.
Follow up changes will switch all usages of no_standard_libs:true over
to use sdk_version:"none" at which point no_standard_libs will be
removed.
Bug: 134566750
Test: m droid
Change-Id: I5f0fd3daa980f6b223abe454cba7f25a97a39d7a
Previously, different parts of the build used different sources of
information about the SDK (i.e. the default libraries) against which
a Java module aimed at the device was built. Some used the sdk_version
property, others used the no_standard_libs or no_framework_libs, some
used a combination of all three.
That lead to inconsistent handling in the code, e.g. some parts treated
no_standard_libs: true as implying no_framework_libs: true and others
did not, and also in the build files, e.g. some modules specified
no_framework_libs: true and sdk_version: "system_current" which makes
no sense, or no_standard_libs: true and sdk_version: "core_current"
which are inconsistent.
This is the first step in a refactoring to simplify the sdk selection
process by replacing the no_standard_libs/no_framework_libs properties
with some extra options for the sdk_version property. This change
consists of:
1) Extra functions sdkContext to access the no_standard_libs and
no_framework_libs properties.
2) Extra field/functions in sdkDep to store and access the value of
no_standard_libs/no_framework_libs.
3) Changes to decodeSdkDep(...) to pass the values of the no_...
properties through to the returned sdkDep.
4) Change all code that accesses the no_... properties directly to
call decodeSdkDep(...) to get an sdkDep object and then accessing
the values of the no_... properties from there.
The accessor functions on sdkDep are called has...() rather than
no...() as most callers of the methods invert the value anyway and
!no...() is harder to reason about than has...().
The hasFrameworkLibs() function returns true if and only if
no_standard_libs and no_framework_libs are false. That is consistent
with all but one usage of the no_framework_libs property and that is
not affected by it.
Bug: 134566750
Test: m droid
Change-Id: I196e3304e8bd802fb154e897397b0dd337f868e2
Exempt-From-Owner-Approval: Colin has already given +2 modulo some
minor nits and this blocking other changes.
The build generates a file out/soong/hiddenapi/hiddenapi-flags.csv
which is used by the hiddenapi-blacklist tests in cts/tests/signature.
The generation is done at the ninja level and so is not accessible from
the soong layer that runs on top. This change adds the hiddenapi-flags
module type which makes the file accessible from other soong modules.
Bug: 122332514
Test: atest -p cts/tests/signature
Change-Id: If38c8a8ffca110f2ae01f97f19a2740ca3fde1b7
Exempt-From-Owner-Approval: Colin has already reviewed and only had minor
nits and this is blocking other changes.
Unbundled builds may not have definitions of shared libraries, and
they are not dexpreopted so the dependencies are not used anyways.
Test: manual
Change-Id: I89ad92f3b073422734f824ac3a8a3b9baf995ccb
* changes:
Consolidate *MutatorContext and ModuleContext into BaseModuleContext
Add test for missing defaults modules with AllowMissingDependencies
Capture missing dependency error rules
Share buildDir for android/soong/android tests
Reimplement AddMissingDependencies
Add GenerateAndroidBuildActions to DefaultsModuleBase
Previously, the tests had to use the Android.bp file in the root
directory of the mock file system. That prevented adding tests that are
dependent on the location of the Android.bp file, e.g. ones that use
no_standard_libs. This change will process any Android.bp in the mock
filesystem.
Bug: 134566750
Test: m
Change-Id: I6fb057a473a18e87bd1a89507e78ceb3fd171eb5
Modules that specify no_standard_libs: true should not specify the
sdk_version property as well because the former supercedes the latter.
Bug: 134566750
Test: m
Change-Id: I1d8663dc3a25baf23a1b136c7f35cf130cd7543b
JVM occasionally (0.5% time) crashes on entering a method with SIGSEGV.
It might be due to excessive load on the host machine. Reduce the number
of the compiler threads to 6, and do not start all the GC threads
immediately. If JVM crashes, copy full diagnostics to stderr.
Bug: 132766811
Test: treehugger
Change-Id: Ib7bfd568f6d32456bf623cbb615ffc990c326a34
Add an empty GenerateAndroidBuildActiosn to DefaultsModuleBase
so that every defaults module doesn't need to provide one. This
will also allow adding an implementation in the next patch.
Test: m checkbuild
Change-Id: I13554bdb3a287c2f18e1efab74d4f08a1ba8620c
The option '-encoding UTF-8' is included in the opts defined at L1754,
which are passed to transformJdiff (defined at L1594), and from there
to a javadoc rule (defined at L29), where they are included in a
command line string which already has '-encoding UTF-8' in it. The
result is that this appears twice in the command line. This is
apparently ignored by the version of javadoc currently used. Later
upstream versions of javadoc, however, fail with the error 'javadoc:
error - The -encoding option may be specified no more than once.'
Test: make system-api-stubs-docs
Test: make system-api-stubs-docs, using an OpenJDK 11 toolchain via OVERRIDE_ANDROID_JAVA_HOME
Bug: 131683177
Change-Id: Ib9382ada3c8259edfacb2be3ab14d4c09d8753a7
blueprint.BaseModuleContext is the set of methods available to all
module-specific calls (GenerateBuildActions or mutators). The
android package split the same functionality across baseContext (nee
androidBaseContext), BaseModuleContext, and BaseContext.
Consolidate all of them into android.BaseModuleContext.
Test: m checkbuild
Change-Id: I2d7f5c56fd4424032cb93edff6dc730ff33e4f1e
This jlink plugin is intended to optimise startup times for Java
runtimes by embedding a pre-processed and pre-validated module graph
in the system image.
This provides no benefit on Android, since the Android runtime does
not make use of the module graph it produces. (It doesn't seem useful
on Android anyway, since the system image only contains one module,
namely java.base.)
Furthermore, the plugin causes the jlink invocation to fail when using
the jlink tool from OpenJDK 11. The issue here is the plugin uses
classes in the jdk.internal.module package to describe the module
graph; that package is not part of libcore and therefore not listed in
the module-info.java for java.base on Android; but the plugin has the
side-effect of adding the package to java.base; this causes jlink to
subsequently fail with an error "Module java.base's descriptor
indicates the set of packages is : <lots of packages>, but module
contains packages: <same packages plus jdk.internal.module>". (The
implementation of the plugin changed significantly in OpenJDK 10,
which is presumably why this issue does not occur using OpenJDK 9's
jlink.)
Therefore, it is safe and beneficial to disable the plugin.
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make core-all-system-modules, using an OpenJDK 11 toolchain via OVERRIDE_ANDROID_JAVA_HOME and changing the jmod create invocation to use --module-version 11
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make droid, flash to device & sanity check
Bug: 131683177
Change-Id: I52333f32c88aa85cd3652ad91d50d9927ff61daf
