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
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
There are cases where a module needs to refer to an intermediate
output of another module instead of its final output. For example,
a module may want to use the .jar containing .class files from
another module whose final output is a .jar containing classes.dex
files. Support a new ":module{.tag}" format in any property that
is annotated with `android:"path"`, which will query the target
module for its ".tag" output(s).
Test: path_properties_test.go, paths_test.go
Test: no unexpected changes in build.ninja
Change-Id: Icd3c9b0d83ff125771767c04046fcffb9fc3f65a
This reverts commit 9d6df2246c.
Reason for revert: This change set the value of JAVA make variable to a string containing "foo bar". When soong_ui is asked to evaluate such string, it drops the quotes, causing bash to treat 'foo' and 'bar' as separate command line arguments.
Change-Id: If4e3c4c950c305bb67a572de3d86119c2da81dc1
Document that strings can contain double quotes escaped as \", and
the droiddoc args argument can contain a dollar signe escaped as $$.
Test: none
Change-Id: I91d3fa73f484094c9ce8cbecc93189850856de84
Move the rules to build framework.aidl into Soong, and use it
when compiling aidl files with sdk_version: "current".
Also fixes incorrectly using the aidl includes exported by the
"framework" module when the proguardRaiseDep dependency was
added.
Bug: 130798034
Test: sdk_test.go
Change-Id: I126adf1d9e7b6acb528875ff62b974ba7ad9a337
Move the logic from ctx.ExpandSources into android.PathsForModuleSrc
and ctx.ExpandSource into android.PathForModuleSrc, and deprecate
them. When combined with the pathDepsMutator this will let all
properties that take source paths also take filegroups or genrule
outputs, as long as they are tagged with `android:"path"`.
Test: All soong tests
Change-Id: I01625e76b5da19240e9649bf26a014eeeafcab8f
ModuleSrcPath was designed as a type that ensured that modules only
referenced sources inside the directory that contained the Android.bp
file. In practice they don't work very well, because allowing
filegroups and genrules as inputs to any module that takes a source
path means that the path might end up being to a file in another
source directory or to a generated file in the output directory.
Remove ModuleSrcPath, replacing it with SourcePath in the places
that need to explicitly refer to a path in the source tree, or
Path where it may be a source path or a generated path.
Make PathForModuleSrc return a Path instead of a SourcePath in
preparation for consolidation with ctx.ExpandSources, which will
make it possibly return paths to generated files.
Test: All soong tests
Change-Id: I973a78470ed14307eea5f6d0cc93942775a65715
Add `android:"path"` to all properties that take paths to source
files, and remove the calls to ExtractSource(s)Deps, the
pathsDepsMutator will add the necessary SourceDepTag dependency.
Test: All soong tests
Change-Id: I488ba1a5d680aaa50b04fc38acf693e23c6d4d6d
Building java_sdk_library without defining prebuilt_apis has been
failing with weird error messages. So one have to touch empty txt files
and create prebuilt_apis module, even when the java_sdk_library is
brand-new and has no previous versions. This commit fixes it so that API
check against previous version is skipped, in the case of missing
prebuilt_apis.
Note that Current api txt files (placed under api/ directory) are still
needed (make update-api)
Bug: 126259114
Test: tries to build without touching empty api txt files.
Change-Id: I93630f4139cbf502621693ec315dc06c0d07d1c3
The legacy-test and core-junit are no longer used by the runtime,
core-junit was removed a long time ago, legacy-test will be removed
soon.
Bug: 63127064
Test: TH
Change-Id: I094e7263afcba76b40361c3a681c9fd7a4314133
A newly introduced sysprop_library soong module will generate a
java_sdk_library and a cc_library from .sysprop description files.
Both Java modules and C++ modules can link against sysprop_library
module, thus giving consistency for using generated sysprop API.
As Java controls accessibility of Internal / System properties with
@hide and @SystemApi, 2 different header files will be created. And
build system will selectively expose depending on the property owner
and the place where the client libraries go into.
Bug: 80125326
Bug: 122170616
Test: 1) Create sysprop_library module.
Test: 2) Create empty txt files under prebuilts/sdk.
Test: 3) Create api directory, make update-api, and see changes.
Test: 4) Try to link against sysprop_library with various clients.
Test: 5) Soc_specific, Device_specific, Product_specific, recovery flags
work as intended.
Change-Id: I78dc5780ccfbb4b69e5c61dec26b94e92d43c333
dexpreopting boot jars is going to need to visit both java_library
and java_sdk_library modules. Since java_sdk_library is already
a java_library module, move the SdkLibraryDependency methods out
of the way so that it will implement Dependency. Also requries
re-ording some of the type switches to check for the more-specific
SdkLibraryDependency first.
Test: TestJavaSdkLibrary
Change-Id: I155c9ffaf31689dd150a4d99e07e432ff770b4a7
Add an empty DepsMutator to ModuleBase so it doesn't have to be
implemented on every module that doesn't need it.
Test: all soong tests
Change-Id: I545a832a0dbf27386d3080377a75ea482cd9ce59
The srcjar directories just confuse people looking for generated
files, clean them up after each rule.
Test: m checkbuild
Change-Id: If712ce7d4922619fd8420ae8f89830fe7824114d
The --android-jar-pattern flag passed to metalava is used to
find all the prebuilts for previous API levels such that
it can compute the exact API level for each class and member.
At some point the prebuilts must have been moved without this
code getting updated.
This fixes
Bug: 122452571: Can't build app with Q prebuilt SDK with minSdkVersion=21
Test: make sdk; inspect api-versions.xml
Change-Id: I25f6203725391dc5404cb8b6049479c9c3da1699
The new format is described in tools/metalava/FORMAT.md.
Fixes: 116589402 Switch signature files over to the v2 format
Fixes: 112626813 Drop "synchronized" modifier from the signature format
Fixes: 122358225 Omit overriding methods that only differ in final [...]
Fixes: 73088715 API Review: Need doclava to output nullability
Fixes: 79739773 API Review: Metalava enforcing constants are constant
Exempt-From-Owner-Approval: Large-scale tooling change
Test: make sdk, make update-api, make checkapi
Merged-In: I8314f4e7099fa92e4f8ed7d283ccf836cc9a84a0
Change-Id: I828ec5ea2f879ebf8dd4ead651e9c9d2345f52e0
To support core library, "Openjdk9", "No_standard_libs" and metalava
properties are added to java_sdk_library.
If core_lib is true, dist paths are changed to
apistubs/core/....
impl library name is changed to {module_name}.jar instead of
{module_name}.impl.jar
Bug: 110404779
Test: m -j
Change-Id: Ieb6248ea714b4260333d8bf61573d4f3413f7f24
Merged-In: Ieb6248ea714b4260333d8bf61573d4f3413f7f24
(cherry picked from commit af4907fed7)
As tnorbye@ mentioned, the check-API comptibility needs the annotations
that were merged in so that the behavior will be consistent with
signature file.
Test: check the ninja file.
Bug: N/A
Change-Id: I0c06c838cf7ddfd43f583fc8c1b1ad999a4cc066
Remove dependency on framework.jar to reduce the build time. So sdk
libraries are not checked API whenever frameowkr.jar changes.
Test: m -j
Bug: 119625999
Change-Id: I7435c429b7857de8c3c1834757c54888091753e5
Otherwise it might have the chance to clobber each other
if the rules ran at the same time.
Test: m -j docs
Bug: b/119671939
Change-Id: Ia57e62f0899e5c61539516833c6e3db88547932e
This names an input file for the droidstubs rule, so needs to be
handled in soong.
Test: core-current-stubs-nullability-validation-check-nullability-warnings
Bug: 73448108
Change-Id: I092c89f01c8a448ca486e4b57d43a1c3af133114
This takes the warnings file written by metalava and diffs it against
the expected (checked-in) file, in a manner similar to the checking
and updating of the signature files. This makes it possible for a
developer adding a large API surface (e.g. by moving to a new version
of upstream sources for ojluni) to do so without being blocked on
adding the annotations, while ensuring that at all times there is an
up-to-date record of the API surface which is missing annotations.
Bug: 73448108
Test: See the other change in this topic.
Change-Id: If9ed470ef3355a0d713bb556b5561fb255e4e277
Before this change, if targetSdkVersion wasn't set in the
AndroidManifest.xml, we'd set it to the sdk_version from the Android.bp.
But there are cases where you want to compile against a later SDK, but
target an earlier one (especially if you depend on libraries that need
to be compiled against more recent SDKs, like androidx).
Test: build APK with different target_sdk_version.
Change-Id: Iaed36b522955a374a049ef331158cc8fc5798ad2
This detects whether this is enabled, makes sure the other necessary
flag is set to provide a suitable location, and suppresses the
requirement for a previous_api.
Test: making a new libcore target using this
Bug: 73448108
Change-Id: Ifea3a060011a58e3288050c6c5d98b205abe25fc
Without the annotation args the check API fails for
APIs that use visibility annotation args.
Bug: 117936519
Bug: 113148576
Test: build
Change-Id: Ie9d2116c7f255634de72de9a448f5c378c11c457
If Srcs contains only srcjar, sourcepath is null and an error occurs. So
if sourcepath is null, we will use the "-sourcepath "" ".
Test: m -j
Bug: 112397488
Change-Id: I03ac0074fc041203fa1b427d4b4a418af44e85e2
This works like the existing annotation merging support, but uses a
different flag, because the merging needs to happen earlier in
metalava (see the other change in this topic).
Bug: 115746226
Test: `make api-stubs-docs`
Test: `make core-platform-api-stubs` with local modifications to trigger this path
Change-Id: I30d6d7993e06b105fb3e9fcefde39c1bf3da998a
Add comment to provide some cautions in case of we make some changes on
the jdiffdocZip name in the future.
Test: N/A
Bug: b/116221385
Change-Id: I3b612d50465f7feb87bc26ef81e692bf72d6f98f
Some build breakages happening on git_master/docs because jdiff rule and
apicheck rule may start in the same time, and jdiff may delete the same
srcjars and out dirs when apicheck trying to read which can cause
apicheck to be failed.
So change the dir names used by jdiff to not mix with dirs used by
apicheck.
Test: m -j docs
Bug: b/114368000
Change-Id: I90a53e0ef5f1ff947db7eb8cc73744919a9b93cb
Originally when metalava sees arg: "--generate-documentation", it will
create a seperate process to invoke javadoc/dokka.
Now this is handled by our build system. Basically metalava target will
only generate a .srcjar file. Any other droiddoc target which generates
docs can depend on this metalava target.
By doing this, if multiple doc targets depending on the same metalava
sources. The metalava won't need to be re-run by multiple times which
could cause quite some timing overhead.
Test: m clean && m -j core-docs and
compare the results using md5sum between the old and new content.
also m clean && m -j core-current-stubs-gen-docs and
compare the results using md5sum between the old and new content.
Bug: b/78245848
Change-Id: If7deef0da738645efe7d3a8376ff2bb3dec92c01
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
This allow Metalava to generate public-dex file when user specify
dex_api_filename.
This blocks how we try java9 for droiddoc since "hiddenapi-lists-docs"
targets depends on libcore sources.
Test: m -j hiddenapi-lists-docs
Bug: b/78245848
Change-Id: Ic847c1123b14afb599dbf2a588885fd36e56b2cc
Merged-In: Ic847c1123b14afb599dbf2a588885fd36e56b2cc
This reverts commit ec716b4151.
Reason for revert:
This is second attempt for Make Metalava checkapi a seperate run.
The first attept didn't work since Metalava also need sources,
classpath, and etc, not like how old Doclava apicheck works.
Test: cherry-pick go/ag/4832335 in internal master, and do 'm clean && m
-j checkapi', it failed with erros which is expected.
Bug: b/113126618, b/113131828
Change-Id: I664b7838d15615905a2e798b1df832218031dfe7
This reverts commit ed0a39dba7.
Reason for revert:
it seems checkapi can be passed successfully even if we didn't do update-api for new changes. roll-back for now and do more investigation.
Change-Id: Idd54ea8919671d54aa6401233156d6c0bcf5325f
We should not squeeze all the args to one Metalava run, especially for
checkapi.
Bug: b/113126618
Test: m -j checkapi, and check out dir api-stubs-docs.
Change-Id: I8d0c75745c7861b6de9070ef69f8e9284473a5d7
Due to various bugs hidden deeply within Doclava, running with
"-source 1.9" is always failed for it.
So switch to "-source 1.8" for now. This includes the case of running the
combination of Metalava + Doclava. Once we have new documentation tool
in system, we can full deprecate Doclava.
Test: USE_R8=true EXPERIMENTAL_USE_OPENJDK9=true m -j core-docs
Bug: b/70351683
Change-Id: I9553f88d0dd9bc263a249c49075c0b931b5d4927
"--previous-api" option was not recommended after Metalava was
changed on how to consume the api file args.
Test: m -j api-stubs-docs
Bug: b/78245848
Change-Id: I1054173e11b4d47942dda0b95193277758aa8193
Metalava is supposed to treat all the args after
"--generate-documentation" as either Javadoc or Dokka commands, and it starts
seperate process to invoke javadoc or java -jar dokka...
Dokka doesn't support --bootclasspath in its args, so treat all the
bootclasspath as classpath.
Also continue to refactor code to seperate Dokka runs from Javadoc or
Metalava.
Test: m -j metalava-dokka-core-docs
Bug: b/72394196
Change-Id: I0f0f3dd80cb2dbb53f19da8fa11ae0b1d92ac5d7
We don't have API exported to glob any dir outside of current module.
Any files deps outside of current module should be either a
filegroup/filegroup or a customized module.
We already have similar customized module to track droiddoc-template, so
rename it to be more generic so that it can be used by
merge_annotations_dir also.
Bug: b/111916275, b/70351683
Test: touch manual/android/support/design/widget/annotations.xml, and m
-j metalava-api-stubs-docs, and check the built output srcjar.
Change-Id: I75420ddba69785e46bea75b6dd3f189be7cfe5ad
The GenerateAndroidBuildActions() is too big to be maintained and added-in new
features.
Since the GenerateAndroidBuildActions() is a giant code block having build flags
setting and workflow logic mixed in it. So seperate these two main
stuff to only keep workflow logic in the function, and create other
indipendent flags setting functions to increase the modularity.
Test: m -j api-stubs-docs && m -j metalava-api-stubs-docs, and check
build.ninja file
Bug: b/70351683
Change-Id: I4230d353756aeb4b24640f641b8f8bab6b21204d
bundle files related to sdk dev tool(activity_actions.txt, and etc.) to the
final -docs.zip file since sdk.atree needs to copy these files from
$(OUT_DOCS)/offline-sdk dir.
Test: m -j out/target/common/docs/offline-sdk-timestamp
Bug: b/70351683
Change-Id: I3bfb3c56570dd6728dec272d38c6046e0d44c40f
Merged-In: I3bfb3c56570dd6728dec272d38c6046e0d44c40f
API txt files from a java_sdk_library are automatically registered as
dist artifacts for sdk and win_sdk targets.
They are installed under $(DIST_DIR)/apistubs/<apiscope>/api/<name>.txt
where <apiscope> can be public, system and test.
Bug: 77577799
Test: m -j
Change-Id: I38cd8ee000445ce843ac01ead38001e509228738
This change replaces droiddoc's metalava_merge_annotations_dir
parameter (which takes a single value) with
metalava_merge_annotations_dirs (which takes a list). This will makes
it possible to merge libcore annotations in from a separate directory
under ojluni, instead of adding them in a preprocessing step.
It is implemented by passing the --merge-annotations argument to
metalava multiple times, which is already supported by metalava's
command line parsing.
Test: `make metalava-api-stubs-docs` with a local change to add a second directory in //frameworks/base/Android.bp
Bug: 111639530
Change-Id: I53d31f1dd45c13405b4511c2b44cbeb7f0e439d1
Define LOCAL_DROIDDOC_ANNOTATIONS_ZIP to export zip file.
Test: m out/target/common/obj/PACKAGING/metalava-api-stubs-docs_annotations.zip
Bug: b/78245848
Change-Id: I66ca2a50adc095cc8a8a1a10620427a91480a9bc
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
These new options are required for online/offline-docs. These options
are only for Doclava, not Metalava.
Bug: b/70351683
Test: m -j offline-sdk-docs
Change-Id: Ie229821409d5640adfa6d7d05450e5f4c215b9b4
This is used to output a mapping of class member signature to source
position, which in turn is used for automated addition of annotations in
frameworks code.
Metalava support does not exist (yet), and may not be needed, since the
addition of these annotations in a one-time thing. This change can be
reverted once this is complete.
See go/hidden-api-annotations for more context.
Test: m
Bug: 110868826
Change-Id: I90e409f6ea02b16eb9e03d92382f9bb46a8fdab5
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
Continue to use -bootclasspath when -source 1.9 is enabled for Metalava
since it doesn't support -system yet.
Test: N/A
Bug: b/110824610
Change-Id: Ie1c047963bd66f1a100255efdcd6ca378cf2e1c4
Remove support for compiling with javac from OpenJDK8.
We still target 1.8 by default, and OpenJDK8 prebuilts are still
required for the bootclasspath and running robolectric.
Bug: 38418220
Test: m java
Change-Id: I5686deb0ae4f9927192a039d08adc0117b2605dd
Blueprint allows multiple dependencies on the same module after
https://github.com/google/blueprint/pull/210.
Fix defaults, WalkDeps can now find the same defaults module multiple
times.
Fix droiddoc, if the srcs_lib points to a lib module that is
specified multiple times, for example through explicit properties
and implicit default libraries, the srcs would be listed on the
command line multiple times. Move srcs_lib to use its own dependency
tag.
Test: m checkbuild
Change-Id: Ia30ce83be1382820d76bca5046ad18cbffe8af1a
Removed the additional "-source $javaVersion" arg in javadoc rule
otherwise javadoc will report error:
javadoc: error - The -source option may be specified no more than once.
Test: m -j ahat-docs
Bug: b/70351683
Change-Id: I7f92236884154075fb4b20cd9a363419b1ecd3f5
CL I5f92a54d718749f8ddef9472f3b6387a3debd385 adds a new "-dexApi" flag
to Doclava, which generates the public API as a list of Dex signatures.
Add support for this flag to Soong and expose it in the droiddoc rule.
Bug: 80461842
Bug: 64382372
Test: make out/target/common/obj/PACKAGING/hiddenapi-blacklist.txt
Change-Id: Iadf09f17bb783209a6555ce5289c381bf025a01c
SourceDepTag is going to become a set of tags of the same type
instead of a single tag, remove references to it outside the
android module.
Bug: 80144045
Test: soong tests
Change-Id: I00b2ea5040e4fc95dfbfdd79e21579853c478fcb
Test: Manually checked-in prebuilt metalava.jar to my local src tree and
compare the doclava based api file and metalava based api file.
Bug: b/78245848
Change-Id: Ib434f1e15403a78a0ccf89d9aacb70a6f8b05b2b
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
droiddoc now accepts aidl files as inputs. This in turn allows us to
feed aidl files to java_sdk_library modules. This is required as some
java_sdk_library internally uses AIDL files and thus we need to specify
*.aidl files in the srcs property. Since the srcs property is internally
given to the droiddoc module as well as the runtime library, droiddoc
should be able to handle aidl files.
Bug: 77575606
Test: java_test.go
Change-Id: If7a8559a2a1d8ac1056b061d24e3a5ee5253453f
didn't remove the props: api_filename, removed_api_filename yet since
these two currently are used by java_sdk_library.
Bug: b/78034256
Test: m clean && m checkapi
Change-Id: Iebd014ef227487717b5b3819c80d630c34559983
CL I8fe27e8c03334f9c90204db1e69447de65a06a38 adds new "-removedDexApi"
flag to Doclava. This patch adds support for that flag into Soong.
"droiddoc" targets can generate the new API file with property
"removed_dex_api_filename".
Bug: 78182899
Test: make
Change-Id: I04b8f615aa4655167b824d40c3fafa2648beec01
When compiling against without customized doclet, Javadoc doesn't need
to depend on Doclava and Jsilver jars. Originally, we leave these two
jars empty in Args so that CommandDeps won't have these two
dependencies. But Ninja doesn't like that with errors:
ninja: error: build.ninja: empty path
because $Jsilver and $Doclava is undefined when compiling Javadoc.
Test: m -j platform_library-docs
Bug: b/70351683
Change-Id: I02fee181490f91e87a1feac74f3a69b5b4acb528
This change fixes several problems found while re-defining some libs
using java_sdk_library module type.
1) A phony module whose name is the same as the java_sdk_library name is
defined. It is used to support installing the runtime library via
PRODUCT_PACKAGES (even when there is no dependency from other modules).
2) A bug that package names whose depth is >= 2 is ignored in
droiddoc.srcs_lib_whitelist_pkgs is fixed. A package name foo.bar.baz is
now converted to a path foo/bar/baz following the Java convention.
3) A make variable JAVA_SDK_LIBRARIES that is the list of java_sdk_library
module names is exported to make. This can be used to distinguish SDK
libraries from ordinary libs.
4) When running doclava, some framework sources in the 'android' package
and the same packages as the SDK library are automatically added to the
sources list. This is required for the case when API class is extending
from the framework class. In that case, doclava needs to know whether
the base class is hidde nor not. Since that visibility info is encoded
as @hide string in the comment, we need source files for the classes,
not the compiled ones. Also there are rare cases where part of SDK
library is implemented in the framework (e.g. org.apache.http.legacy).
In that case, we need framework source to make API stubs, though the
sources are not required to build the runtime library.
5) The stubs libs are disabled for PDK builds as well.
Bug: 77575606
Test: m -j
Change-Id: I360cf15fe5339e46644fb16d0dabe2548aa315f9
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
Some modules only need the documentation instead of the stubs.
And fix a small issue for arg name passed to standard javadoc.
Test: m -j dx-docs and check the build.ninja
Bug: b/70351683
Change-Id: Ic47c53db12db6f2632349e48c4a626a4f432f447
javadoc expects directories on the sourcepath, not jar files.
The original commit 88b607994a148f4af5bffee163e39ce8296750c6
in 2009 was already passing the jar files, and every revision
since then seems to have kept this habit through cargo cult.
This CL removes the superfluous jar file arguments from the
sourcepath argument to javadoc.
Test: Treehugger
Bug: 76436487
Change-Id: I3a8503ae089cd6657a698c0552dc194156311849
extract_srcjars.sh uses zipinfo and unzip, which fail with an
error on an empty zip file. Instead of trying to hack around
this (which is hard to make guarantees for since they are
non-hermetic host tools), replace them with a go tool to unzip
a set of zip files into a directory.
Bug: 73885582
Test: m checkbuild
Change-Id: I151fed347ed5196726e36866ffc27bc831799afb
api-stubs, system-api-stubs and etc need generated sources and srcjars from "framework",
so add a property that tell module to fetch srcs and srcjars from its
dependency libraries. The libraries in that property has to be in the
module's classpath.
Also add doc_defaults targets.
Bug: b/70351683
Test: m -j
Change-Id: I05831fbcad488037710950e4f05dc8fb2a12f403
We prefer not to use absolute paths in modules, but to reference modules
that have associated paths. This a few benefits:
* it's easier to move a module than to update all the references
* if the module doesn't exist, we treat it as a normal missing
dependency, not having to deal with the missing dependency in path.go
* implementing visibility(etc) in the future would be simpler if there
was a module attached to the reference, so we don't have to do various
path-based lookups to try and match things up.
So define a `droiddoc_template` module, which takes a path, and will run
the glob once in that module. All of the `droiddoc` modules can then
specify it through the `custom_template` property, which will pull the
necessary data.
Also fix that htmldirs should be references from the local path, the
htmldir2 argument never being specified, and complain if more than two
htmldirs are specified, or if the custom template isn't specified.
Test: m core-docs
Test: out/soong/build.ninja is nearly identical
- line numbers in comments
- adds directories to droiddoc template dependency lists, which
is more correct, since we need to rerun on added or removed
files too.
Change-Id: Iff630bddb3818b8eeed439de7e41fc7fbe7cdcb0
This reapplies If1690a708393964d3030cb908beaf7b6897c0084.
PathForSource does the AllowMissingDependencies check now, use it
instead of PathsForSource.
Test: m checkbuild
Change-Id: I84868c92ee43779f9b5c8b285dac92f5f87b018c
This reverts commit 9d37831dd3.
Reason for revert: Broke builds with ALLOW_MISSING_DEPENDENCIES=true
Change-Id: Ibff79642f747b83364c83d6b298334121028e02d
PathForSource does the AllowMissingDependencies check now, use it
instead of PathsForSource.
Test: m checkbuild
Change-Id: If1894fd98d8d757ebc3c1635d5fcea86f81bfc4a
Support Droiddoc to Soong based on core/droiddoc.mk. The non-std doclet
based droiddoc compilation output is a "real" stubs.jar instead of a
directory of java files and a timestamp file.
The std doclet based javadoc compilation output is a "empty" stubs.jar
instead of a timestamp file.
The stubs.jar will be exported to
out/target/common/obj/JAVA_LIBRARIES/$(LOCAL_MODULE)_intermediates/classes.jar
and out/target/common/docs/$(LOCAL_MODULE)-stubs.jar
A $(LOCAL_MODULE).zip file will be generated also, and is exported to
out/target/common/docs/$(LOCAL_MODULE)-docs.zip if property: installable is not set
to false.
Bug: b/70351683
Test: unittest + convert libcore docs Android.mk to Soong manually.
Change-Id: I1cffddd138a5d9d445f86a3d4a3fd4de88a2bc0f
(cherry picked from commit 78188ec622cb1ee24171455867fc58ffab91562e)
