Make this consistent with how code names are used in the rest of Soong.
Bug: 204763318
Test: m nothing
Change-Id: I1f2f40310df9d619db6aaaad3ed7339bb5e79194
Marks the `scopeProperties.AnnotationsZip` property as only being
supported on T builds and above.
Bug: 204763318
Test: m nothing
Change-Id: Ie59396287c08da77a6a1f15d4be202429e011e17
Adds support for traversing into a field that is of type:
map[...]*struct{...}
This is needed to allow java_sdk_library to mark scope specific
properties, e.g. public.annotations as being target build release
specific.
It was necessary to change the Scope field from:
Scope map[*apiScope]scopeProperties
to:
Scope map[*apiScope]*scopeProperties
That is because there is no way in go to change the field of a struct
value of a map. i.e. you cannot do the following, not even using
reflection:
Scope[apiScopePublic].AnnotationsZip = nil
Bug: 204763318
Test: m nothing
Change-Id: Id103f70f55d4202971321ef4925cbec4b55f8136
Minor restructuring of the build_release pruning code to make it easier
to add logic for handling fields of maps of structs. That includes:
1. Moving some code that is specific to clearing a selected field
inside the associated if block.
2. Replacing an if with a switch.
3. Improving the error handling by separating the reporting of the
container that broke from information about which field could not be
set. That allows follow up code to provide information about the map
key instead.
The tests were restructed by:
1. Switching from using AssertDeepEquals to compare the structs to
comparing the output of marshalling the structs to JSON. That was
for a couple of reasons. Firstly, because JSON will marshal (and so
allow comparison of) the contents of pointers to structs whereas
AssertDeepEquals will just compare the pointers themselves.
Secondly, because JSON can pretty print the output and make it
easier to read.
2. Using a func to create a new instance of the input structure for
each test. That is to allow the test to modify the input structure,
e.g. by clearing a field in a struct that is pointed to by a map.
The test previously relied on the input structure being immutable
and passed by value but a follow up change will change that by
adding a map field that contains pointers to structs.
Bug: 204763318
Test: m nothing
Change-Id: I84dc99621497b7263e30466895b823eb02cb2b56
We will need the profile when we generate the primary boot image on
device.
Bug: 203492478
Test: Run `banchan com.android.art x86_64 && m` and see
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof`.
Test: Run `lunch aosp_cf_x86_64_phone-userdebug && m` and see both
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof` and
`$ANDROID_PRODUCT_OUT/system/etc/boot-image.prof`, in different
sizes.
Test: Start Cuttlefish with the built image and see both
`/apex/com.android.art/etc/boot-image.prof` and
`/system/etc/boot-image.prof` on device.
Change-Id: Id879dc49b234133dfbb9563814328661a1f4a6c0
Previous change that was reverted: https://r.android.com/1835222
An additional test was added that revealed a bug in the previous change
which has been fixed here.
Previously, the behavior of the stub_flags and all_flags properties
was different between S and T. In S they contained paths for the
complete set of stub flags and all the encoded flags. However, in T
they contained filtered sets of flags which if used in S would prevent
build checks from detecting possible inconsistencies. Also, a new
signature_patterns property was added in T that is not supported in S.
This change creates separate properties/files for T and reverts the
behavior of the properties/files that were added in S back to how they
behaved in S. The new properties are called filtered_stub_flags and
filtered_flags.
The S and T properties are tagged with the appropriate
supported_build_releases tag to ensure that they are only output when
specifically targeted.
Bug: 197842263
Test: m nothing
Change-Id: I1ce0a3d6623dabf73e32af1a7457b9b444fc3b7c
This was reverted unnecessarily along with the change that actually
broke the build.
Previously, the sdk snapshot was assumed to be generated for the
current build system. This change adds support for the
SOONG_SDK_SNAPSHOT_TARGET_BUILD_RELEASE environment variable which can
be used to select the target build release in which the generated
snapshot will be used.
At the moment this will only affect the properties that are output but
if/when it becomes necessary it can also be used to control more
aspects of the snapshots such as supported member types or even
members.
This change does not modify any properties that are build release
specific. That will come in following changes. However, it does add a
test that targets build release S which defines a baseline for
properties that will be affected in following changes. That baseline
makes it easier to see the effect of those follow up changes.
Bug: 197842263
Test: m nothing
Change-Id: If4b452237f105382550d2842c8010249afbc7432
Previously, the behavior of the stub_flags and all_flags properties
was different between S and T. In S they contained paths for the
complete set of stub flags and all the encoded flags. However, in T
they contained filtered sets of flags which if used in S would prevent
build checks from detecting possible inconsistencies. Also, a new
signature_patterns property was added in T that is not supported in S.
This change creates separate properties/files for T and reverts the
behavior of the properties/files that were added in S back to how they
behaved in S. The new properties are called filtered_stub_flags and
filtered_flags.
The S and T properties are tagged with the appropriate
supported_build_releases tag to ensure that they are only output when
specifically targeted.
Bug: 197842263
Test: m nothing
Change-Id: Iec8b9c539796c507245b69c0aed980fde6d8694f
Previously, the sdk snapshot was assumed to be generated for the
current build system. This change adds support for the
SOONG_SDK_SNAPSHOT_TARGET_BUILD_RELEASE environment variable which can
be used to select the target build release in which the generated
snapshot will be used.
At the moment this will only affect the properties that are output but
if/when it becomes necessary it can also be used to control more
aspects of the snapshots such as supported member types or even
members.
This change does not modify any properties that are build release
specific. That will come in following changes. However, it does add a
test that targets build release S which defines a baseline for
properties that will be affected in following changes. That baseline
makes it easier to see the effect of those follow up changes.
Bug: 197842263
Test: m nothing
Change-Id: I5cfde5e9e86af522b0d5030d301e116b0233fd62
Adds a general mechanism for pruning selected sdk member properties
(i.e. setting their fields to their zero value) and uses that to prune
any properties that do not support a specified target build release.
Follow up changes will use that to allow building an sdk snapshot that
is compatible with previous release S.
Bug: 197842263
Test: m nothing
Change-Id: Ib949a9cfe85fff30f86228eeb15d3a45c073b037
Adds the following:
1. A buildRelease type to represent a single build release.
2. A buildReleaseSet type to represent a set of build releases.
3. Methods to create parse and use the previous new types.
4. Tests for the above.
Bug: 197842263
Test: m nothing
Change-Id: Ib0dd4fc32851a4fffde3fa02ea22c8369f8c2995
Bug: 194150908
Test: m nothing
Test: manual - 1. Patch aosp/1835087.
2. m out/soong/.intermediates/art/build/sdk/art-module-sdk/common_os/snapshot/Android.bp
3. See prebuilt_systemserverclasspath_fragment modules and
systemserverclasspath_fragments in an sdk_snapshot module.
Change-Id: I7876b077b0b4ed190f01dbfa9533de04ea32d524
Similar to java_boot_libs, java_systemserver_libs only provide access
to their dex implementation jar for use by dexpreopting and do not
provide an actual implementation jar.
This is used in the subsequent CL.
Bug: 194150908
Test: m nothing
Change-Id: Ib2e7d5e6c002314a0231f46934a766f4a27e610a
Allows an sdk to require that a cc_library_headers module provides a
ramdisk image variant for the prebuilt.
Previously, "ramdisk_available: true" would be set in the generated
prebuilt snapshot for any sdk member that specified
"ramdisk_available: true" in the source module. This change will only
add that setting to the snapshot if the ramdisk image variant trait
was explicitly requested for a member.
Bug: 195754365
Test: m nothing
Change-Id: I21e0dd02d380beabf228a72c463fcc603c77d87f
Allows an sdk to require that a cc_library_headers module provides a
recovery image variant for the prebuilt.
Previously, "recovery_available: true" would be set in the generated
prebuilt snapshot for any sdk member that specified
"recovery_available: true" in the source module. This change will only
add that setting to the snapshot if the recovery image variant trait
was explicitly requested for a member.
Bug: 195754365
Test: m nothing
Change-Id: I7d79ccdec843127f7852d82b4b163021e30a79a7
Previously, the archTypeSpecificInfo included an array of
*linkTypeSpecificInfo. This change replaces that array with an array of
*imageVariantSpecificInfo which themselves contain an array of
*linkTypeSpecificInfo.
That allows the sdk snapshot to handle image variants correctly, i.e.
collate their properties, optimize their properties and then detect if
there are any image variant specific properties for any image variant
other than the CoreImageVariant ("") and report it as an error.
The latter case is treated as an error because while Soong needs to
handle image specific variants there is currently no requirement to
handle generating a prebuilt with image specific properties. A follow
up change will test the error handling.
Image specific variants are needed because the "jni_headers"
cc_library_headers module provides a number of image variants (e.g.
recovery) that are used outside the ART module. Therefore, the sdk
snapshot needs to do the same.
At the moment image variants like the recovery variant are supported by
copying the property that creates the variant (e.g. recovery_available)
through to the prebuilt but that is not safe for a couple of reasons:
1. It ignores any differences between the recovery variant and the
other variants which could cause compatibility issues in modules
that build against the prebuilts.
2. It marks modules in the snapshot with recovery_available even when
they do not need it.
This change will allow follow up changes to address both those issues.
Bug: 195754365
Test: m nothing
Change-Id: I1c187d814f44b2cb7607cd43a6b215134be0faad
* changes:
Consolidate the code to resolve a deapexer module dependency.
Propagate the dex jar path as an OptionalPath which is either valid or invalid with a message.
Historically, this file was used by the `--updatable-bcp-packages-file`
flag for dex2oat. The flag is no longer needed and is being deprecated.
Unfortunately, we cannot remove `permitted_packages` and all the code
related to it because we still need it for checking the module
compatibility with Q and R.
Bug: 200241946
Test: m nothing
Change-Id: Ie3be54fd47a847ba0caf627d12da76b415d99466
invalid with a message.
This will allow propagating any error from the deapexer module for
prebuilt APEXes to the location where the dex jars get used. It's only
at those points that we can raise errors about not being able to
extract files from the deapexer modules if they are invalid, and this
way we avoid encoding knowledge there about why they may be invalid.
To keep the refactoring limited it intentionally does not change any of
the existing logic for when dexJarFiles are set or not (non-nil vs nil
prior to this change), although there may be opportunity to use this
for more conditions when dex jars aren't available.
The refactoring is also not extended to
dexpreopt.ClassLoaderContextMap.
Test: m nothing
Bug: 192006406
Change-Id: I68986dccd9a9b3fee4d24caa1947ea17a36caedc
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
