This is needed for a follow up change that makes sure that the
prebuilt modules have the same visibility as the source modules.
Bug: 143678475
Test: m conscrypt-module-sdk
Change-Id: I9461c8c094ab19ee9ececb5e5fd50565789f2fa2
Extracts the type specific functionality into the SdkMemberType
interface which has to be implemented by each module type that can
be added as a member of the sdk. It provides functionality to add
the required dependencies for the module type, check to see if a
resolved module is the correct instance and build the snapshot.
The latter was previously part of SdkAware but was moved because
it has to be able to process multiple SdkAware variants so delegating
it to a single instance did not make sense.
The custom code for handling each member type specific property,
e.g. java_libs, has been replaced with common code that processes
a list of sdkMemberListProperty struct which associates the
property (name and getter) with the SdkMemberType and a special
DependencyTag which is passed to the SdkMemberType when it has to add
dependencies.
The DependencyTag contains a reference to the appropriate
sdkMemberListProperty which allows the resolved dependencies to be
grouped by type.
Previously, the dependency collection methods would ignore a module if
it was an unsupported type because they did not have a way of
determining which property it was initially listed in. That meant it
was possible to add say a droidstubs module to the java_libs property
(and because they had the same variants) it would work as if it was
added to the stubs_sources property. Or alternatively, a module of an
unsupported type could be added to any property and it would just be
ignored.
However, the DependencyTag provides information about which property
a resolved module was referenced in and so it can detect when the
resolved module is of the wrong type and report an error. That check
identified a bug in one of the tests where the sdk referenced a
java_import module (which is not allowed in an sdk) instead of a
java_library module (which is allowed). That test was fixed as part
of this.
A list of sdkMemberListProperty structs defines the member properties
supported by the sdk and are processed in order to ensure consistent
behaviour.
The resolved dependencies are grouped by type and each group is then
processed in defined order. Within each type dependencies are grouped
by name and encapsulated behind an SdkMember interface which includes
the name and the list of variants.
The Droidstubs and java.Library types can only support one variant and
will fail if given more.
The processing for the native_shared_libs property has been moved into
the cc/library.go file so the sdk package code should now have no type
specific information in it apart from what is if the list of
sdkMemberListProperty structs.
Bug: 143678475
Test: m conscrypt-module-sdk
Change-Id: I10203594d33dbf53441f655aff124f9ab3538d87
Having each module type generate the contents of the snapshot's .bp
file results in lots of duplicated code. This adds an intermediate
model for use by the module types and then generates the .bp file
contents from that.
This not only removes the duplicated formatting code but it also
allows consistent handling of shared properties such as name further
reducing duplication. It also makes it possible to duplicate the
versioned and unversioned prebuilt modules from the same model.
Extracts generatedContents from generatedFile to allow the contents
to be populated without creating an output file, for testing.
Cleans up unused code.
Bug: 143678475
Test: m nothing
Change-Id: If21b84db0ef3fdfb5dc11ea0973ce6cb73603ea3
Removes duplicated code for generating a versioned and non-versioned
form of the prebuilt_stubs_sources module in the snapshot.
Bug: 143678475
Test: m nothing
Change-Id: Ic431b6fcb6f3c7c85f1a04cb6f087424aaf0cffa
Adds stubs_sources property to sdk and unzips the droidstubs srcjar
into the snapshot directory.
Adds an UnzipToSnapshot method to the SnapshotBuilder which creates
a rule that uses zip2zip to repackage the supplied zip content into a
temporary zip file that matches what the required snapshot structure.
e.g. if the supplied zip contains foo/Foo.java and that needs to be in
the snapshot directory java/foo/stubs then it will create a zip that
contains java/foo/stubs/foo/Foo.java.
The temporary zip that is the output of that rule is added to the
zipsToMerge field for merging later.
If the zipsToMerge is empty then the snapshot zip is created as
before. Otherwise, a temporary zip file is created. That is then
merged with the other zip files in zipsToMerge to create the final
snapshot zip.
Adds prebuilt_stubs_sources for use by the generated .bp module.
Bug: 143678475
Test: added conscrypt sdk module and attempted to build it
Change-Id: Ie274263af3a08e36a73c61c0dbf0c341fd6967e2
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
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
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
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
Remove the hardcoded checks against "1.9" by making javaVersion
an enum and implementing javaVersion.usesJavaModules().
Test: TestClasspath
Change-Id: I559eeb1f45880bb8177269c6d977ee4dfbadce57
Prior to this change, setting that to "false" turned the default Java
language level back to 8. This change removes that option.
Bug: 115604102
Test: m java droid docs tests cts
Change-Id: I97bfd0dc8d941008b4071c6efe1c0c24950c4f1f
This allows to use Metalava to generate metadata files useful for
Android Studio as part of a droidstubs target.
Once those files have been created in a new metadata folder, they are
zipped to make it easier to transfer them into the
out/target/common/obj/PACKAGING folder where they can then be picked up
by the SDK build to be included there.
Bug: 142480924
Test: m sdk
Change-Id: I4be1c9e78369c65ee9cd94706c6d20ab0df6b797
This allows droidstubs to use the same system modules to create the
stubs that will be used to compile them. It improves consistency and
avoids droidstubs having to duplicate the libraries that make up the
system modules on its libs property.
Adds systemModules() to the sdkContext which allows consistent error
checking behavior between droidstubs and java_library.
Bug: 142534789
Test: m checkbuild
Change-Id: Ib2006906d9528a900f16851f50b62152ffb51a1b
Group aidl files into groups of 50 and compile them together into a
srcjar.
Bug: 124333557
Test: m checkbuild
Change-Id: I18e0858eab434071d3ff0039bb21e07c7311b601
They are no longer used. Sources are provided via filegroup.
Also removing the SrcDependency interface as it is no longer used.
Bug: 135922046
Test: m
Merged-In: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
(cherry picked from commit fa21cba64a)
Change-Id: I81f9614d20fbdd2f7d18340d6dbdb592e7acde06
This change removes srcs_lib_whitelist_dirs which was used to let
droiddoc to know the base directories for the AIDL/Java source files.
Instead, the base directories are given via the path property of the
filegroup modules.
This change also includes a fix that the base directories from all
filegroup modules listed in srcs are used as the import paths for the
AIDL compiler. This removes the need to have aidl.[local_]include_dirs.
Bug: 70046217
Test: m
Exempt-From-Owner-Approval: Approved internally
Merged-In: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
(cherry picked from commit f79334d95c)
Change-Id: I62ff2a7dd3943d9a3d95d91c36a30fd44ea467d2
sysprop_library now checks the API stability itself, cutting dependency
on java_sdk_library. Under the directory {module_dir}/api,
{module_name}-current.txt and {module_name}-latest.txt hold API
signatures.
When sysprop_library is built, or a user run "m {module_name}-check-api"
command, API check is performed. First, current.txt must have exactly
same signature with built sysprop_library module. Second, current.txt
must be compatible with latest.txt.
Build system emits a handy error message to generate/update those API
files, in case of missing or mismatching. Also, a script file for
freezing API files is introduced.
Bug: 131637873
Test: 1) m && boot blueline
Test: 2) m {sysprop_library} performs API check
Test: 3) manual test for check-api, freezing api
Change-Id: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: Ib7ad4f17e82c90da5ef3f80e2ab88c0b53112c60
(cherry picked from commit 093f0eb133)
Let genrules access the docs.zip output using ":module{.docs.zip}".
Bug: 138396395
Test: m checkbuild
Change-Id: I71e22147a596227f21826d875926b8b2ad1c74c1
* changes:
Fix date on mac builds
Convert javadoc modules to android.RuleBuilder
Convert droiddoc modules to android.RuleBuilder
Add a systemModules utility type
Convert droidstubs to android.RuleBuilder
This change fixes a bug that aidl include paths are not exported when a
java lib is used by a droiddoc module.
Bug: 135922046
Test: N/A
Change-Id: I367695677f60bfb4f324b788c7d09cd926cb75bb
date on mac takes a -r argument that expects seconds, date on linux
takes a -d argument that expects a date string. Prefixing the date
string with @ makes date on linux treat the time as seconds, but is
incorrect for date on mac.
Test: m docs
Change-Id: Ic2a585eaac4c25b7b471caa581d7f25827c3a6b3
Storing system modules in a classpath is clumsy, as there should
only ever be one system modules, and it needs to store both a
directory to pass as the argument and a set of generated files
to use as dependencies. Store them in a separate systemModules
type instead.
Test: m checkbuild
Change-Id: I020556c736bd5091865bcca51dc0fb9e4db6b45b
The droiddoc rules are ripe for converting to android.RuleBuilder,
they conditionally use many input files which is hard to track
with the standard blueprint.Rule style, as the argument and the
dependency have to be handled independently. Start converting
to android.RuleBuilder by converting the droidstubs module.
Test: m docs
Test: m checkapi
Test: m updateapi
Change-Id: I08713e91149471e88a40115f69824cf5eaf88fb6
Move the ninja escaping of Args later so that they can be passed to
RuleBuilder without double escaping.
Test: m docs
Change-Id: Iac3560a12c05d010e6bd0ad9c2d6b1e18ebf5f89
Change ctx.Config().BuildNumberFromFile() to be unescaped, and then
escape it manually where necessary. This will allow passing
ctx.Config().BuildNumberFromFile() to RuleBuilder, which will handle
the necessary escaping.
Test: no change to out/soong/build.ninja
Change-Id: I5329ab2ba70ccea49958864488aa81794a7e4b56
RuleBuilder does its own ninja escaping, so values that will be
passed to RuleBuilder must not be pre-escaped. Add a new
android.ExpandNinjaEscaped method that explicitly handles ninja
escaping. Some of the expansion functions return ninja values
(like "${in}") that need to stay unescaped, so add a bool return
value to the expansion function in android.ExpandNinjaEscaped.
Test: expand_test.go
Change-Id: Ib03d4db38b5e3e5bffbd87acf14f55e276a53d04
From aosp/588578, if vendor app doesn't fill sdk_version, build scirpt overwrites system_current to sdk_version.
But there is no similar enforcement in soong.
So, as make does, sdkVersion() returns "system_current" if it is device-specific or soc-specific module. and sdk_version is not filled.
Test: pass soong test
Bug: 132780927
Change-Id: I69bb3d7bfcf7c27c2db4d0efbe046f9c7879b4bc
Corrects an error message that refers to no_framework_libs.
Removes any tests that use no_framework_libs:true where possible as
there are duplicate tests for sdk_version:"core_platform". Otherwise,
switches them over to use sdk_version:"core_platform".
Bug: 134566750
Test: m droid
Change-Id: I41abe1a49f5c744e3393ca9cdf0c41888f810c9f
Corrects an error message that refers to no_standard_libs.
Removes any tests that use no_standard_libs:true where possible as
there are duplicate tests for sdk_version:"none". Otherwise, switches
them over to use sdk_version:"none".
The androidmk mapping from LOCAL_NO_STANDARD_LIBRARIES to
no_standard_libs has also been removed. There was little point in
updating the tool to map it through to sdk_version:"none" as there are
only a couple of places where it is used, in art's test running mk
targets and in some unbundled packages to work around some limitation
in .mk based build.
Bug: 134566750
Test: m droid
Change-Id: I6413c9b1fe3e63b93753a6a017d2981e32b7e013
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.
* 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
Paul Duffin