`UpdateDirectlyInAnyApex` is used to propagate the ApexProperties
`DirectlyInAnyApex` and `InAnyApex` to the direct dependencies of the
direct dependencies of an apex bundle. In other words, this will be
propagated only to two-levels max dependency from the apex bundle.
However, the implementation library of the sdk library can have longer
dependency chain from the apex bundle than two levels:
e.g. apex -> bcpf -> sdk_lib -> sdk_lib impl lib
Therefore, even if the implementation library of the sdk library is
registered as a dependency using the "CopyDirectlyInAnyApexTag"
dependency tag, the ApexProperties would not be propagated to the
implementation library. In order to resolve this issue and recognize
the implementation library to be directly in apex and allow
instrumentation for the implementation library, this change proposes
propagating `DirectlyInAnyApex` and `InAnyApex` to transitive
dependencies on top of direct dependencies.
Test: DIST_DIR=dist_dir TARGET_BUILD_VARIANT=userdebug PRODUCT=mainline_modules_x86_64 COVERAGE_MODULES="uwb" ./vendor/google/build/build_unbundled_coverage_mainline_module.sh && \
unzip -l out/target/product/module_x86_64/jacoco-report-classes-all.jar and ensure that framework-uwb is included
Bug: 341170242
Change-Id: I27d7a74f6e5bc3e0a044d13c619f4897b6b2eb57
To include a sdk library impl and a permission xml for that.
Bug: 340365498
Test: m aosp_cf_system_x86_64 && check if there is a sdk lib impl and
permission xml
Change-Id: I10190fb9d398b6249efd6fe50b204e328250f23f
Currently, the implementation library of the java_sdk_library is always
being instrumented due to the issue described in b/159241638.
With https://r.android.com/3079425, all compilation actions of the
java_sdk_library is delegated to the implementation library.
Consequently, this has caused all java_sdk_library to be instrumented,
leading to coverage builds failing due to double instrumentation (i.e.
instrumenting an already instrumented class file). In order to prevent
such error, this change modifies the property of the implementation
library to not instrument during coverage builds.
This change also copies some additional java library properties from
that of the implementation library to the top level sdk library, in
order to ensure that all non-null androidmk entries are correctly
reflected in that of the sdk library.
Test: lunch husky-trunk_staging-userdebug && EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m droid dist
Bug: 340174053
Bug: 341170242
Change-Id: I9d8f1c190205fa7a827649961ba5222293a945ad
This replaces the global override of min_sdk_version (via
`APEX_GLOBAL_MIN_SDK_VERSION_OVERRIDE`) with an min_sdk_version override
that can be set by each individual soong override_app.
The use case for this are go apps which are only installed in T and
above, even though the base AOSP apexes might be installable on < T
devices.
Test: added a unit test
Bug: 295311875
Change-Id: Ie2e738a6786bb24417c675617f7c78358017c96c
This change modifies the build actions of java_sdk_library module type
so that it does not perform any compilation actions (i.e. does not
create the top level java_sdk_library jar file). Instead, it delegates
the build actions the top level jar file was performing to the
dynamically created ".impl"-suffixed java library module. The build
actions that are delegated to the impl library module include hiddenapi
processing, dexing, and dexpreopt.
This change relands https://r.android.com/3035972. Implementation
changes from the original change:
- "all_apex_contributions" is added as a dependecy to the implementation
library modules where the parent sdk_library module has a prebuilt
equivalent. This allows the source apex variant to be hidden from make
when the prebuilt is active.
Test: patch in internal main, lunch barbet-ap2a-userdebug && m nothing
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: I017938e5567aef82e428e7ceb557d9c9090e0257
This allows using select statements with it.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6f3efaaa3d82505e38a91ee4ba0e18e404360191
Merged-In: If355d24506e3f117d27b21442a6c02bca3402dc7
Bug: 333311683
Test: build android.bp system image and then check if there is
permission xml file for sdk_library
Change-Id: If5ac1975a7db10d85a1b11c1cd666051e3da546e
This change supports passing multiple last api files to metalava,
instead of emitting an error when multiple files are passed as inputs.
The last api file providing modules are filegroups or genrule modules
that output exactly one output file. This change modifies that behavior
so that the filegroups can output multiple api files.
The last api file providing modules are (mostly) generated from the
`prebuilt_apis` sdk module. However, these modules only provide a single
api scope txt files (e.g. system api scope last api file filegroup
would only provide last system api file, not system + public). This
change modifies `prebuilt_apis` by generating "combine" filegroup
modules, that include api files of the subset api scopes as well.
The ordering of the files are handled when generating the combined api
filegroup modules, and droidstubs module does not check whether the
passed api files are in order from the narrowest api scope to the widest
api scope.
Submission of this change will be done once metalava fully supports
handling multiple api files input for api lint and nullness migration.
Test: m nothing
Bug: 321827591
Change-Id: I2066e7ceb7ee7c6d0fd87cd43bfd08db906d4b8f
aosp/2984037 disabled dexperopt of the source apex system server jars
when prebuilts are selected. This was done to prevent duplicate
installation and dex2oat deps.
AOSP art has some additional variants like com.android.art.debug. In
source builds, this apex should contain service-art.jar and
service-art.jar.prof (a dexpeopt artifact). We have a test to check this
(`art_apex_test.py`). If we disable dexpreopt of source sdlib when
prebuilts are selected, this test needs to be disabled. This is the
behavior at ToT.
This CL changes the behavior to enable running this test even when
com.google.android.art prebuilt is active in a specific release
configuraiton. To prevent collisions that prompted aosp/2984037, this CL
special-cases the installation and dex2oat rules instead of disabling
dexpreopt of the source sdklib altogether.
b/331665856 tracks the principled solution to prevent duplicate
dexpreopt rules.
Implementation:
Add a new copyApexSystemServerJarDex arg to GenerateDexpreoptRule API.
If true, the dexjar file will be copied to
out/soong/system_server_jars/. For soong modules, the value of this will
be the inverse of disableSourceApexVariant. Since none of the apex
system server jars are in make, this will be a noop in dexpreopt_gen
Bug: 331665856
Test: modified trunk_staging.scl locally to select
art.google.contributions.prebuilt; mmma art; (with the sibling CL in
topic)
Change-Id: Idb59e424f83d126cdc8b1671dde358745979bd8d
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
