Use the `WriteFileRule` to write the permissions file for shared
libraries instead of generating a custom bash rule.
Test: TH
Change-Id: I904cf0742bfec46ed45ec7801bb9bd3dc3047185
As part of the process to remove the compilation action in the top level
java sdk library, this change modifies SdkHeaderJars(...) (i.e. the
"magic") to return the header jar of the implementation library instead
of the header jar of the top level java sdk library when the
implementation jar is returned from the "magic".
This change also removes `SdkImplementationJars()` from the
SdkLibraryDependency interface, as it is not currently used anywhere
else.
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: Icc00af4b1485dc2b1b0981a3e56758d0306dea69
Keep the Src attribute for compatibility. The new attribute (Srcs) is
mutually exclusive with Src.
Keep SourceFilePath and OutputFile for compatibility with other modules.
These can be removed in a follow up change.
Bug: 328313691
Test: presubmit
Test: m blueprint_tests
Test: prebuilts/build-tools/build-prebuilts.sh (on build-tools branch)
Change-Id: I5d5b2657715a7180a829c7ed0f501872d561b662
This change creates a "combined" filegroup module, which will contain
all api files of the subset api scopes in the followup change. In this
change, the "combined" filegroup is identical to the currently existing
last api filegroup module in that it only contains the api file /
removed api file of the specific api scope.
This change also passes the "combined" filegroup to the droidstubs
module generated from the sdk_library modules, but this currently does
not lead to any functional changes as the "combined" filegroup is
identical to the currently existing last api filegroup.
Test: m nothing --no-skip-soong-tests
Bug: 321827591
Change-Id: If73a7229f2f970f7e74cd010a8b4808dc9018344
Currently, the "exportable" stubs and the api files are copied to the
dist directory during SDK builds regardless of the value of the
RELEASE_HIDDEN_API_EXPORTABLE_STUBS build flag. This change modifies
such behavior that the "exportable" artifacts are copied to the dist
directory only when the RELEASE_HIDDEN_API_EXPORTABLE_STUBS flag value
is set to true.
Test: lunch aosp_arm-trunk_staging-eng && m sdk dist and inspect ninja graph to verify that the "everything" artifacts are copied to the dist directory
Bug: 330417789
Change-Id: I3b83375610eb172d7b9da7ea831a74cd427b696c
This change adds support to generate non-"everything" (i.e. "runtime"
and "exportable") stubs in java_api_library, which generates the stubs
from the api signature files.
Unlike droidstubs module that generates "everything", "exportable" and
"runtime" stubs in a single module, java_api_library generates a single
set of stubs per module, which is set by the default-"everything"
property `stubs_type`. This is because java_api_library is responsible
for both generation and the compilation of the stubs srcjar, and
compilation of the stubs srcjar are done in separate java_library
modules for from-source stubs.
Utilization of this feature will be done in a follow up change that
generates the "exportable" java_api_library modules in java_sdk_library.
Test: m nothing --no-skip-soong-tests
Bug: 318009570
Change-Id: I1051544ac3bcdb3ba1f78bfec28eba4e9fad9c2d
Currently, the "exportable" stubs are copied to the dist directory by
default when building the java_sdk_library module. However, "everything"
api files (current & removed) are copied to the dist directory, causing
confusion to the developers. This change modifies the default behavior
so that the "exportable" api files are copied to the dist directory and
match the behavior of the stubs.
Test: m nothing
Bug: 325639165
Change-Id: I2e3b158bb638d30629120b32aa3e88bb26231020
is_stubs_module property signifies whether the module compiles stubs or
not. The information is propagated to the reverse dependencies of the
java_library/java_sdk_library modules via JavaInfoProvider as
StubsLinkType, a ternary state that provides information about whether
the provided jars are compilation of stubs or implementation, or
unknown.
When java_sdk_library sets StubsLinkType, its state is Unknown as the
decision of providing stubs vs implementation jar differs by the reverse
dependency.
Note that this CL does NOT propagate the property up to its reverse
dependencies. This will be done in follow up CLs.
Test: m nothing
Bug: 310504781
Merged-In: Ic81488dbd1c9af1b5d31a33e5e9441d9f1416dbe
Change-Id: Ic81488dbd1c9af1b5d31a33e5e9441d9f1416dbe
This CL is the java_sdk_library_import equivalent of aosp/2928483.
With trunk stable, we will have multiple apex prebuilts in the tree.
Each apex prebuilt will have its own module sdk. This means that it is
possible to have mutliple versions of `framework-foo` in the tree. This
CL introduces a mechanism to select a specific versioned
java_sdk_library prebuilt.
Implementation details
- Add a `source_module_name` property to java_sdk_library_import. This
will identify the source equivalent of the jsl in packages/modules.
This used to be implicit - i.e. the name without the prebuilt_ prefix.
With multiple prebuilts, this has to become explicit.
- Set appropriate `source_module_name`(s) in the dynamically created
child modules. e.g. the source_module_name on sdklib.v1.stubs and
sdklib.v2.stubs will both be sdklib.stubs, assuming
`source_module_name` on the top-level jsl_import is sdklib
- Add a private Created_by_java_sdk_library_name property to java_import
and prebuilt_stubs_sources modules. This will be used to idenfity the
top level java_sdk_library_import that was used to create these child
modules. This is necessary because java_sdk_library_imoprt is a macro
that creates 1:many modules. However, to avoid toil, only the
top-level java_sdk_library_import will be listed in
`apex_contributions`. This new property will be used for
source/prebuilt selection in android/prebuuilt.go
- Rename BaseModuleName in commonSdkLibraryAndImportModule to
RootLibraryName. This is necesssary because the former is now reserved
to identify the source equivalent of a prebuilt module (maybe we
should rename it?)
Bug: 322175508
Test: Added a unit test
Change-Id: If6aa6b0e939a07f8263874941413908383c81a78
For prebuilts, the dexpreopt rules of system server jars are now
generated from the context of the top-level prebuilt apex and not in the
context of the shim java_import modules. Since
`dex_preopt.profile_guided` property is defined in java_import, this
needs to be bubbled up to the top-level apex. This will be done using
deapxerInfo. If profile_guided of a transitive java_import is true, the deapexed .prof file will be
set as dexreopter.inputProfilePathOnHost before invoking
dexpreopter.dexpreopt. This ensures that only that java_import undergoes
profile guided dexpreopt, and not every other transitive java_import
Test: go test ./apex -run TestPrebuiltStandaloneSystemserverclasspathFragmentContents
Test: lunch cf_x86_64_only_phone-next-userdebug && m
$ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
Test: du -sh
$ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
24K
Bug: 308790457
Change-Id: Ibf46ecb400b3f126b243fc8d27b08d9a1aa4cc97
For prebuilts, java.dexpreopt gets called twice
1. in the context of the top-level prebuilt apex
2. in the context of the java_library shim
Only the artifacts of (1) get installed. The artifacts generated by 2)
are unused. However the args used to generate the artifacts of (1) are
incorrect. It uses moduleName(ctx) to do special-handling of apex system
server jars. This special-handling does not happen in (1), so although
dexpreopt artficats get generated, they get generated with the wrong
args.
To fix this, add an additional parameter in java.dexpreopt to pass the
libraryName explicitly.
Details
- Delete moduleName function. This was used to determine the java
library name, which is no longer safe
- Add a libraryName parameter to java.dexpreopt
- Most module types will use j.Name() as libraryName
- prebuilt_apex and apex_set will iterate over its `contents` and use
each element as libraryName when invoking java.dexpreopt
With the correct args passed from (1), we can drop j.dexpreopt from (2)
completely. Dropping (2) also breaks profile guided dexpreopt tests.
These currently operate on (2). They will be moved to (1) in the next CL
of this stack.
Test: presubmits
Test: lunch cf_x86_64_auto-trunk_staging-userdebug && m nothing (this
was a postsubmit failure with aosp/2923733)
Test: art_standalone_dexpreopt_tests on next https://android-build.corp.google.com/builds/abtd/run/L86000030001579256
Test: art-gtest on git_master-art-host https://android-build.corp.google.com/builds/abtd/run/L07800030001550262
Bug: 308790457
Bug: 322255144
Change-Id: I8eb604c82f1fa5289d3cd1a20084d56e4d7485e3
In order to prepare generating "runtime" stubs in droidstubs, this
change performs some cleanups, which are:
- Modify droidstubs providers methods to take a StubsType enum as an
input, in order to remove exportable-specific providers. The methods
are also modifed to return an error when the artifact is not provided
for the input StubsType.
- Wrap droidstubs artifact to a struct. This removes artifacts common to
all stubs types from being written out as a individual module property
(e.g. exportableAnnotationsZip -> exportableArtifacts.annotationsZip)
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: I6d6c57c5417ca71eab5ddda7981b71fd84fa6ee1
The different roles of stubs (e.g. dependency to java modules,
hiddenapi, dist to sdk snapshot) are now split to different set of stubs
(everything, exportable and eventually runtime), while a single set of
stubs are responsible for all roles for the prebuilt stubs. Thus, the
stubs from source are depending different stubs tag (e.g.
everythingStubsTag, exportableStubsTag), while the prebuilt stubs
utilize stubsTag. Given that this tag is only used for the prebuilt
stubs, it can be renamed to `stubsTag`.
Test: m nothing --no-skip-soong-tests
Bug: 319162970
Change-Id: Iacdf434fab6a403482fd2f1de24e6f260ad80756
aosp/2876754 missed adding error handling to one of the places which
consumes the dex jar deapexed from prebuilt apexes. This CL ensures that
when we have multiple prebuilt apexes _without_ flagging, the hiddenapi
processing code emits a more descriptive error "Multiple deapxers..."
rather than a cryptic error "<module> does not provide a dex jar"
Test: m nothing --no-skip-soong-tests
Change-Id: I80849fa7cca17d724ac53c94bb353b169175ee28
This change modifies the copy rules of the sdk_library when generating
the module sdk snapshots so that the exportable artifacts (annotations
zip, api file, removed api file, srcjar file) are copied instead of the
everything artifacts.
In order to satisfy the prebuilts compatibility, this feature is flag
guarded by the build flag "RELEASE_HIDDEN_API_EXPORTABLE_STUBS"
Test: m --no-skip-soong-tests
Bug: 315027929
Change-Id: I8bf5bb1f196aa9b5db78ba4677caa5f4337e3021
This change modifies the dependencies of the hiddenapi to always depend
on the exportable stubs, instead of the currently utilized everything
stubs.
To support this, the full api surface exportable stubs are defined in a
separate change at the `frameworks/base` project. Note that the full api
surface exportable stubs are only used for the hiddenapi purpose, and
`sdk_version` continues to utilize the currently existing everything
stubs.
Currently, this feature is hidden behind the build flag
"RELEASE_HIDDEN_API_EXPORTABLE_STUBS". This feature will be fully
enabled once metalava fully supports handling of the flagged apis.
Test: ENABLE_HIDDENAPI_FLAGS=true m
Bug: 317426356
Change-Id: I109b7cd27b20ceffcdf1766ab8106b0c276be2b3
This is a followup cleanup for aosp/2876754 and replaces panic with
ctx.ModuleErrorf. The latter creates a more expressive build error.
Implementation details
- export moduleErrorf interface from build/soong/android. This minimal
interface will be used as a parameter for `DexJarBuildPath`
- Add ModuleErrorf to the function signature of DexJarBuildPath. This
parameter only gets used for Import and SdkLibraryImport structs.
These two can have duplicate deapexer definitions, and ModuleErrorf
will be used to report that error
- Create a minimal implementation of `ModuleErrorf` in tests of java and
apex
Test: m nothing --no-skip-soong-tests
Change-Id: I0febec651f40c3f04deb957e64133c94b80fbd78
Given that now the droidstubs module generates the "exportable" stubs,
this change modifies java_sdk_library to generate the java_library
modules that compiles the "exportable" stubs per api scope.
The detailed naming scheme of the generated modules are available in the
bug linked in the footer.
Similar to the from-text java_api_library vs from-source java_library
static lib selection for the "everything" stubs, the "exportable" stubs
module can also toggle between the stubs java_api_library and the
java_library module. However, given that the "exportable" stubs
generation has not been implemented for from-text stubs, the module
always default to depend on the from-source "exportable" stubs compiling
java_library module.
Test: go test ./java
Bug: 315495926
Change-Id: I5798312c1338c55625b2030da728b056385171a4
In consideration of the incremental build performance, this change let
droidstubs and java_sdk_library (which generates droidstubs per api
scope) modules to specify `aconfig_declaration` modules where the
dependent flags are defined in via the "aconfig_declarations" property,
opposed to passing uniform "all_aconfig_declaration"-generated flag
arguments to metalava.
When "aconfig_declarations" property is defined for java_sdk_library
modules, the property is passed to the generated droidstubs modules.
When "aconfig_declarations" property is defined for droidstubs modules,
the all aconfig_declaration modules listed in the property are listed as
deps, all cache protobuf files are gathered and metalava-consumable
flags are generated in "revert-annotations.txt".
Although this change introduces scalable implementation to easily
support generation of the "runtime" stubs corresponding flags, actual
support of the runtime flags/stubs will be done in future changes. This
change mostly focuses on the generation of the "exportable" flags.
Utilization of the generated "exportable" flags will be done in future
changes.
Test: go test ./java
Bug: 315485740
Change-Id: I37becd1b9dd9069d7ac4abed130906df30b3fdf4
hiddenapi and dexpreopt require boot and system server jars from apexes.
When building with prebuilts, this comes via
java_import/java_sdk_library_import, which acts as a hook for
prebuilt_apex/apex_set. If we have multiple apexes in the tree, this
hook becomes 1:many. This CL prepares dex_bootjars to select the right
deapexerd .jar files when mutliple prebuilts exist.
Implementation details
- Update prebuilt module types (prebuilt_apex/apex_set) and source
apexes to set a map of
library name to dex jar path on host.
- dex_bootjars will access the path of the .dex jar on host via the
provider. These then
copied/installed to the right locations.
This CL does not drop the old mechanism to get the dex file (i.e. by
creating a dep on java_library). Once all mainline
modules have been flagged using apex_contributions, the old mechanism
will be dropped
Bug: 308790457
Test: git_master-art-host:art-gtest https://android-build.corp.google.com/builds/abtd/run/L21500030000926533
Test: git_main:art_standalone_dexpreopt_tests https://android-build.corp.google.com/builds/abtd/run/L99000030000891212
Test: Added a unit test that checks that the right .jar is selected
when multiple prebuilts exists
Change-Id: I6ef94135b9303a35135810930af4b641df13a583
FindDeapexerProviderForModule raises an exception if multiple apexes in
the tree has an export dep on the java module. In prepartation to
support multiple prebuilts, move this error check out of
FindDeapexerProviderForModule and into rdeps. i.e. raise an exception
only if an rdep calls DexJarBuildPath
- This should be a no-op for now.
- In the short-term future, a java import module will be allowed to have
multiple deapexers. An error will be raised if anyone actually tries
to depend on the dexjar
- In the long-term future, this function will be removed. All processing
will be done at the prebuilt apex level and not at the prebuilt java
library level
Since this check now happens in the moduleCtx of rdeps, add some
additional props to unit tests to ensure that it does not exit early on
unrelated validation checks (e.g. hidden_api prop is not set)
Test: go test ./apex ./java
Bug: 308790457
Change-Id: I3323d993c1ea8f43305834cae8e65b6fe41dfefd
dexpreopt of apex system server from prebuilts involves three soong
modules
1. prebuilt_apex / apex_set
2. an internal deapexer module created by the prebuilt apex
3. java_import/java_sdk_library
(3) acts as a shim for the deapexer to set the dexjar extracted from the
prebuilt apex. This methodolody requires a 1:1 correspondence across the
three modules
This breaks down when we have multiple versions of the same prebuilt
apex in the tree. In preparation for this, move the dexpreopt
processing from (3) to (1). Each prebuilt_apex will create the necessary
rules for dexpreopting the jars deapexed from itself. In the future,
apex_contributions will be used to pick which service-foo.{odex|.vdex} to
install depending on which prebuilt apex is selected.
Implementation details
- Embed dexpreopter in prebuiltApex structs so that this module type can
register the dexpreopt rules. Since a single apex can have multiple
system server jars, this also requires creating an additional scope in
dexpreopt.go to prevent name collisions
- Add the dexpreopt modules as required in initApexFilesForAndroidMk
- Add the depreopt modules to androidMk in AndroidMkEntries. Drop the
equivalent from java_import and java_sdk_library_import
Bug: 308790457
Test: existing soong unit tests
Test: lunch cf_x86_64_phone-next-userdebug && m out/target/product/vsoc_x86_64/system/apex/com.google.android.adservices.apex
Test: Verified that the above command installs
/out/target/product/vsoc_x86_64/system/framework/oat/x86_64/apex@com.android.adservices@javalib@service-adservices.jar@classes.{odex|vdex} and the equivalent files of service-sdksandbox
Test: presubmits
Change-Id: I01cea8956d2857fb864b415e73d3d2686d069b5e
Convert all of the callers of OtherModuleProvider/OtherModuleHasProvider
to use the type-safe android.OtherModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: Id77f514d68761a262d9ea830a601dbed804bbbe5
Convert all of the callers of Provider/HasProvider to use the type-safe
android.ModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: I73479de1625fa2865b6c73444cd477e50d56dc5a
Convert all of the callers of SetProvider to use the type-safe
android.SetProvider API.
Bug: 316410648
Test: builds
Change-Id: If58f4b5355264ddab2045bc3591a4eac19cd58fc
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
The default-false bool property `contribute_to_android_api` will be used to signify whether the java_sdk_library module contributes to an api
surface (i.e. listed in frameworks-base-api.bootclasspath or not).
If the property is set to true, the module's stub jar can be
generated from .txt files.
Currently, the property is a no-op. The property will be utilized in the
child changes.
Test: m nothing
Bug: 276958307
Change-Id: I617802ec352c7055579ce92ea3de43f10cac1da4
java_sdk_library has historically suppressed a few legitimate lint
errors. Make it possible to remove these suppressions via a flag.
Bug: 306806877
Test: checkapi
Merged-In: I10577dacbd7ea8063c6e1e02f3b6c60a2bee5094
Change-Id: I10577dacbd7ea8063c6e1e02f3b6c60a2bee5094
The name of the sdk library will be used in source vs prebuilt
selection. For soong modules that are not dynamically created from a
java_sdk_library, the value will be nil.
Bug: 308174768
Test: TH
Change-Id: Ic7e9889f00c6184992b663a7124967bb0794d475
Provides SdkTestCore/test_core_current sdk_version for non-updatable
modules that have their test scope dependent on test apis from
framework-minus-apex.
Ignore-AOSP-First: Change in topic with internal-first projects
Bug: 289776578
Test: m checkapi | go test ./java
Merged-In: Iba3213e8c34ea75ac9dd8532a95ef62fb5455e6c
Change-Id: Iba3213e8c34ea75ac9dd8532a95ef62fb5455e6c
Currently, there is no build action ensuring that the API text files are
up to date, unless a user runs `m checkapi` or `m update-api`. This
means that the user must run `m update-api` after making a change that
modifies api surface(s), so that the API text file reflects the local
change. This adds additional layer of action to developers, and it is
not guaranteed that the developer will always run `m update-api` after
making an api surface-affecting changes.
To prevent such mistake, this change adds droidstub-level api check as
validation for from-text stub generation. With this change, the build
will fail if the API text file is not up to date and the user must run
`m update-api` when making api surface-affecting local changes.
The validation is done by adding all droidstubs modules associated with
the java_api_contributions passed to java_api_library via
`api_contributions` as dependency and setting the current api timestamp
files as the validations for the from-text stubs generating build rule.
The full api surface libraries will not run the validations to avoid
circular dependency. However, all java_sdk_library generated
java_api_library modules will run validations, mapped to the droidstubs
in the same api domaion.
If the user sets the environment variable `DISABLE_STUB_VALIDATION=true`, validation
actions are not run. Validation actions run by default.
Test: m nothing --build-from-text-stub and run ninja query to verify `check_current_api.timestamp`s are listed as validation \
DISABLE_STUB_VALIDATION=true m nothing --build-from-text-stub and run ninja query to verify that validation actions are not added
Bug: 288624417
Change-Id: I329e6438fe8f3ac30d8c6a971d57853ed6b0d150
java_api_library modules generated from java_sdk_library get
full_api_surface_stubs corresponding to the api surface that the module
contributes to. However, modules generated from java_sdk_library where
sdk_version is none should not depend on the full api surface stub jar.
Test: m --build-from-text-stub
Bug: 288624417
Change-Id: I7edda3e6a40f739e805e8719b8d366da765a6933
System_modules property provides the jars passed as bootclasspath when
compiling the stubs in the java_api_library where its creating
java_sdk_library's sdk_version is none, as the jars will not be provided
from the full_surface_stub_libs but compiled by itself in the child
change.
The jar provided by the system_modules will also be passed to metalava
to resolve hierarchy coming from outer dependencies.
Test: m --build-from-text-stub
Bug: 288624417
Change-Id: I8f3b89efa24bceb070d7a37fae3c7334dd7f0868
With api_files property being removed from java_api_library, all api
files are passed to java_api_library via java_api_contribution, which
provide api_surface information. Instead of relying on the naming
convention of the api files, java_api_library can utilize this
information to sort the api files from narrower api scope to the wider
api scope.
Test: m --build-from-text-stub
Bug: 295429988
Change-Id: Idd832778833c072c6b7e9d1f775533e5f4e2af00
This no-op refactoring facilitates some upcoming functional changes for
"bp2build allowlist v2". The work requires that the bp2build conversion
mutator be changed from a TopDown mutator to a BottomUp mutator.
Refactoring all bp2build-related methods so that they use Bp2buildMutatorContext
makes it easier to make this functional change without touching tens of
files and multiple projects.
Bug: 285631638
Test: m bp2build
Change-Id: I3d1ef3064146e959c6f0dc315350fc9764bf2bd2
Test: go test bp2build conversion tests
Test: enable modules build from prebuilt and m nothing
Bug: 300640274
Change-Id: I8c015aec546d052bef6c42869e12db4e87d39780
This change modifies sdk_library_import so that it directly creates
java_api_contribution per api scope. The module creates api_contribution
module for api scopes where the api file is specified.
Test: m nothing && MODULE_BUILD_FROM_SOURCE=false m nothing
--build-from-text-stub and inspect ninja dependency of java_api_library
Bug: 300175323
Change-Id: I74be3b4f1efef7f7d1cb8bd7b6c893b9cef0f370
java_sdk_library generates stub java_library module which compiles the
stub generated from either source or txt files, which is toggled based
on the build configuration. The java_api_library/java_library module
that compiles the stubs should not be directly accessible to the modules
outside of the sdk_library module scope, thus modify their visibility as
private.
Test: m nothing
Bug: 299373105
Change-Id: Ia4a08bf6e65c521814c82f54ea43cc8d367834e3
Since full_api_surface_libs extract class files instead of srcjar file,
full_api_surface_stub can be replace with android_*_stubs_current,
instead of the api_library android_*_stubs_current.from-text.
Functionally, the class files of the two modules are identical (in
from-text stub build), but depending on the from-text java_api_library
leads to missing dependency errors in partial branches (especially ART
branches). To resolve this problem, make sdk_library generated
api_library depend on the missing dependency handled
android_*_stubs_current.
Since android_module_lib_stubs_current.from-text does not have its
from-source equivalent, this can remain as dependency as the module is
moved to build/soong in aosp/2674196
Test: m (default to from-text stub build)
Bug: 274805756
Change-Id: Ic8bbd25252e5f9f1dc7c059ce6b00a951188985d
legacy.i18n.module.platform.api, stable.i18n.module.platform.api and
conscrypt.module.platform.api contributes to api surfaces, but the
corresponding stub libraries were being generated from source during
from-text stub build. This discrepancy may lead to hiddenapi failure.
Thus, enable these modules to be built from txt files during from-text
stub build.
Test: m
Bug: 274805756
Change-Id: I940dc8484b210bb8aea57ead1055983be7cdf5ec
Currently, stub java files are extracted from srcjar file provided from
dep_api_srcs in java_api_library module generated in java_sdk_library
per api scope. However, compiling the java files may lead to difference
in the content of the generated class files even if the stub java files
are equivalent, as javac may arbitrarily add overridden methods. Thus,
create a stub jar file instead of creating a stub srcjar file and
compiling it, in order to guarantee stub jar files content equivalence
and thus enable hiddenapi during from-text stub build.
Note that this change does not fully resolve differences between the
full api surface csv and the per sdk_library csv. Instead, it removes
the difference caused by methods arbitrarily added by javac.
This change also renames dep_api_srcs to full_api_surface_stubs to be
more intuitive.
Test: rebase on top of aosp/2617274 and `m --build-from-text-stub`
Bug: 275570206
Change-Id: I22b6d56624633681f5c3b000370b5782655c7b8d
Metalava no longer looks for common typos. It relies on the code
analyzers that run on Gerrit to detect them.
Bug: 288072162
Test: m checkapi
Change-Id: I08eca8008af39ebe69442db419ebd3d3378aa0de
