In preparation for a refactoring that will dedup the registry code.
Bug: 195754365
Test: m nothing
Change-Id: I93e8485d588f5b4d6b5e2967da5dbef7b6c831ad
Adds a native bridge trait that if required will cause a
cc_library_header module to generate a cc_prebuilt_library_headers with
native_bridge_supported: true. It will fail if the cc_library_header's
native bridge variant would produce native bridge specific properties,
distinct from the other architecture variants, in the generated
cc_prebuilt_library_headers.
Bug: 195754365
Test: m nothing
Change-Id: I282fbb9095de6c6af57cca4eb4260e2c6c2da8cc
Previously, the snapshot code ignored native bridge related arch
specific variants and only used the non native bridge variants. This
change enabled it to track native bridge variants too.
There is currently no support for creating native bridge specific
prebuilts so this ensures that any attempt to create one will fail
during generation of the snapshot with a clear message.
At the moment that error message cannot be tested by creating an sdk as
there is no way to add a dependency from the sdk onto a native bridge
variant. A follow up change will add the capability to test this
functionality through an sdk.
Bug: 195754365
Test: m nothing
Change-Id: I0494fdba9cc2ff013ea990d12d6a03a0a444bd5c
Currently, every sdk member of a specific module type has to be treated
in the same way as every other sdk member of that type. e.g. it is not
possible for an sdk member to use different variants to other members
of the same type.
Adding a new member type for each different way to treat the members is
not scalable as if there were N different ways treat a member then it
would require 2^N types for all the possible combinations.
This adds a new traits mechanism that allows the behavior of member
types to be customized per sdk member. Each member type can specify a
list of supported traits and customize its behavior based on which
traits are required for each member. A trait can be supported by
multiple different member types.
Bug: 195754365
Test: m nothing
Change-Id: I165ac80d208c0402d2a9ffa8085bba29562c19b7
The annotations zip file is produced by the "main" sdk build and is
primarily consumed by android studio.
In order to support building the main SDK without requiring the sources
of all modules, we are adding module SDK artifacts that allows
reconstructing these outputs. The annotations zip contains XML files
which should be fairly easy to merge from all the individual parts.
Bug: 187397779
Test: unit tests in this CL
Test: m sdkextensions-sdk and inspect output
Change-Id: I955cae720e6f1382936836ee1d8fb11003f51b7d
Makes it adhere to the go standard practice of prefixing documentation
comments with the name of the type/func/method.
Bug: 195754365
Test: m nothing
Change-Id: Idf3fe827edc9b6d67d12a99a4b27539ac938ea95
Previously, some of the sdk member type related types and variables
included the words "member type" whereas others only used the word
"member" and did not include "type". This changes makes them all
include the word "type" to differentiate them from other types related
to sdk members.
Bug: 195754365
Test: m nothing
Change-Id: I913daaa1d436fd5dc857c2af0ffdee6471dcc6ed
Replaces the BottomUpMutatorContext parameter with a new
SdkDependencyContext type that extends BottomUpMutatorContext. This is
to allow the sdk to pass additional information to the implementations
of that method to allow the behavior to be more finely tuned.
Bug: 195754365
Test: m nothing
Change-Id: I69c6d2c523934eb67d7a7e6c55c241e9b8a81773
Previously, the sdk snapshot would include all the entries from the
stub-flags.csv and all-flags.csv modular files generated by a single
bootclasspath_fragment. That included implementation details, i.e.
class members that are not part of a stable API or the hidden API which
meant that the sdk snapshots were implementation dependent.
This change removes the implementation details from the modular flag
files, i.e. those entries that are only marked as "blocked". When
comparing the files against the corresponding subset of the monolithic
files it assumes that any entries missing from the modular flag files
are blocked.
Bug: 194063708
Test: atest --host verify_overlaps_test signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
- manually change files to cause difference in flags to check
that it detects the differences.
Change-Id: I6b67b2253cf029d6830b58a06ebb0c8fcaa0dd71
This is in preparation to r.android.com/1740313 where setting correct
variables would be enforced (i.e. apex and non-apex boot jars must be in
config.ApexBootJars and config.BootJars correspondingly).
Bug: 191369843
Test: m nothing
Change-Id: Ic86680c1f7af53d229083b2cc58beb3ceccb4b6a
Bug: 194063708
Test: atest --host verify_overlaps_test signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
- manually change files to cause difference in flags to check
that it detects the differences.
Change-Id: Ic819def9b0c41e3b22fb98582cd39f6d27080a32
Previously, the signatures used to select the subset of the monolithic
flags were simply the signatures read from the modular flags file. This
change moves the creation of the signature list into a separate script
that outputs the signatures to a file and then passes the path through
Soong from the bootclasspath_fragment modules that create it to the
platform_bootclasspath module that uses it to compare the modular
flags against the monolithic flags.
Currently, the signatures are the full signatures but follow up changes
will replace them with patterns (hence the name) that avoids having to
include implementation details in the hidden API flags that are output
as part of a bootclasspath_fragment's snapshot.
This change moves the stub flags related code next to the all flags
related code as they are treated in a similar way.
Bug: 194063708
Test: atest --host verify_overlaps_test signature_patterns_test
m out/soong/hiddenapi/hiddenapi-flags.csv
- manually change files to cause difference in flags to check
that it detects the differences.
Change-Id: I2855bf6d05c91b8a09591664185750361c7e644f
system_shared_libs has been modified to have the same behavior as
the newly added default_shared_libs, remove default_shared_libs in
favor of system_shared_libs.
This reverts Ia2349d84c70e503916f90a5d2702e135248f73df and renames
the default_shared_libs property in cc_object (which never had
system_shared_libs) to system_shared_libs.
Bug: 193559105
Test: m checkbuild
Change-Id: I46672e3a096b6ea94ff4c10e1c31e8fd010a163c
Note that ART apex boot jars and core-icu4j are exceptions here as they
are not part of ApexBootJars. ART apex boot jars are defined in their
own variable, while core-icu4j is treated as a regular non-updatable
boot jar.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I3cea3d82ef521655a1a5ffa8cae2258ab9d08bfc
Replace the android.BuildOs constant with Config.BuildOS so that it
can vary based on the product config.
Bug: 190084016
Test: all Soong tests
Change-Id: Ia67f872d8b2ab788747a22e3a9659dc21c9775cd
This reverts commit 22ff0aaf51.
The workaround to support hidden API generation with prebuilts by
passing the full implementation jars through to the SDK snapshot is no
longer needed as the monolithic hidden API flag generation uses the
prebuilt flag files that are already part of the snapshot.
This change reverts that previous workaround.
Bug: 192868581
Test: - Update the prebuilts
DIST_DIR=$PWD/dist TARGET_BUILD_VARIANT=userdebug art/build/build-art-module.sh --skip-apex
packages/modules/ArtPrebuilt/update-art-module-prebuilts.py --local-dist=dist --skip-cls --skip-apex
- Build hidden API flags to make sure it does not fail
Change-Id: Idb3fde6f7dcb171677316d8794a4af91ede1f7e0
Previously, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: I0cbf11986adff1f2f967b96f86e6bfe0e9b8b1ef
Previously, the java_import and java_sdk_library_import modules did not
make their permitted_packages available to the rule that generates the
updatable-bcp-packages.txt file. This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Change-Id: If0706e4551a331b48d383123088e63924dded48b
Previously, permitted_packages were not copied to the sdk snapshot.
This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Change-Id: I4560987f746f78c0ae706058195b6db4bea438aa
Allows the builder of an sdk snapshot to specify a Soong config
variable that can be used to control whether the snapshot's prebuilts
are used or not.
Bug: 193523070
Test: m nothing
Change-Id: Ib09500ba61befc1202dff61dc06847c730ba9253
This reverts commit d0b99cea0a.
Reason for revert: Not needed anymore. We will simple exclude the
gernated Android.bp files from prebuilt drops instead, it keeps
things simpler.
Change-Id: I5b01b2e01197f9fceb4630c8ade95f0d1d0f33f4
This is needed because:
- the SDK prebuilt drop is being automated, including the Android.bp
- We want to control the prefer flag on a per-module level
It augments the existing SOONG_SDK_SNAPSHOT_PREFER which now overrides
this new flag when set to true.
Bug: 188427719
Test: m nothing
Change-Id: Ieb5ab9fab53a34c615345b7a9d19cadf713eec26
cc_object files don't link against static or shared libraries, but they
can use headers from them. Make cc_object use the default_shared_libs
headers, and add support for explicit static and shared library
dependencies.
Bug: 153662223
Test: go test ./cc/...
Change-Id: I9ab160ede06db1b135d217d72770c22f500cfe1b
Previously, hidden API processing could only be done by those
bootclasspath_fragment modules that either did not depend on any other
fragments (e.g. art-bootclasspath-fragment) or only depended on APIs
provided by other fragments (e.g. i18n-bootclasspath-fragment). That
meant that modules like com.android.os.statsd-bootclasspath-fragment
that depended on APIs provided by parts of the platform which are not
yet part of another bootclasspath_fragment could not perform hidden
API processing.
This change adds support for a bootclasspath_fragment to specify the
additional stubs needed to perform hidden API processing. It adds a new
additional_stubs property that can be used to specify the additional
stub libraries.
Most bootclasspath_fragments that need to use the property will need
access to the APIs provided by the android-non-updatable.* libraries.
Rather than have each fragment explicitly specify the correct module
for each scope it treats "android-non-updatable" as if it was a
java_sdk_library that can provide different jars for each scope.
Soong will handle mapping that to the correct android-non-updatable.*
module.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv \
out/soong/hiddenapi/hiddenapi-index.csv \
out/soong/hiddenapi/hiddenapi-stub-flags.txt \
out/soong/hiddenapi/hiddenapi-unsupported.csv
- make sure that this change does not change the contents.
m TARGET_BUILD_APPS=Calendar nothing
Change-Id: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
Previously, a java_sdk_library with shared_library = true would create
a variation per APEX because it depends on an sdkLibraryXml module
which generates a file containing the APEX name. However, a shared
java_sdk_library_import would create a merged APEX variation. The
inconsistent variations caused failures in sdkDepsReplaceMutator.
This change ensures that both java_sdk_library and
java_sdk_library_import create an APEX specific variation when their
shared_library property is true.
Bug: 190499958
Test: m nothing
- ran the above command after modifying the test to reproduce the
problem and then after fixing to verify that it fixed the problem.
Change-Id: Iee81776a8569db3e871c40cbde14d248dfeb56e4
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Merged-In: I515f235fe21755b5275af12366e96c24c94c0273
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
(cherry picked from commit a1aa7387f7)
Adds support for printing a PropertySet that has a property whose value
is an array of structs.
Bug: 179354495
Test: m nothing
m conscrypt-module-sdk
- check generated Android.bp file
Change-Id: I71be04188465610bcbea4d3c9a5e8204171a1eeb
Building against a locally-built libc besides bionic requires setting
system_shared_libs to avoid circular dependencies, but modules all
over the tree assume that system_shared_libs only affects modules
building against bionic. Add a new default_shared_libs property
that applies to all modules, which will generally be set in
arch-specific clauses to only affect the desired set of modules.
Bug: 190084016
Test: m checkbuild
Change-Id: Ia2349d84c70e503916f90a5d2702e135248f73df
Previously, all of the supported types were handled explicitly using
type switches. This change switches to use reflection instead to allow
it to work with unknown types such as custom structures, support for
which will be added in a follow up change.
Bug: 179354495
Test: m nothing
Change-Id: I197f3f1dbce6d80c0127c99bbe6f836d422a8db9
This change adds a test for an sdk that includes a java_sdk_library
directly as well as transitively includes one of the component modules
that it creates. It also adds a test for the names of a versioned
java_sdk_library_import's components as fixing one requires fixing the
other.
The use case added is one that does occur in the art-module-sdk. It has
a couple of pairs of java_sdk_library and java_system_modules that
cause both the java_sdk_library and one of its component modules to be
included in the sdk snapshot. That causes problems when building
against prebuilts.
e.g. The art-module-sdk_art.module.public.api.stubs module is a
duplicate of the art.module.public.api.stubs module created by the
art.module.public.api java_sdk_library_import. The former is added
because the art-module-public-api-stubs-system-modules depends on it.
A follow up change will avoid the component being added to the sdk
snapshot separately and instead cause the snapshot to use the
component created by the java_sdk_library_import in the snapshot.
Bug: 179354495
Test: m nothing
Change-Id: Ifdc1b4a5a7968db2ded3fdb7eb02f9cff77c7c3f
Prebuilt modules do not provide classesJars containing annotations.
Previously, the monolithic hidden API processing just used classesJars
from all the modules that provided them so when building against
prebuilts would have fewer classesJars than when building against
sources and so would produce different hidden API flags.
This change will generate the monolithic files from both classesJars
and files previously generated from hidden API processing. A fragment
that has performed hidden API processing will contribute its generated
files whereas standalone libraries and fragments which have not
performed hidden API processing will contribute classesJars.
Bug: 177892522
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
m SOONG_CONFIG_art_module_source_build=false out/soong/hiddenapi/hiddenapi-flags.csv
- verify that the files are identical whether built from
source or prebuilts.
Change-Id: I06f3c7df49626bec21a452bc9abf1bb9e7545e5c
Bug: 177892522
Bug: 189298093
Test: m check-boot-jars
m SOONG_CONFIG_art_module_source_build=false check-boot-jars
- Ran both commands with and without java.lang in the
package_allowed_list.txt
Change-Id: Iba1a881c8f6b6919d5c0c0520eb3073658f3b8d2
In the input test fixture this makes sure that every
bootclasspath_fragment is part of an apex and every content module for
the fragment is listed in the appropriate boot jars config property. It
also adds a platform_bootclasspath fragment that references the
fragment.
In the snapshot test fixtures this adds a prebuilt_apex that exports
the fragment so that the platform_bootclasspath has access to the dex
implementation files.
Bug: 177892522
Test: m nothing
Change-Id: I6c73651a359052858232b06229b4433799dd94db
Previously, due to legacy reasons, the property validation did not
require a contents property and allowed the image_name to be either
"art" or "boot". Those reasons no longer apply and so this change
requires a contents property and only allows the image_name to be set
to "art" if specified.
Bug: 177892522
Test: m nothing
Change-Id: I8855d6e5365ef0b55490e90e7b6c0081cf070ee5
This change adds support for generating the hidden API flags for the
contents of a bootclasspath_fragment. Currently, it will only work for
the art-bootclasspath-fragment as it has no support for creating
dependencies between bootclasspath_fragment modules which will be
needed for handling any other bootclasspath_fragment.
The hidden API flag generation added by this change is completely
separate to the normal hidden API processing and is not as yet encoded
in dex jars so will have no effect on the runtime.
The generated files are provided for use by other modules and copied
into the sdk snapshot. That is needed to allow the build to verify that
the hidden API flags generated by the individual bootclasspath_fragment
modules are consistent with the flags generated for the whole
bootclasspath, whether building from source or prebuilts.
Bug: 179354495
Test: m art-module-sdk
m out/soong/.intermediates/art/build/boot/art-bootclasspath-fragment/android_common_apex10000/modular-hiddenapi/all-flags.csv
m out/soong/hiddenapi/hiddenapi-flags.csv
- test that the former file is a subset of the latter and that
where they overlap they are identical.
Change-Id: Ie27303e2960953db1b7abe95510e3bca4411b09a
A java_library specified in a bootclasspath_fragment's contents
property will be automatically added to the sdk containing that
bootclasspath_fragment. Previously, if that was attempted with a
java_sdk_library it would be added to the sdk as if it was a normal
java_boot_libs which would prevent the sdk from containing the
API specific artifact such as current.txt files and stub libraries
and sources.
This change fixes that and adds a java_sdk_library as a java_sdk_libs
module.
Bug: 177892522
Test: m nothing
Change-Id: Ided57b846ce5b8940c7e898c786fd77602582ea2
Adds the bootclasspath_fragment to an apex and also adds an sdk library
to the stub_libs property.
Bug: 179354495
Test: m nothing
Change-Id: I2a5fffe915eb62923cc60732352d4d050dec4398
SOONG_SDK_SNAPSHOT_VERSION=current will generate unversioned and
versioned prebuilts and a versioned snapshot module. This is the
default behavior. The zip file containing the generated snapshot will
be <sdk name>-current.zip.
SOONG_SDK_SNAPSHOT_VERSION=unversioned will generate unversioned
prebuilts only and the zip file containing the generated snapshot will
be <sdk name>.zip.
SOONG_SDK_SNAPSHOT_VERSION=<number> will generate versioned prebuilts
and a versioned snapshot module only. The zip file containing the
generated snapshot will be <sdk name>-<number>.zip.
Bug: 157884619
Test: m nothing
m SOONG_SDK_SNAPSHOT_VERSION=current art-module-sdk
- check that the generated Android.bp file has not changed
from the default.
m SOONG_SDK_SNAPSHOT_VERSION=none art-module-sdk
- check that the generated Android.bp file does not contain
versioned modules.
m SOONG_SDK_SNAPSHOT_VERSION=2 art-module-sdk
- check that the generated Android.bp file only contains
version 2 of each module.
Change-Id: I087e9d7d3ad110508a3d6a39bca50cbb46b3ce82
This ensures that the LSC license tool does not attempt to add a
package module to an sdk snapshot Android.bp.
Bug: 181569894
Test: m nothing
Change-Id: I37b66e0df56c5b9ec255f66cb4f2a066ea96a738
Adds initial support for adding license modules to the sdk, along with
any referenced license text files. There is a number of minor
improvements to be made but the core of the support is there and it
works for ART sdks.
Basically, this change will automatically add license modules
referenced from any sdk member module as an internal sdk member. An
internal module has an sdk snapshot specific name that will not
conflict with the source module and which cannot be referenced from
outside the sdk snapshot.
Bug: 181569894
Test: m art-module-sdk art-module-host-exports art-module-test-exports
- diff output before and after this change
made sure that every prebuilt had a licenses field
and that the license modules were added
Change-Id: I0c5ccabf58f4ef487e42ef8e61a5b2a74c0e81af
This change adds a test that includes license modules that are used by
modules which are part of an sdk but which does not yet copy the
license module into the snapshot. It includes the refactoring changes
needed to allow license modules to be used in an sdk test and provides
a baseline against which future changes can be compared.
Bug: 181569894
Test: m nothing
Change-Id: I60722f43cc9cc8375d97f46eb4c281e6c38987cd
Previously, the deapexer module properties were simply passed through
from the prebuilt_apex/apex_set modules. This change derives the
properties from the transitive dependencies of the modules so that it
can automatically include the contents of a bootclasspath_fragment
module without having to duplicate them in the exported_java_libs
property.
Part of this change involves moving the addition of dependencies onto
the prebuilt apex's contents from DepsMutator to ComponentDepsMutator
so that they can be visited in the createDeapexerModule() function. The
ComponentDepsMutator runs before prebuilts without matching sources are
renamed to match the source name which simplifies the process of adding
dependencies directly onto the prebuilts.
The deapexerDeps method was renamed as the dependencies are added both
for use by deapexer and also to create APEX variants for access by
platform_bootclasspath so the name was confusing.
Bug: 187266082
Test: m nothing
m SOONG_CONFIG_art_module_source_build=false nothing
- this fails but not because of missing APEX variants
Change-Id: Icb4f883e7d2b63739e5ff0dc6edb8a906d80189b
By default the generated snapshot has prefer: false. Building it with
SOONG_SDK_SNAPSHOT_PREFER=true will force it to generate prefer: true.
Bug: 157884619
Test: m nothing
m SOONG_SDK_SNAPSHOT_PREFER=true art-module-sdk
- check the generated Android.bp file to make sure it contains
prefer: true
Change-Id: Ied297b32d9bd4822a140fa99016f38e234c50f64
Previously, only those SdkMemberTypes which had specific need to
automatically add some of their dependencies as sdk members would cause
the sdk to visit their transitive dependencies. However, as any module
can have dependencies on license modules and license modules need to be
included in the sdk then it needs to visit transitive dependencies of
all members.
So, this change removes the support for allowing an SdkMemberType to
control whether its transitive dependencies are visited and just visits
them all.
This does not have any effect on sdk snapshots as in order for a
dependency to be added to an sdk it needs to be added with a tag that
implements SdkMemberTypeDependencyTag and the only tags that implement
this are used by SdkMemberTypes that had enabled transitive members.
Bug: 181569894
Test: m art-module-sdk art-module-host-exports art-module-test-exports
- verify that this change has no effect on the generated snapshots
Change-Id: If0293af0237aa7e39335e5b8383a41c023ff5853
Making licenseModule SdkAware caused two breakages in the build. The
breakages were both caused by having an SdkAware module that was
depended upon by a versioned sdk snapshot but which was not itself
versioned and so did not have the member_name property set.
That occured because some default licenses have been added to the
packages containing prebuilts, e.g. prebuilts_runtime_license in
prebuilts/runtime/Android.bp. They apply to both the versioned and
unversioned members.
Once license support has been added to the sdk most of those will be
removed and replaced with properly versioned license modules. However,
in the meantime it is necessary to support that.
This change avoids the issue by checking to see whether the module is
itself versioned before relying on the member_name property. It also
improves the error message when a panic is recovered to make it easier
to identify where it originates.
Bug: 181569894
Test: m nothing
Change-Id: I0e7da2e0c4a30a6f814c2faab821b185aaed2135
The tests use <sdk>_<module>_<version> as the format for a versioned
sdk member name but the format should be <sdk>_<module>@<version>. This
change corrects it and also fixes a similar issue in an error message.
Bug: 181569894
Test: m nothing
Change-Id: I8be0db4bcd0b6f4d6fbdf9e402ef7257fae8e18b
Using the InstallFile as the snapshot ensure that the artifact
in out/soong/mainline-sdks/ is built when building the sdk
target.
Test: m ipsec-module-sdk
Change-Id: I45ce6001dbae3a7a9c4cf50f8d7d5d67f94dbcb3
The getBootImageJar function will be removed once the boot image
creation has been moved to the platform_bootclasspath and
bootclasspath_fragment module types. However, the consistency checks
that it performs are still useful so this change moves them out
first.
The ART boot image related checks are now performed in the
bootclasspath_fragment module type. A previous change accidentally
disabled the checks when the contents property was not empty which has
been fixed. Also, the error messages have been tweaked to make it clear
that the art-bootclasspath-fragment is now the source of truth as to
its contents not the configuration.
The framework boot image related checks are now performed in the
platform_bootclasspath module type.
Initially, this change included an extra check to make sure that
UpdatableBootJars comes from updatable APEXes but that broke because
framework-wifi and framework-tethering are not currently marked as
updatable in AOSP.
Bug: 177892522
Test: m nothing
Change-Id: I80fb600fa2c7cec4566b3461c6a33c4c6f0743f4
Previously, the method was run in repo manifests that did not include
the frameworks/base repository so it had to handle the file being
missing. However, now that this is being called from
platform_bootclasspath which is only defined in frameworks/base that
is no longer required.
Bug: 177892522
Test: m droid
Change-Id: I77fa5a204d1426a6be24a6f0b48e18f48f3dd908
This change allows an SdkMemberTypeDependencyTag to select the
SdkMemberType to use to add a dependency based on the module.
Bug: 177892522
Test: m nothing
Change-Id: I2d6e51b615636dc7cd41da65808ef851dd8ae6ac
Previously, both a bootclasspath_fragment and its contents had to be
explicitly added to the sdk. This change means that adding a
bootclasspath_fragment to and sdk will automatically add its contents
as if they were added using java_boot_libs.
Bug: 177892522
Test: m nothing
Change-Id: I8f7e70649f272c9a109d4606571a2d12c44b7904
Previously, the snapshot member list properties were simply copied from
the sdk variants. That worked because the snapshot member list
properties must include all exported (i.e. visible outside the sdk
snaphot) members and only members explicitly specified in the sdk
member list properties were exported. However, a preceding change
allowed members that were transitively added (and so not explicitly
specified on the sdk) to be exported.
This change ensures that those exported members are added to the
snapshot member properties which means that they will now work properly
with the sdk version mutators.
This does not add tests for this because no existing SdkMemberType
exports its transitive dependencies and there is currently no way to
register an SdkMemberType for testing only. A following change will
exercise this functionality.
Bug: 186290299
Test: m nothing
Change-Id: Iadbdd86f6dcdd183fa99f647222a43d412271501
Previously, every module added to an sdk directly through one of the
SdkMemberType specific properties, e.g. java_libs, was exported and
every module added automatically via a transitive dependencies was not
exported. This change allows that behavior to be customized per tag.
Bug: 186290299
Test: m art-module-sdk
- verify that this change does not affect its contents.
Change-Id: I563b5bcd823e61c23cdb706cfcbb13337963d550
Previously, the code was inlined in the addSnapshotModule() method
which made it difficult to follow, did not have clear separation
between the different pieces and duplicated functionality. This
change combines the dynamic and static properties together and then
separates the processing into collation, optimization and property
set updating methods.
Bug: 186290299
Test: m nothing
Change-Id: I311eebca2337cb67634e63d71da12305f4370c07
Previously, the code to add the compile_multilib property was
duplicated. This change moves the logic into the existing
addMemberPropertiesToPropertySet method, renames it to reflect new
behavior and renames and promotes the variantProperties struct from the
addSnapshotModule() method to the package level scope.
Bug: 186290299
Test: m nothing
Change-Id: I832a7fd89a3cf95467a1ff0807902c9be34c50b9
Previously the compile_multilib property was added after the member
list properties at the top level but before them in the target.os
level. This change makes it always be added before them.
Bug: 186290299
Test: m nothing
Change-Id: I01fe272933fd11f7f730cc379f60fb2ce70f2114
Renames some types and adds some documentation to try and clarify how
the sdk handles the members.
Bug: 186290299
Test: m nothing
Change-Id: I4038276f5f4c473a96fe06aedc43050c90416877
Previously, there were two types sdkMemberRef and sdkMember that seemed
as though the former was referring to the latter but that was not the
case. The former was actually information about the dependency the sdk
had on a specific member variant. The latter is all the information
about a specific member, including all its variants.
This change attempts to clarify that relationship, both through a
better type name and through some improved documentation.
Bug: 186290299
Test: m nothing
Change-Id: I1dcc0ddf3333da9e797bb23ae945d04729839014
This is needed to allow a prebuilt_bootclasspath_fragment to be used
interchangeably with a bootclasspath_fragment in the
platform_bootclasspath module.
The platform_bootclasspath module depends on APEX specific variants of
bootclasspath_fragment modules. That works because the
bootclasspath_fragment modules are part of an apex and so have an APEX
specific variant which the platform_bootclasspath can specify.
Using a prebuilt_bootclasspath_fragment in place of a
bootclasspath_fragment requires that the prebuilt also has an APEX
specific variant.
Specifying exported_bootclasspath_fragments on a prebuilt_apex/apex_set
will cause it to create an APEX variant for the named module whcih will
allow it to be selected by the platform_bootclasspath module.
Bug: 186034565
Bug: 177892522
Test: m nothing
Change-Id: I7ddacc6498ec3a4a9f26c5f78b7f9a033e494d78
These are needed at the moment to ensure the hidden API processing
generates the same set of flags whether it is being generated from
source or prebuilts. Soon these will be needed to ensure that the
hidden API flags generated for the individual modules are compatible
with previous releases.
Bug: 179354495
Test: m art-module-sdk and check snapshot zip contains the files
and the generated Android.bp references them.
Change-Id: I9a3334cc48faa381bbbcbbb59479db719042796a
Test: m platform-mainline-sdk
Check Android.bp in the generated platform-mainline-sdk-current.zip.
Bug: 156286550
Change-Id: Ifb99288f3b85c3b986270d48e2dc7d9e15fa7536
The hidden API processing needs access to dex jars for the API stubs in
order to determine which dex members are part of an API surface. The
dex stubs used for the monolithic file are provided by normal
java_library modules for legacy reasons. However, the APEXes that
contribute to the bootclasspath, and so need to perform hidden API
processing, typically provide stubs created by a java_sdk_library.
This change adds support to java_sdk_library/_import to make the dex
stub jars available when requested, that involves:
1. Adding compile_dex property to java_sdk_library_import and
propagating it down the the java_import modules for the stubs. That
is already handled for java_sdk_library.
2. Propagating the java_sdk_library compile_dex property to the
java_sdk_library_import in the generated snapshot.
3. Refactoring and wiring to make the dex stubs jar available to other
parts of Soong.
Bug: 179354495
Test: m nothing
Change-Id: I5895d4f2ba0b684870862b9429b2364865e4afc6
Replaces a single call to checkAndroidBpContents(...) with separate
calls to check the versioned and unversioned Android.bp files.
Test: m nothing
Bug: 179354495
Change-Id: I270bf73909958d97b2f298e8d7f6d10a1f75ae71
This is a cleanup CL to make the OsTypeList accessor consistent with
ArchTypeList by creating a function that creates a copy of the
underlying slice.
Test: TH
Change-Id: I346c5c3937bbdb8a373e4d7135b896a5274cc1f1
So far, when a library `libfoo` has `stubs.versions: ["10", "11"]`, then
`shared_libs: ["libfoo"]` is linked to the version 11 of the stub.
This requires the author of `libfoo` to manually update the property
whenever a new version is introduced. Otherwise, clients are not able
to use the newly added APIs because the latest stub is for an old
version.
This change eliminates the need for manual updating. "current" version
is always implicitly added to `stubs.versions`. It is added even when
nothing is set on the property, if `stubs.symbol_file` is set. i.e.
```
cc_library {
name: "libfoo",
stubs: {
symbol_file: "libfoo.map.txt",
// no versions: [...] needed
},
}
cc_library {
name: "a_client",
shared_libs: ["libfoo"],
apex_available: ["myapex"],
min_sdk_version: "29",
}
apex {
name: "myapex",
native_shared_libraries: ["a_client"],
min_sdk_version: "29",
}
```
`a_client` links to the "current" stub of `libfoo` that has all symbols
shown in the map file.
Note that, above doesn't mean that the client has unlimited access to
APIs that are introduced even after the min_sdk_version of the client
(29 in this example). The use of such APIs still has to be guarded with
`__builtin_available` check.
Bug: N/A
Test: m
Change-Id: I70bb1600c18e74d36c6b24c3569d2149f02aaf96
* changes:
Strengthen metalava sandbox support using sbox
Move metalava's output files into a subdirectory
Fix lint warnings in droidstubs.go
Split droidstubs out of droiddoc.go
Move all of the output files of the metalava rule into a single
subdirectory to make it compatible with sandboxing in sbox.
Test: TestDroidstubs
Change-Id: I66101c0c224dee702c8175e61c12cc9cd1aa8b93
Previously, unpacking a snapshot containing a
prebuilt_platform_compat_config into a source build would cause build
failure because of duplicate ids because the singleton would collate
ids from both prebuilts (versioned and unversioned) and source.
This change filters out versioned prebuilts and only uses prebuilts
that are preferred and source modules that have not been replaced by a
prebuilt.
Bug: 182402754
Test: m nothing
Change-Id: Idacbb34444e5156370df70bf88c6e8a7e2d67890
Test behavior was changed a while ago so that tests by default ignore
non-existent source paths (unless they explicitly check for/rely on
them). Prior to that CheckSnapshot() could detect when files were
missing from the snapshot but it no longer can.
This change disallows non-existent source files in all the sdk tests
which means that they are disallowed when processing the snapshots as
they use the same preparers as were used to process the sources.
This caused a test failure which has been temporarily ignored and has
a TODO and bug associated with it.
Bug: 183184375
Test: m nothing
Change-Id: I969d8515d20ef5ae515f2b5f93d8ed4e4f8ede75
The sdk produces snapshots that are expected to be unpacked in one of
the Android repos. Often that can lead to issues due to conflicts
between the source and prebuilts. This change attempts to avoid those
conflicts by testing the different ways that those files can be used.
With the existing test to cover adding the snapshot
This change will cause the sdk tests to check the following:
1) Snapshot on its own (already done).
2) Snapshot plus original source where the original source is
preferred.
3) Snapshot plus original source where the snapshot is preferred.
It also adds the ability for tests to provide their own custom checkers
to verify the result of each of the previous tests.
This change reveals a number of bugs already present. Rather than
attempt to fix them this change adds the ability to specify error
handlers for the two cases that mix source and snapshot to allow those
errors to be temporarily ignored while allowing the majority of the
tests to benefit from this improvement. Each of those failures has a
TODO and bug associated with it.
Bug: 183184375
Test: m nothing
Change-Id: I105233195074dbe7a6422b6dfc5486e74398ea15
This change needed to add some additional files to the registered
files for PrepareForTestWithJavaDefaultModules because otherwise they
would fail when "TestAllowNonExistentPaths = false". Those files were
being added by the TestJavaLintRequiresCustomLintFileToExist (albeit in
some cases in different locations to that required by the default
modules but as the files are needed by the modules defined in
PrepareForTestWithJavaDefaultModules they should be defined in it.
A couple of other places also provided some files so moving them into
PrepareForTestWithJavaDefaultModules caused some conflicts which needed
to be resolved.
Bug: 183184375
Test: m nothing
Change-Id: I76ce9f1673c1c1c4000635b76b8377d582224bf1
Added to reproduce the conditions that lead to the error reported in
the bug so they can be fixed. There were a number of issues that were
fixed in previous changes and this test verifies that they have been
fixed.
Bug: 182992071
Test: m nothing
Change-Id: I2197899b284a99973e698db314b15812f602b141
Extracts the setup for apex from prepareForSdkTest to allow it to be
reused without using all of it. That will allow tests to optimize their
test setup.
Bug: 182638834
Test: m nothing
Change-Id: I2056103b15c2737a616ee29ff890c6af0722e6d2
Using the preparer(s) that were used to run the test to verify the
integrity of the generated snapshot ensures that it will be verified in
the same environment as the snapshot was generated. This ensures that
as sdk tests are migrated to use fixtures that are optimized for each
test that they will benefit from those optimizations when checking the
snapshot.
Bug: 183184375
Test: m nothing
Change-Id: I62b383f9a1d9a77d1cabb101d9d1e4a976170fe3
These packages have already been migrated to use per test build
directory so have no need for a FixtureFactory.
Bug: 183235980
Test: m nothing
Change-Id: I667d1d992caaf0f615de91f89efdae11c44986c2
The ExcludeFromApexContentsTag marker interface was added to avoid
every implementation of DepIsInSameApex() from having to deal with the
special tags, like PrebuiltDepTag. Unfortunately, when adding that
not all calls to DepIsInSameApex() were protected which meant that the
BootImageModule, which panics if it doesn't recognize a tag, was
causing failures. This change documents the need and improves the
consistency.
A follow up change will add a test for this.
Bug: 182992071
Test: m nothing
Change-Id: If0bf9a7447ebf7a0bb0c88e91951a7220d4af45c
Adds the AlwaysRequireApexVariantTag interface to enable
ApexInfoMutator to differentiate between a tag that is excluded from
apex contents but still requires an apex variant and a tag that is
excluded from apex contents and does not require an apex variant.
That is needed to support the sdkMemberVersionedDepTag which excludes
the target from being added to the APEX but requires an APEX variant.
A more detailed explanation is in the comments.
The AlwaysRequireApexVariant() method follows the pattern used in
ReplaceSourceWithPrebuilt of having a method that returns a bool to
trigger the behavior and not say ExcludeFromApexContentsTag that simply
relies on the tag implementing an interface to trigger. That is because
the former is more flexible and allows a tag type to parameterize the
behavior if necessary.
The tags that this will exclude from creating an apex variant are:
* PrebuiltDepTag - by the time the apex variant has been created any
preferred prebuilts will have replaced the sources so there is no
need to create an APEX variant if the only dependency path from the
APEX to the prebuilt is via this tag.
* hiddenApiAnnotationsDependencyTag - the target of which is a purely
build time artifect and MUST NEVER end up in the APEX.
It will also stop calling DepIsInSameApex for any dependency created
by the sdkMemberVersionedDepTag. Which will fix the issue reported in
the bug.
Bug: 182992071
Test: m nothing
Change-Id: I9569e488d6446ca45d3ea8f32a9b74524eb865df
This change is in preparation for removing testing.T from TestResult.
Bug: 181070625
Test: m nothing
Change-Id: I67535aff0d894e6e3d8456b75540f340af853355
This will allow the testSdkResult to be replaced with the TestResult
when switching sdk package to use test fixtures.
Bug: 181070625
Test: m nothing
Change-Id: Ieca63f4c189f5e804102aeb4073289ea03143b6e
This change makes it easier to switch the sdk package over to using the
new fixture mechanism by removing inconsistencies between the
testSdkResult and TestResult structures.
Bug: 181070625
Test: m nothing
Change-Id: Ic4c06e08ea5060fd09123f2ca65580e18b4d2ef6
As part of the work on the new fixture mechanism some of the TestHelper
functionality was moved into the android/fixture.go package. This moves
the rest and removes the now duplicated TestHelper from the sdk
package.
Also removed some unnecessary & operators.
Bug: 181070625
Test: m nothing
Change-Id: Ia09a5d05e4fab3a4e28cf44b2d947a33541e3925
Changes this function so it only registers components from the cc
package by pushing the call to genrule.RegisterGenruleBuildComponents()
down into those packages whose tests need it.
This will make it easier to migrate cc package tests to test fixtures
as the RegisterRequiredBuildComponentsForTest() no longer overlaps with
preparers from the genrule packages.
Bug: 181070625
Test: m nothing
Change-Id: Ic00c7e480dc738d7a88d038aca6ab95a1502a24a
Previously, it was assumed that generated headers must be arch specific
and so prevented the fields referencing the paths to those headers from
being automatically optimized by the sdk generation code. That is not
always the case, e.g. with headers generated from protos so this change
allows those fields to be optimized.
Bug: 180427921
Test: m nothing
Change-Id: Id2af419d58ae3c30ea6d9e87f71e33a9ff6ba13b
Previously, the snapshot handling code did not preserve the directory
structure of generated include directories and instead just copied the
headers into the same module specific directory and added that single
directory to the export_include_dirs (or similar) property.
That had a couple of issues:
* The include directory was repeated in the ..._include_dirs property.
* It did not work when the include directories overlapped.
In the latter case it had a couple of issues:
* Code which compiled fine against the source would not compile against
the prebuilt.
* Header files were duplicated in the output.
e.g. assume the following generated header file structure:
foo/
foo.h
bar/
bar.h
baz/
baz.h
When the sdk snapshot was passed include directories of "foo", "bar" and
headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a
snapshot with the structure:
include_gen/
foo.h
bar.h
baz/
baz.h
And:
export_include_dirs: ["include_gen", "include_gen"]
However, when the include directories overlapped and include directories
of "foo", "bar" and "bar/baz" were passed in the directory structure
would be the same and the export_include_dirs would contain 3 usages of
"include_gen".
That meant that source code which used the following would build
against the source (because it would find "baz.h" in the "bar/baz"
include directory) but would fail when built against the prebuilts
because the "include_gen" directory did not contain "baz.h":
#include "baz.h"
This change preserves the input directory structure for generated files
in a similar way to how it does it for source files. So, the snapshot
structure looks something like this:
include_gen/
foo/
foo.h
bar/
bar.h
baz/
baz.h
And:
export_include_dirs: [
"include_gen/foo",
"include_gen/bar",
"include_gen/bar/baz",
],
Bug: 180427921
Test: m nothing
Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
A number of tests in cc_sdk_test.go use "include" for the input include
directory which results in the output containing "include/include"
(because the snapshot code uses "include" as the directory into which
native headers will be output). This change switches the inputs from
"include.." to "myinclude.." to differentiate between the two sources.
Bug: 180427921
Test: m nothing
Change-Id: Iba1e6d94647c74b31307b18254c03580e64c91cf
Uses new capability added in previous change to separate the testing of
the versioned and unversioned snapshots in sdk/cc_sdk_test.go. Any test
that generated an _snapshot module that simply listed the modules and
did not check a new type only tests the unversioned output to reduce
the duplication and cost of changing the tests.
Bug: 180479010
Test: m nothing
Change-Id: If11f82b3dd8ec79110b3a2f5adf193b6464000ab
Previously, the only way to test the Android.bp file generated by the
sdk module was to test both the unversioned and versioned parts
together. This change allows them to be tested separately.
Bug: 180479010
Test: m nothing
Change-Id: I3d695bcfbff030a6da393283ab30ec0979fb2826
Hiddenapi processing currently requires access to the class
implementation jars for libraries on the bootclasspath which means that
they need to be provided as part of the prebuilts. This change modifies
the java_boot_libs property on the sdk to make those files available.
Modularization of the hiddenapi processing will hopefully remove the
need for these to be exported so this should be temporary.
Bug: 178361284
Test: m art-module-sdk
check generated snapshot zip contains implementation jars
Change-Id: I9e94662dddb0ddb85a477ae6d27e533085147e88
Insulate tests that exercise code in the java package from having to
register the build components provided by the java package by providing
a single function that registers them all. This follows the pattern
currently used in the cc and rust packages.
This change is in preparation for switching the dex_bootjars singleton
from a singleton, which does not require a module definition in order
to be instantiated, to a singleton module which does. That will require
adding a module definition into java.GatherRequiredDepsForTest() and
this change ensures that the required components will have been
registered in every test.
Bug: 177892522
Test: m nothing
Change-Id: I6475db8240894947dd07c89a940a3e4f201aa598
The build has some implicit dependencies (via the boot jars
configuration) on a number of modules, e.g. core-oj, apache-xml, that
are part of the java boot class path and which are provided by mainline
modules (e.g. art, conscrypt, runtime-i18n) but which are not otherwise
used outside those mainline modules.
As they are not needed outside the mainline modules adding them to
the sdk/module-exports as either java_libs, or java_header_libs would
end up exporting more information than was strictly necessary. This
change adds the java_boot_libs property to allow those modules to be
exported as part of the sdk/module_exports without exposing any
unnecessary information.
Some points to note:
* The java_import has to have a valid file for the src property
otherwise it will be disabled.
* The src property is supposed to reference a jar file but the
java_boot_libs property will make it reference an empty file (not
an empty jar) so that any attempt to use that file as a jar, e.g.
compiling against it, will cause a build failure.
* The name of the file passed to the src property should make it
clear that the file is not intended to be used.
* The test makes sure that only the jar file is copied to the
snapshot.
Test: m nothing
Bug: 171061220
Change-Id: I175331e4c8e3874ab70a67cdc2f76ed1576e41eb
Setting this to true by default is dangerous as it can mask bugs. Create
a dedicated attribute for java_sdk_library to enable this behavior
instead. The default will be flipped in a future CL when all the current
offenders have been fixed.
Fix all the tests to have the right API files.
Bug: 176092454
Test: m nothing
Change-Id: Ieab94bcb74abf8d018365a56fb447fe3dbd46957
I added in case anyone needs to access AndroidMkEntries to generate
footer lines, but nobody uses it, and it only confuses people.
Test: m nothing, TreeHugger
Change-Id: Ic8a450e3c306d9228c1fdec212c7441bd6aaee03
