The build ations will be created by the top-level apex.
Details
1. In GenerateAndroidBuildActions, do a graph walk to determine if the
apex has exported deps.
2. If there are exported deps, call the newly introduced `deapex`
function. This registers the build rules and returns a DeapexerInfo
object. This was previously provided by the internal deapexer
dependency.
3. Update `dexpreoptSystemServerJars and `provideApexExportsInfo` to use
the DeapexerInfo object from (2).
A lot of unit tests that relied on the legacy mechanism of deapexing
have been updated.
Test: go test ./apex
Test: lunch cf_x86_64_phone-next-userdebug (uses mainline prebuilts)
Test: verified no diff in file_list.txt
Bug: 368337090
Change-Id: I0edb681beccac4d2a9ceb73f9a506c081a8a96e0
prebuilt_apex/apex_set currently supports its deapexed contents to be
returned via a sibling java_import/java_sdk_import module. This is
necesssary for
1. dexpreopt/hiddenapi processing
2. usage as shared library
(1) is no longer necessary. this information is provided by the
top-level prebuilt apexes now
(2) is no longer possible since `exported_java_libs` has been removed in
https://r.android.com/3272110
This CL uses a hack for java_sdk_library_improt. Even though (1) is
provided by the top-level apex, there are still some places where
dexpreopt/hiddenapi processing visits the import modules. This CL uses
a bogus path to make analysis work. If this bogus path gets used, there
will be an error during ninja execution
Test: go test ./apex
Test: in internal lunch cf_x86_64_phone-next-userdebug (uses mainline
prebuilts)
Test: verified that file_list.txt is same
Bug: 368337090
Change-Id: I0ea2327f648f0fc60e337b232f7265e140772ffd
The property was introduced as an interim solution, and is currently
unused.
Test: m nothing --no-skip-soong-tests
Bug: 366071058
Change-Id: I57abdb64fabdb34fbbd1190851bc528dbb88c7f8
To enforce that selects are only evaluated after a certain point
in a followup cl.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: Ib215fedb904aa2e5f4d65cfd26a23f527eb4983e
This property was introduced for inter module dependencies in the
prebuilt module sdk. https://r.android.com/3252814 changed the visibilty
of all prebuilts in module sdk to //visibility:public. This property is
a noop now, and can be removed.
Test: go test ./sdk
Bug: 365111645
Change-Id: I186a201895fc2b33a65bbedae8a8326e087feb2b
https://r.android.com/3252814 modified the visibility to
//visibility:public to account for visibility skew between development
and release branches.
Drop the comment about stub libraries being safe to use by any _rdep_.
There might be cases where this is not true.
Test: N/A
Bug: 239189932
Change-Id: I74ca661a40384d480148f5e18f76495e837c58e3
To reduce pains introduced by visiblity skew between source
and prebuilts, mark them with //visibility:public
Bug: 239189932
Test: go test ./sdk
Change-Id: I47dd63bd03337bc9ec6fa364bbdcdfdfcd70b0d9
Pass the name of Soong's checkbuild target for each module to
Make so that it can depend on it from the main checkbuild rule.
This will give better control over which files get built, allowing
checkbuild to skip the jar combining step when transitive classpath
jars are enabled. The per-module checkbuild targets are passed to
make instead of added directly as a dependency of checkbuild in order
to maintain the existing behavior of only building modules exposed
to make in checkbuild.
Also tweak the existing calls to CheckbuildFile and add
InstallFileWithoutCheckbuild to match the files that are
in the Make-based checkbuild.
Bug: 308016794
Test: m checkbuild
Change-Id: Ic5140819381d58f4d00f23a7a12447950c4cf268
This change introduces a method to detect violating inter-container
dependencies between modules. The method is run in
`ModuleBase.GenerateBuildActions`, after the container info provider is
set. Given that the provider of the direct dependencies would have been
set at this time, the method utilizes this information to determine
the violations, which are introduced in https://r.android.com/3141104.
Note that this enforcement does not turn all inter-container
dependencies as errors. Instead, it will only turn dependencies that
matches the pre-defined violations into errors. Even if the dependency
matches the violation, an error will not be thrown if the dependency
satisfies any of the exception functions (e.g. the dependent module is
stubs, or the two modules belong to the same apexes).
Test: m nothing --no-skip-soong-tests
Bug: 338660802
Change-Id: Ib9ddc0761fa46f1309b1a1a4f759d9a4e04fd70e
This change introduces a method to detect violating inter-container
dependencies between modules. The method is run in
`ModuleBase.GenerateBuildActions`, after the container info provider is
set. Given that the provider of the direct dependencies would have been
set at this time, the method utilizes this information to determine
the violations, which are introduced in https://r.android.com/3141104.
Note that this enforcement does not turn all inter-container
dependencies as errors. Instead, it will only turn dependencies that
matches the pre-defined violations into errors. Even if the dependency
matches the violation, an error will not be thrown if the dependency
satisfies any of the exception functions (e.g. the dependent module is
stubs, or the two modules belong to the same apexes).
Test: m nothing --no-skip-soong-tests
Bug: 338660802
Change-Id: Ia693c4a53369c757a3e96656a769405c759b111c
This reverts commit bb678f82d6.
Reason for revert: Droidmonitor created revert due to b/362639013. Will be verifying through ABTD before submission.
Change-Id: I1dcb71672eeb44a17cf176d3731bcaf9aaf81edf
This change introduces a method to detect violating inter-container
dependencies between modules. The method is run in
`ModuleBase.GenerateBuildActions`, after the container info provider is
set. Given that the provider of the direct dependencies would have been
set at this time, the method utilizes this information to determine
the violations, which are introduced in https://r.android.com/3141104.
Note that this enforcement does not turn all inter-container
dependencies as errors. Instead, it will only turn dependencies that
matches the pre-defined violations into errors. Even if the dependency
matches the violation, an error will not be thrown if the dependency
satisfies any of the exception functions (e.g. the dependent module is
stubs, or the two modules belong to the same apexes).
Test: m nothing --no-skip-soong-tests
Bug: 338660802
Change-Id: I36e9cd956c5a076a53635be0c6ff27f77725516e
So that you can use selects with them.
Bug: 342006386
Bug: 358377461
Test: m nothing --no-skip-soong-tests
Change-Id: I5a8350f670d51b7da411ad5c3cdbf5f2d6cdd63b
Add a helper function that creates a test fixture preparer that
sets a build flag, and use it everywhere that was setting build flags
manually.
Test: all soong tests
Flag: EXEMPT refactor
Change-Id: I68d50d68787a30d091f0827e8caa51f5c5a762ef
cc_prebuilt_library_shared does not currently support generating stubs
from API symbol_files, and therefore the symbol file was removed from
the module sdk snapshots in https://ag.corp.google.com/11394495
As part of b/275273834, the stubs will be generated from the API files
for cc_prebuilt_library_shared, so add the symbol file back to the
module sdk
Bug: 275273834
Test: m nothing --no-skip-soong-tests
Test: m art-module-sdk and verified the map.txt is copied to the zip
next to the Android.bp file
Change-Id: I9551e7b8a76ceb9db3ed0434d315b6839f5e3d54
Setting sanitize and stl to nil in a mutator isn't valid, if any other
mutator creates a variant then the factory method will be called again
to create the new variants and will reset sanitize and stl to non-nil.
Add a property to sanitize and check it everywhere that checked for
sanitize != nil, and set the Stl property.
Bug: 319288033
Test: all soong tests pass
Flag: EXEMPT refactor
Change-Id: If99d5fa0f088ee4a73cc7dccdab4268618a6009f
Prebuilt cannot be stripped in older platform. Therefore, we set
stripper to none to skip the call to strip.sh.
Bug: 350050115
Test: SOONG_SDK_SNAPSHOT_TARGET_BUILD_RELEASE=Tiramisu m art-module-sdk
Test: Create module sdk from this and drop into tm-dev
Change-Id: I911ce24ca18435f95395c43fc5e73110a50b3067
In the context of incremental soong, the output files
inter-module-communication will be through OutputFilesProvider.
The OutputFileProducer interface will be deprecated.
Test: CI
Bug: 339477385
Change-Id: I786661d2ef882fe5dc7a0f67fa28f5df78f1f259
This change modifies the contents of the generated Android.bp files so
that when generating a snapshot on a older platform, the "exportable"
modules are removed from the bp files, as the "exportable" modules are
first introduced in V and do not exist in older platforms.
Bug: 345162614
Test: ABTD
Change-Id: I2dba51b98deec7805bd796647a66981f237c55a9
platform-bootclasspath constructs the monotlithic hiddenapi flags by
looking at PRODUCT_BOOT_JARS which are not included in another
bootclasspath fragment. PRODUCT_BOOT_JARS is a product specific
property, and non java devices like minidroid have an empty value for
this. For such devices, the monolithic flag generation runs into an
error because there are no jars to run this on.
This CL disables the generation of monolithic specific hiddenapi flags
when there are no monolithic boot jars in the build.
Bug: 338363444
Test: lunch aosp_cf_x86_64_minidroid-trunk_staging-userdebug && mmma
frameworks/base
Change-Id: I093690786bcf85b2aa6f01d0c689fc2a35861b5c
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
Revert submission 3070882-sdk_lib_remove_compilation
Reason for revert: Potential culprit for build breakage of barbet-ap2a-userdebug in git_main
Reverted changes: /q/submissionid:3070882-sdk_lib_remove_compilation
Change-Id: I5135760e13e0152480c68fe91a3c88564e9bc7cb
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.
Test: m nothing --no-skip-soong-tests
Bug: 332785297
Change-Id: I7534f9eaacf6d9f72fbf8d540b1e26af84106c20
A follow-up change broke `TestSnapshotWithJavaSystemModules()` during
development. The code was fixed but it revealed an issue with the test
coverage of that test. That test only supported `public` APIs and the
fix could have had different behavior on `system` and `module-lib`
APIs. This change adds them to the test to make sure that the follow-up
change works correctly for them too.
Test: m --no-skip-soong-tests nothing
Bug: 321827591
Change-Id: I3b5570f5d4f0764ae365bfc448f287b50b9c2686
The host variant of libdexfile and its deps were added to module sdk to
support the use case of building platform tests without art's source
code. This use case is not very relevant today, so we can drop the host
variant of these modules from the module sdk.
We still need to keep them in <= U snapshots, so this CL uses a hack to
drop these libraries only if `SOONG_SDK_SNAPSHOT_TARGET_BUILD_RELEASE`
is greater than UDC
Test: SOONG_SDK_SNAPSHOT_TARGET_BUILD_RELEASE=UpsideDownCake m
out/soong/mainline-sdks/art-module-host-exports-current.zip # verified
that libartbase is in the generated Android.bp
Test: m out/soong/mainline-sdks/art-module-host-exports-current.zip #
verified that libartbase is not in the generated Android.bp
Test: In `main`, deleted the host variants from prebuilts/module_sdk locally; enabled art prebuilts;
Test: atest --host --no-bazel-mode libunwindstack_unit_test
Bug: 329830257
Change-Id: Iab23853ef5e96661a5f5c2989add1be32fb07fbc
This metadata module will contain a flattened list of all the soong
modules contributed by this module to the rest of the build. This is
supported in V and above.
Bug: 326246905
Test: m art-module-host-exports
Test: unzip -p out/soong/mainline-sdks/art-module-host-exports-current.zip Android.bp | grep -A 15 apex_contributions_defaults
apex_contributions_defaults {
name: "art-module-host-exports.contributions",
contents: [
"prebuilt_art.module.api.annotations",
"prebuilt_dex2oat",
"prebuilt_dex2oatd",
"prebuilt_dexdump",
"prebuilt_hiddenapi",
"prebuilt_oatdump",
"prebuilt_profman",
"prebuilt_veridex",
"prebuilt_libartpalette",
"prebuilt_libartbase",
],
}
Change-Id: Iba43a9da5430adfc0a5fd9b5dc27b5d89c5eacb8
* changes:
Copy exportable artifacts to module sdk snapshot
Enable hiddenapi check for exportable stubs
Add defaults support for bootclasspath_fragment module type
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
Every module belonging to a single mainline module family will be
hidden from make, except the one which has been flagged using
apex_contributions
Details
- Introduce a new `source_apex_name` property to prebuilt_apex and
override_apex. This property will be used to identify the source
equivalent of a prebuilt soong apex module.
- Create an N-ary tree from source to prebuilt(s). The tree wil be
rooted at the source module.
- In a subsequent mutator, visit every node in the tree(s). Query
apex_contributions and store the handle of the node which is "active"
(if any)
- In the same mutator, do another pass over the tree. Invoke
`HideFromMake` on every node which is not "active". The two-pass
approach is needed PrebuiltSelectionInfoProvider does not know about
the inter source-prebuilt dependency, this dependency can only be
known by doing a graph walk of the N-ary tree.
Some tangential implementation details
- Each prebuilt apex has an internal deapxer module that is responsible
for generating the deapex ninja rules. The name of this internal
module uses the BaseModuleName (without the prebuilt_ prefix). Since
we can have multiple prebuilt soong modules in trunk stable, change
this to follow the name of the prebuilt module in order to avoid name
collisions. Update existing unit tests accordingly
Bug: 316179314
Test: go test ./apex -run TestInstallationRulesForMultipleApexPrebuilts
Test: m nothing --no-skip-soong-tests
Test: presubmits
Change-Id: I58aa99d5e6a9859954614e6db9a8e9e2e581642d
This change generates rules for "exportable" stubs in the droidstubs
module.
Given that there are a lot of overlap between the currently existing
"everything" stubs rule and the newly introducing "exportable" stubs
rule, the currently existing metalava rule commands are modularized to
be utilized in the "exportable" stubs rule commands.
The currently existing build actions are modularized in the followings:
- commonMetalavaStubCmd(...): metalava commands that are required for
generation of both "everything", "exportable", and potentially
"runtime" stubs
- everythingOptionalCmd(...): metalava commands that are dependent on
"everything" stubs and not dependent on flagged apis annotations, such
as api lint, released api check
Based on this modularization, the "everything" stubs are now generated
in everythingStubCmd(...), which calls commonMetalavaStubCmd(...) and
everythingOptionalCmd(...).
Similarly, the "exportable" stubs are generated in
optionalStubCmd(stubsType=Exportable, ...), which calls
commonMetalavaStubCmd(...) and appends additional flags. Runtime stubs
can be generated similarly in the future with
optionalStubCmd(stubsType=Runtime, ...).
"everything"-related artifacts will now be created in
`everything/` subdirectory, and "exportable"-related artifacts will be
created in `exportable/` subdirectory. For example, the outdir of a
droidstubs module "foo" would look like below:
```
foo
|-- everything
| |-- foo_api.txt
| |-- foo-stubs.srcjar
|
|-- exportable
|-- foo_api.txt
|-- foo-stubs.srcjar
```
The module generates the build rules for the "exportable" stubs
regardless of whether the module defines the `aconfig_declarations`
property or not. All APIs marked with `@FlaggedApis` annotations are
stripped out for the "exportable" stubs when the `aconfig_declarations`
property is not defined. On the other hand, only the `@FlaggedApis` that
are specified in the aconfig_declarations module and are enabled will be
included (and all others are stripped) when the `aconfig_declarations`
propety is defined.
Test: go test ./java && BUILD_FROM_SOURCE_STUBS=true m
Bug: 315490657
Change-Id: I300273cd2a62fa978b046c0268e3a67c35e22b08
Convert all of the callers of OtherModuleProvider/OtherModuleHasProvider
to use the type-safe android.OtherModuleProvider API.
Bug: 316410648
Test: builds
Change-Id: Id77f514d68761a262d9ea830a601dbed804bbbe5
Some users want to repackage the results of an sdk module.
Genrules have 3 variants: linux, android, and common_os. The common_os
one produces a snapshot zip file that users want. In order to get
access to it, we need a genrule in the same variant, so create
an sdk_genrule for that.
The sdk_genrule shouldn't have linux/android variants either, because
those other variants would get errors when trying to depend on the
sdk modules because the snapshot zip doesn't exist in those other
variants. The code in arch.go needs to be tweaked to allow a common_os
variant without the other variants.
Bug: 315962165
Test: m dist out/dist/art_release.zip
Change-Id: Idc9b3cae7a525d71aed6bafa0f8724a89f75a94b
Add a test for that checks the SDK snapshot contains sdk library
definitions for modules with alowed minSdkVersion, but that doesn't
contain definitions for modules with disallowed minSdkVersions.
Bug: 289183551
Test: go test ./sdk
Change-Id: I194526f8eba4dacb52a345fa67cf7371e722c237
If a header jar couldn't be built (for example when an API generating
annoation processor is in use) the implementation jar is reused as the
header jar. If the implementation jar contains an annotation processor
listed in META-INF/services/javax.annotation.processing.Processor then
later javac executions with the implementation jar in the classpath
could attempt to run the annotation processors unexpectedly. Remove
the META-INF/services directory when using an implementation jar as
a header jar.
Bug: 290933559
Test: builds
Change-Id: I40d48644bc5a09a9564dc2c4b38f627edd00fcf8
In the past, dexpreopt for boot jars was very inflexible, and it was
incredibly hard to make a change that is as simple as adding a jar to a
boot image. Boot image generation was handled by
"platform_bootclasspath" and "bootclasspath_fragment" separately. This
caused not only code duplication but also the inflexiblity as such a
design did not fit today's use cases, where a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. The design casued a huge
maintenance burden as any change to the boot image cost multi-week
efforts.
In recent years, efforts have been made to improve this a bit by a bit.
This change is another step towards making dexpreopt reasonable.
After this change, all boot images are generated by "dex_bootjars",
which is in build/soong and is therefore available on both the full
source tree and the thin manifest (master-art). The change decouples
profile generation/extraction from boot image generation. Profiles for
mainline modules are still handled by "bootclasspath_fragment"
because they need to be packed into APEXes when building mainline
modules and extracted from APEXes whem building the system image from
prebuilt modules. Boot images are not handled by
"bootclasspath_fragment" anymore.
Bug: 290583827
Test: m (all existing tests are still passing)
Test: Manually checked that the boot images are exactly the same as
before.
Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
