aboutsummaryrefslogtreecommitdiff
path: root/java/platform_bootclasspath.go
Commit message (Collapse)AuthorAgeFilesLines
* Remove updatable-bcp-packages.txt.Jiakai Zhang2021-09-241-8/+0
| | | | | | | | | | | | | 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
* Separate creation of signature patterns from overlap checkingPaul Duffin2021-08-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rename UpdatableBootJars to ApexBootJars.satayev2021-07-221-32/+33
| | | | | | | | | | | 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
* Avoid permitted_packages related build failures in unbundled buildsPaul Duffin2021-07-161-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | Unbundled builds cause AlwaysUsePrebuiltSdks() to return true which causes java_sdk_library_import modules to be preferred instead of their corresponding java_sdk_library module. That causes the platform-bootclasspath module to depend on prebuilt versions of modules like framework-statsd which currently do not specify permitted_packages and so cause a failure. This is a temporary hack to prevent an unbundled build from checking for permitted_packages. It can be removed once the prebuilts have been updated to include the permitted_packages. Bug: 193095050 Bug: 193889859 Test: m TARGET_BUILD_APPS=Calendar apps_only - before the change it failed in Soong. - after the change it started failing, later in Make, so the Soong problem has been worked around. - I reverted all the recent changes to permitted_packages and ran this and it still failed so that failure is unrelated to these changes. Change-Id: I213d35437d76d61cf616d1f16dae213b311c6c8e
* Generate boot images for host from prebuiltsPaul Duffin2021-07-061-3/+8
| | | | | | | | | | | | | | | | | | | Previously, when building from prebuilts boot no rules were created to produce the boot image files for the host, i.e. the OS on which the build was running. That caused problems with checkbuilds. No rules were produced as there was no host variant of a prebuilt apex to provide them. This change restructures the code to allow the prebuilt bootclasspath fragment to build the host variants of the files from the dex files provided by the prebuilt APEX. The generated files will not be the same as they would be if built from source as there is no boot image profile to use but it should be sufficient to satisfy the checkbuild target and allow for host side testing. Bug: 192575099 Test: m SOONG_CONFIG_art_module_source_build=false droid dist checkbuild Change-Id: I6af00f19bb71aa18dd462f5eac6aa38e3e721023
* Generate boot zip file from prebuilt_bootclasspath_fragmentPaul Duffin2021-07-011-1/+4
| | | | | | | | | | | | | | | | | | | | Previously, the boot zip file, containing all the boot image files for all the supported architectures, was only created from source. It was not created when building from a prebuilt_bootclasspath_fragment. That lead to build failures when building from ART prebuilts. This change pulls the boot zip file creation out so that it can be done for both source and prebuilt bootclasspath_fragment modules as well as for the platform_bootclasspath module. Bug: 192575099 Test: m out/target/product/generic_arm64/boot.zip m SOONG_CONFIG_art_module_source_build=false out/target/product/generic_arm64/boot.zip - Compare the output of the first command from before the change with the output from them both after and confirm that when the ART prebuilts are up to date with the source that there are no differences. Change-Id: Ie7dd5e2ca4a865d06fd9ebf87320cf68c4d05bc3
* Verify the modular stub flags are subsets of the monolithic stub flagsPaul Duffin2021-06-251-1/+1
| | | | | | | | | | Bug: 179354495 Test: m out/soong/hiddenapi/hiddenapi-stub-flags.txt - check that an error is reported if a modular stub-flags.csv file, i.e. one created by a fragment is not a subset of the monolithic file, e.g. because a signature in the modular file has different flags than it does in the monolithic or is not present there. Change-Id: I46ebb495cb093a5e3abe7571c49933c845318549
* Make ruleToGenerateHiddenAPIStubFlagsFile build rulePaul Duffin2021-06-251-3/+2
| | | | | | | | | | | | Previously, the func created a rule and returned it for the caller to create with the appropriate name and description. This change passes the name and description into the func and causes it to create the rule itself. The func is also renamed to make it more consistent with the other similar rules. Bug: 179354495 Test: m nothing Change-Id: I2a4455daa8a6090ed5568994b255848d063e1ab2
* Add HiddenAPIScope to replace use of SdkKindPaul Duffin2021-06-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Previously, the hidden API processing used SdkKind to identify the API scopes, e.g. public, system, etc. that are of interest for hidden API processing. Unfortunately, there is a mismatch between the SdkKind and what hidden API processing needs. e.g. SdkKind includes values that are not used by hidden API processing and hidden API processing needs additional API scope specific information not provided by SdkKind. The apiScope struct used in sdk_library.go is also not a suitable representation for similar reasons. This change adds the HiddenAPIScope (following a similar approach as apiScope) that rectifies that and uses it as a replacement for SdkKind in most parts of the hidden API processing. The SdkKind is still used for retrieving information from java_sdk_library[_import] modules. Follow up changes will extend the HiddenAPIScope with more information. Bug: 179354495 Test: m out/soong/hiddenapi/hiddenapi-flags.csv - make sure that this change has no effect on the generated flags. Change-Id: I97968f58535121652852b8d25217aa288afd2bfd
* Merge "Append platform classpath proto configs with missing apex jars."satayev2021-06-231-3/+19
|\
| * Append platform classpath proto configs with missing apex jars.satayev2021-06-221-3/+19
| | | | | | | | | | | | | | | | | | | | Any apex classpath fragment that doesn't generate its own classpaths proto, must still propagate it's boot jars for the platform classpath fragment to include for complete CLASSPATH variables on device. Bug: 191127295 Test: atest CtsClasspathsTestCases derive_classpath_test Change-Id: I93687f69006741fcd66eb6e04891a4b4bbcc3b47
* | Merge "Fix monolithic hidden API processing with prebuilts"Paul Duffin2021-06-221-16/+36
|\ \ | |/ |/|
| * Fix monolithic hidden API processing with prebuiltsPaul Duffin2021-06-201-16/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Fix bootDexJarByModule with UNSAFE_DISABLE_HIDDENAPI_FLAGS"Paul Duffin2021-06-221-2/+3
|\ \ | |/ |/|
| * Fix bootDexJarByModule with UNSAFE_DISABLE_HIDDENAPI_FLAGSAdrian Roos2021-06-211-2/+3
| | | | | | | | | | | | Fixes: 191652687 Test: UNSAFE_DISABLE_HIDDENAPI_FLAGS=true m Change-Id: I7d85340681e54fbd0da69596b6846eb446c6ec6d
* | Use classpath elements in platform_bootclasspathPaul Duffin2021-06-201-10/+11
|/ | | | | | | | | | | | Use classpath elements in newMonolithicHiddenAPIInfo. That means the method can collate information from both fragments and libraries rather than just fragments. So, this change moves the collation of the classesJars into the method. Bug: 177892522 Test: m out/soong/hiddenapi/hiddenapi-flags.csv out/soong/hiddenapi/hiddenapi-index.csv - make sure that this change does not affect the contents. Change-Id: I7c2a229fab60d02bd211438735a8d7303ed83386
* Merge "Move boot jars package check into platform_bootclasspath"Paul Duffin2021-06-171-3/+6
|\
| * Move boot jars package check into platform_bootclasspathPaul Duffin2021-06-171-3/+6
| | | | | | | | | | | | | | | | | | | | 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
* | Merge "Combine hidden API encoding with flag generation"Paul Duffin2021-06-171-2/+2
|\|
| * Combine hidden API encoding with flag generationPaul Duffin2021-06-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the rules to perform hidden API encoding were generated separately to the rules to perform hidden API flag generation. This change combines them within the (renamed) produceHiddenAPIOutput() method and makes the paths to the encoded dex files an output of the generateHiddenAPIBuildActions method alongside the paths to the generated flag files. As encoded dex jars are now an output of the produceHiddenAPIOutput() method which is implemented for both prebuilts and source bootclasspath_fragment modules that necessitated the prebuilt also providing paths to encoded dex files. That in turn required updates to some of the tests to provide dex files from prebuilt_apex modules. Similarly, as the produceHiddenAPIOutput() method may not be called for some bootclasspath_fragment modules as they do not yet provide all the information needed to perform hidden API encoding then it is necessary to extract the encoded dex files produced by the modules themselves. That also required a few changes to tests that did not previously provide dex files. Bug: 177892522 Test: m com.android.art - check that this change does not change the contents of the apex file, i.e. is byte-for-byte identical. Change-Id: I60996a34d06ed1c87ed244ab3509621999ad86ec
* | Rename ClasspathFragmentToConfiguredJarList methods to configuredJars.satayev2021-06-161-2/+2
|/ | | | | | | | They are internal implementation details of individual fragments. Bug: 191127295 Test: m Change-Id: Ib350135f5f6720741492f362f7b3203e5107772e
* Avoid passing around []hiddenAPIModulePaul Duffin2021-06-141-4/+2
| | | | | | | | | | | | | | | | Previously, an []android.Module was converted to an []hiddenAPIModule that was then used to retrieve boot dex jars. That was ok when obtaining the dex jar files from source modules for bootclasspath_fragment but does not work well for other use cases as it would require doing that conversion in multiple places. This change pushes the use of hiddenAPIModule down to the methods that retrieve information from it which makes the methods more flexible and easier to reuse. Bug: 177892522 Test: m nothing Change-Id: Ib84aaf03d8f5a63b48232036fe4589646fc23352
* Make copyBootJarsToPredefinedLocations simpler and less fragilePaul Duffin2021-06-101-2/+4
| | | | | | | | | | | | | | | | | | Previously, copyBootJarsToPredefinedLocations relied on all its parameters having the same length and the same order. That made it quite fragile as changes to one of the parameters without corresponding changes to the other would cause failures. It also combined the retrieval of the boot dex jars from the modules, handling of missing boot dex jar files and the generation of the rules to copy the files. This change separates the retrieval of boot dex jars and handling of missing files from the copying of those files while at the same time making the function less fragile by replacing the three ordered parameters with two maps that shared common keys. Bug: 179354495 Test: m nothing Change-Id: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
* Export hidden api related types and fieldsPaul Duffin2021-06-101-2/+1
| | | | | | | | | | | This will export some hidden api related types and fields so they can be used from outside the java package. This is needed to allow a follow up change to move the TestPlatformBootclasspath_Fragments from the java to the apex package. Bug: 179354495 Test: m nothing Change-Id: Ib69eea9d79cc83b8e3fc29919a29f071e1ec17b5
* Support removed API members in modular hidden API processingPaul Duffin2021-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the hidden API flags generated for a bootclasspath_fragment did not include removed API members. That was because it did not supply a file containing the dex signatures of the removed API members. The monolithic hidden API processing uses combined-removed-dex which is the output of a genrule that takes as input the *removed.txt files from all the APIs and uses metalava to construct the dex signatures file. This change does the equivalent for the *removed.txt files for the APIs provided by a bootclasspath_fragment and then passes them to the rule that generates the final all-flags.csv. Bug: 179354495 Test: - Update packages/modules/RuntimeI18N to enable hidden API processing. m out/soong/hiddenapi/hiddenapi-flags.csv - Before this change that fails as the flags generated for the i18n-bootclasspath-fragment differ from the monolithic flags. After this change that passes. - Verify that this change does not change any of the monolithic hidden API files. m com.android.i18n - Verify that the apex file before and after this change are byte for byte identical. Change-Id: I6a21edb8a5231666e3f35b2c99a8687f36dd98fd
* Separate input to flag generation from hiddenAPIFlagFileInfoPaul Duffin2021-05-241-4/+20
| | | | | | | | | | | | Encapsulating the information needed by hidden API processing in a struct makes it easy to add additional information in future and allows the code to populate that struct from various different sources to be grouped together. Bug: 179354495 Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt - verify that this does not change the contents of the apex files Change-Id: I53805737dff36a3ae87aca5aad51cf46ae1361fe
* Separate monolithic hidden API processing from hiddenAPIFlagFileInfoPaul Duffin2021-05-241-12/+14
| | | | | | | | | | | | | | | | The hiddenAPIFlagFileInfo was being used for both the input and output of bootclasspath_fragment and platform_bootclasspath and also to pass information around to various hidden API rule methods. Supporting multiple different uses in this way made it hard to reason about. This change creates a separate structure for use by the platform_bootclasspath. Follow up changes will split out other functionality into separate types. Bug: 179354495 Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt - verify that this does not change the contents of the apex files Change-Id: Ia5c5f65ae5645486c42819c669a8601588217f88
* Populate individual classpath_fragments' classpaths.proto configs.satayev2021-05-201-8/+1
| | | | | | | | | | | | To avoid duplicates on *CLASSPATH environ variables at runtime, remove split entries from platform-*classpath, i.e. all updatable jars that have their own classpath fragments should not appear in the platform-*classpath's classpaths.proto config. Bug: 180105615 Test: m && launch_cvd; atest CtsClasspathsTestCases Change-Id: Id2759ab8e106cc183e695bf3509a6ab60ab0ef2a Merged-In: Id2759ab8e106cc183e695bf3509a6ab60ab0ef2a
* Merge changes I4e7a7ac5,I0c73361bJiyong Park2021-05-201-1/+1
|\ | | | | | | | | | | * changes: Record the actual APEXes that a module is part of. Rename InApexes -> InApexVariants
| * Rename InApexes -> InApexVariantsJiyong Park2021-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .. in preparation for the upcoming change. This change doesn't alter any behavior. InApexes is a misleading name. People expects that it has the list of soong module names of the APEXes that a module is part of. So, for example, `core-oj` is a part of both `com.android.art` and `com.google.android.art`. However, in reality, that's not true. The field has `com.android.art` only. This is because the two APEXes (android and Google) have the same apex name which is `com.android.art`. That apex name is used in various places like the `apex_available` and allows us to keep using the same name regardless of whether the APEX is overridden or not. However, this is causing problems in some cases where the exact list of soong module names is required. The upcoming change will add a new field to handle the case and the new field actually will get the name 'InApexes'. So, the existing field is renamed to a less misleading name `InApexVariants`. Bug: 180325915 Test: m nothing Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
* | Workaround to make AlwaysUsePrebuiltSdks() work with platform_bootclasspathPaul Duffin2021-05-191-2/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The AlwaysUsePrebuiltSdks() causes all java_sdk_library_import modules to be preferred over the source, i.e. as if they had prefer: true set. That interacts badly with the work that is being done to integrate the bootclasspath_fragment/platform_bootclasspath modules into the build. It would work fine once that integration has been completed but in the interim it causes problems. e.g. it does not cause a problem in AOSP because those java_sdk_library_import modules that are affected have already been integrated into the build properly. Unfortunately, internally that is not the case because there are java_sdk_library/java_sdk_library_import modules that still need to be updated. Before the java_sdk_library_import can be safely preferred each java_sdk_library/java_sdk_library_import module that contributes to the bootclasspath must: * Be in the contents of matching bootclasspath_fragment and prebuilt_bootclasspath_fragment modules. * Have an apex and one of a prebuilt_apex/apex_set that contains the dex implementation jar and lists the prebuilt_bootclasspath_fragment name in its exported_bootclasspath_fragments property. Safely preferred in this context means that the whole build will continue to work rather than the current situation which is that only some of the build will work and some will fail if an attempt is actually made to build it. Unfortunately, many java_sdk_library_import modules are missing: * The prebuilt_bootclasspath_fragment. * The exported_bootclasspath_fragments property on the prebuilt_apex/apex_set that contains them. Together these cause the following symptoms: 1. The java_sdk_library_import does not have a dex implementation jar. 2. The java_sdk_library_import does not have a myapex variant. These workarounds will avoid Soong reporting build failures. However, the build will still fail if an attempt is made to build anything produced by the platform-bootclasspath, e.g. hidden API processing or a system image. Bug: 188505921 Bug: 179354495 Test: m TARGET_BUILD_APPS=Calendar Change-Id: I3226e21cd6a7f9e4d6bbe94e54129ac5e1d4c679 Merged-In: I3226e21cd6a7f9e4d6bbe94e54129ac5e1d4c679
* Generate monolithic hidden API files direct from class jarsPaul Duffin2021-05-141-112/+32
| | | | | | | | | | | | | | | | | | | | | Previously, the monolithic hidden API files, e.g. hiddenapi-index.csv file, were generated in two steps. First, each module created its own files using the information in its class jars. Then, the monolithic files were created by merging those module specific files into a larger file. This change switches to generating the monolithic files directly from the class jar files and bypassing the intermediate files. In order to ensure that this change did not change the monolithic files it is necessary for the hiddenapi-metadata.csv to go through a reformatting step. Hopefully, this will be able to be removed in a follow up change. Bug: 179354495 Test: verified that the monolithic out/soong/hiddenapi/... files are unchanged by this change Change-Id: I5a78e747516014b7c0f402a4b4431b14be6a84b2
* Use java_sdk_library in bootclasspath_fragment contents as stubsPaul Duffin2021-05-141-1/+1
| | | | | | | | | | | A java_sdk_library specified in the bootclasspath_fragment contents must be providing APIs for the bootclasspath_fragment and so must be treated as if they were specified in the stub_libs. This avoids having to specify them in both contents and stub_libs. Bug: 179354495 Test: m nothing Change-Id: I535065ee1a79b439e2676f35e06a75d4626adcaf
* Generate hidden API flags for a bootclasspath_fragmentPaul Duffin2021-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Build boot images in bootclasspath_fragment/platform_bootclasspathPaul Duffin2021-05-121-0/+4
| | | | | | | | | | | | | | | | | | Moves the building of boot images from the dexpreopt_bootjars singleton to the bootclasspath_fragment and platform_bootclasspath. The art boot image is generated by the art-bootclasspath-fragment module and the framework boot image by the platform-bootclasspath module. This does temporarly duplicate the generation of an identical boot profile for each image. As part of the work to modularize the boot image profile each image will have its own custom default boot profile. Bug: 177892522 Bug: 186455808 Test: m droid and TreeHugger Change-Id: I23cf05ec7648749b21c7cf6fcba282b46649a981
* Move copying of dex files from dexpreopt_bootjars singletonPaul Duffin2021-05-121-2/+9
| | | | | | | | | | The art dex files are copied in the bootclasspath_fragment and the non-updatable and updatable dex files are copied in the platform_bootclasspath. Bug: 177892522 Test: m nothing Change-Id: I5d3d533d1a7a9f8e7ae20c12eb33029a898a2cd6
* Generate empty classpaths.proto for bootclasspath_fragment.go.satayev2021-05-111-0/+1
| | | | | | | | | | | | | - Adds all required details for bootclasspath_fragment to implement classpath_fragment. - Keeps the actual boot jars in platform-bootclasspath to begin with. - Makes sure to put the file in apex/etc/classpath on device. Note that for platform versions of classpath fragment AndroidMkEntries perform the installation, while for APEXes it must be plumbed via apex.go. Bug: 180105615 Test: m && launch_cvd; atest CtsClasspathsTestCases Change-Id: I6101ebdf5b8bcbe95c0b7ce21f3f67a2685aef50
* Declare ConfiguredJarList in specific fragment implementations.satayev2021-05-071-2/+19
| | | | | | | | | | | | | Each specific classpath_fragment module knows what jars must be part of the corresponding classpaths.proto config. Note that bootclasspath_fragment does not implement classpath_fragment yet, thus all boot jars and all system server jars go into corresponding platform classpaths. Bug: 180105615 Test: m && launch_cvd; atest CtsClasspathsTestCases Change-Id: I6a8c7b0a5d17d62e790a441b8e2c5c1a816e7f30
* Split SYSTEMSERVERCLASSPATH entries from platform_bootclasspath.satayev2021-05-071-2/+2
| | | | | | | | | | | Boot jars are different to system server jars at build level, due to added complexity of dexpreopt. As a logical separation add a new classpath fragment type and split existing classpaths.proto generation into relevant pieces. Bug: 180105615 Test: m && launch_cvd; atest CtsClasspathsTestCases Change-Id: I88bec09fc920166ffd0092faef980754ddeb6593
* Rename classpath_fragment.go methods for better readability.satayev2021-05-061-2/+2
| | | | | | Bug: 180105615 Test: m nothing Change-Id: Ic663c22e5b7cbab487dc1fe99805e08843c3213d
* Support dex_import on platform_bootclasspathPaul Duffin2021-05-041-0/+2
| | | | | | | | | Maintain compatibility with previous behavior by ignoring dex_import during hidden API processing. Bug: 179354495 Test: m nothing Change-Id: I976b02129bf981b7b61dce233567d6f89e04f92d
* Merge "Fix build failure when building unbundled apps (second try)"Paul Duffin2021-04-301-17/+56
|\
| * Fix build failure when building unbundled apps (second try)Paul Duffin2021-04-301-17/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous attempt, which simply skipped the hidden API processing altogether when unbundled builds were enabled failed when attempting to build module snapshots as while they enabled an unbundled build they actually need the hidden API processing to be performed. This change just checks whether missing dependencies are allowed and if so it fakes up any missing files so that the build will only fail if they are not present AND they are used. Bug: 186695448 Bug: 185828824 Test: tapas Calendar m -j60 Change-Id: Ie13fed05af0aba51f45f6791fce944d0e4285037
* | Move configuration checks from getBootImageJarPaul Duffin2021-04-301-0/+41
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Revert "Fix build failure when building unbundled apps""Treehugger Robot2021-04-301-11/+1
|\
| * Revert "Fix build failure when building unbundled apps"Vishnu Nair2021-04-301-11/+1
| | | | | | | | | | | | | | | | | | This reverts commit c027119e73e9a211b7d2c1cafc978a750f11e920. Reason for revert: b/186797512 Test: vendor/google/build/build_mainline_modules.sh -j80 Change-Id: I2bb062cce09ac6717702c4f6b110acbb2887adec
* | Merge "Fix build failure when building unbundled apps"Paul Duffin2021-04-291-1/+11
|\|
| * Fix build failure when building unbundled appsPaul Duffin2021-04-291-1/+11
| | | | | | | | | | | | | | | | Bug: 186695448 Bug: 185828824 Test: tapas Calendar m -j60 Change-Id: I1c5365f6d2afb2f2d159e6f6ed004647ec6d2427
* | Move generation of hidden API make vars to platform_bootclasspathPaul Duffin2021-04-291-1/+11
|/ | | | | | | | | Bug: 179354495 Test: rm out/soong/make_vars* m nothing grep INTERNAL_PLATFORM_HIDDENAPI_FLAGS out/soong/make_vars* - make sure it is still out/soong/hiddenapi/hiddenapi-flags.csv Change-Id: I86e56512a9a2091f446bad25294d41ea1f4341ee
* Make platform_bootclasspath a singleton modulePaul Duffin2021-04-291-3/+15
| | | | | | | | | | | This is needed in order to allow it to implement MakeVars so it can create make variables just like the dexpreopt_bootjars and hiddenapi singletons currently do. Bug: 177892522 Bug: 179354495 Test: m nothing Change-Id: Ida5bf8abeecde531e1f6430151650065445804ac
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-23 17:44:58 +0000