aboutsummaryrefslogtreecommitdiff
path: root/java/platform_bootclasspath.go
Commit message (Collapse)AuthorAgeFilesLines
* Use the correct bootjars for hiddneapi when multiple prebuilts existSpandan Das2024-01-021-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hiddenapi processing require boot jars from apexes to determine the full set of methods available at runtime. When building with prebuilts, this comes via java_import/java_sdk_library_import, which acts as a hook for prebuilt_apex/apex_set. If we have multiple apexes in the tree, this hook becomes 1:many. This CL prepares platform_bootclasspath to select the right deapexerd .jar files when mutliple prebuilts exist. Implementation details - Create a dependency edge from platform_bootclasspath to all_apex_contributions (DepsMutator) - For every boot jar, query all_apex_contributions to get the path to dexjar file (GenerateAndroidBuildActions) Some other important details - This CL does not drop the old mechanism to get the dex file (i.e. by creating a dep on java_library). Once all mainline modules have been flagged using apex_contributions, the old mechanism will be dropped - This CL has a functional change when building with source apexes. At ToT, the unecoded hiddenapi dex jar is used for package check and generating the monolithic stub file. After this change, the hiddenapi encoded file will be used for these operations. This should be fine since the package and dex signature do not change across the encoded and unencoded dex file. In fact, we already have a split today. When building with prebuilts, we use the encoded dex file. When building with source, we use the unecoded dex file. Test: Added a unit test Test: Manual testing in internal described below - lunch cf_x86_64_phone-next-userdebug - flagged com.google.android.adservices using apex_contributions - aninja -t commands out/soong/hiddenapi/hiddenapi-stubs-flags.txt # no diff before and after Bug: 308790777 Change-Id: I72c70f0ae1b587679203ea254c9c12a48e7aa782
* Convert OtherModuleProvider to generic providers APIColin Cross2023-12-141-4/+4
| | | | | | | | | Convert all of the callers of OtherModuleProvider/OtherModuleHasProvider to use the type-safe android.OtherModuleProvider API. Bug: 316410648 Test: builds Change-Id: Id77f514d68761a262d9ea830a601dbed804bbbe5
* Convert SetProvider to generic providers APIColin Cross2023-12-141-1/+1
| | | | | | | | | Convert all of the callers of SetProvider to use the type-safe android.SetProvider API. Bug: 316410648 Test: builds Change-Id: If58f4b5355264ddab2045bc3591a4eac19cd58fc
* Use the correct mainline BCP jars for app dexpreopt.Jiakai Zhang2023-11-061-9/+0
| | | | | | | | | | | | | | | Before this change, the build system had special logic to find mainline BCP jars and copy them to a special location for app dexpreopt. This logic doesn't work on `next`. In fact, we don't need this logic anymore. Since we are now generating the mainline boot image extension, we can reference the inputs of the mainline boot image extension, which are exactly the mainline BCP jars needed for app dexpreopt. Bug: 309302263 Test: atest art_standalone_dexpreopt_tests (on next) Test: m --no-skip-soong-tests nothing Change-Id: I055018ffbc5d7e5678f305e65a7f1c7e73bf3b99
* Make the srcjar for bcp available in OutputFilesAnton Hansson2023-09-281-2/+7
| | | | | | | | This makes it possible for Android.bp files to depends on the srcjar. Bug: 151360309 Test: m platform-bootclasspath.srcjar Change-Id: Id42cc3cff89c084b55c7fb0726ad84ecd4f50f58
* Add srcjar output for platform_bootclasspathAnton Hansson2023-09-281-0/+12
| | | | | | | | | | | | This output contains all the transitive sources that are contained in the bootclasspath. It's currently limited to source-built bootclasspath components. Future work will make this deal with sdk_library prebuilts. Bug: 151360309 Test: unit test, as well as manual inspection of platform-bootclasspath Change-Id: Ie05d8125e19736d8b4b9ebafb70b88a0a40069d5
* Disable Hidden API Checks for ENG BuildsPratyush2023-07-301-3/+3
| | | | | | | | | For more discussions/details, please check internal CL ag/24145146 Bug: 289409213 BUg: 285976182 Test: Look for hiddenapi calls in build trace Change-Id: Ia2780ee419b8da1418ba1c7a7d732712b7c2a322
* Refactor dexpreopt for boot jars to make it flexible to config changes.Jiakai Zhang2023-07-141-77/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the past, dexpreopt for boot jars was very inflexible, and it was incredibly hard to make a change that is as simple as adding a jar to a boot image. Boot image generation was handled by "platform_bootclasspath" and "bootclasspath_fragment" separately. This caused not only code duplication but also the inflexiblity as such a design did not fit today's use cases, where a boot image may take jars from multiple mainline modules and the platform, and a mainline module can contribute to multiple boot images. The design casued a huge maintenance burden as any change to the boot image cost multi-week efforts. In recent years, efforts have been made to improve this a bit by a bit. This change is another step towards making dexpreopt reasonable. After this change, all boot images are generated by "dex_bootjars", which is in build/soong and is therefore available on both the full source tree and the thin manifest (master-art). The change decouples profile generation/extraction from boot image generation. Profiles for mainline modules are still handled by "bootclasspath_fragment" because they need to be packed into APEXes when building mainline modules and extracted from APEXes whem building the system image from prebuilt modules. Boot images are not handled by "bootclasspath_fragment" anymore. Bug: 290583827 Test: m (all existing tests are still passing) Test: Manually checked that the boot images are exactly the same as before. Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
* Parallelize singleton executionLaMont Jones2023-05-191-1/+1
| | | | | | Bug: 281536768 Test: manual, presubmits Change-Id: I57fdc76ba6b277e88e196b506af87127a530fd37
* Dexpreopt ART jars and framework jars together.Jiakai Zhang2023-05-111-10/+38
| | | | | | | | | | | | | | | | | | Bug: 280776428 Test: atest art_standalone_dexpreopt_tests Test: - 1. m 2. Check .invocation file (http://gpaste/6498044089466880) 3. Check files in $ANDROID_PRODUCT_OUT/system/framework/x86_64 Test: - 1. m dist 2. Check files in out/dist/boot.zip Test: - 1. art/tools/buildbot-build.sh --host 2. m test-art-host-gtest 3. art/test/testrunner/testrunner.py --host Test: m build-art-target-golem Change-Id: I89490252e56a05edab03fdddc6539fa4d7f79756
* Revert^2 "Generate boot image profiles even if dexpreopt is disabled."Jiakai Zhang2023-05-081-6/+7
| | | | | | | | | | | | | Revert submission 2580631-revert-2574032-XXTWCJDTDQ Reason for revert: Fixed build breakages Reverted changes: /q/submissionid:2580631-revert-2574032-XXTWCJDTDQ Bug: 280440941 Test: lunch aosp_cf_riscv64_minidroid-userdebug && m UNSAFE_DISABLE_HIDDENAPI_FLAGS=true dist Test: Disable dex2oat on host (to simulate macOS) and build Change-Id: I5f7f746ca1d4da660fe0c40115e6c71750dfdccc
* Revert "Generate boot image profiles even if dexpreopt is disabled."Qiao Yang2023-05-051-6/+9
| | | | | | | | | | | Revert submission 2574032 Reason for revert: DroidMonitor-triggered revert due to breakage <https://android-build.googleplex.com/builds/quarterdeck?branch=aosp-master&target=aosp_cf_riscv64_minidroid-userdebug&lkgb=10069333&lkbb=10075041&fkbb=10071083>, bug <b/280902279> Reverted changes: /q/submissionid:2574032 Change-Id: I8e99f8231639198b149ea8d822ee7f9a5b391a89 BUG: <280902279>
* Generate boot image profiles even if dexpreopt is disabled.Jiakai Zhang2023-05-031-9/+6
| | | | | | | | Bug: 280440941 Test: - 1. Patch ag/22302622 to disable dexpreopt. 2. See boot image profiles still generated. Change-Id: I1bf05ade53fa83f3dba46f28a8f9246ba1fdf664
* Revert^2 "Generate a boot image extension for mainline BCP...Jiakai Zhang2023-03-161-0/+1
| | | | | | | | | | Revert submission 2465993-boot-image-mainline-revert Reason for revert: Relanding the changes Reverted changes: /q/submissionid:2465993-boot-image-mainline-revert Change-Id: Ie611cf3a1ff4be7a7beab164f69b4186c474be5c
* Revert "Generate a boot image extension for mainline BCP jars."Jiakai Zhang2023-03-021-1/+0
| | | | | | | | | This reverts commit 3830308fb8be13df66437b9798122789c85c7e37. Reason for revert: Caused various SH regressions. Bug: 271036161 Change-Id: Ia785324f83006a095e262c251b24d49fd778427e
* Generate a boot image extension for mainline BCP jars.Jiakai Zhang2023-02-241-0/+1
| | | | | | | Bug: 269230245 Test: m Test: atest art_standalone_dexpreopt_tests Change-Id: I253c30d938eee2cf2549ec2338425d53956e7cbb
* Refactor platform_bootclasspath to support multiple boot images.Jiakai Zhang2023-02-241-21/+19
| | | | | | Bug: 269230245 Test: m Change-Id: I223756d5481607a82732f70c51057609ec4ee43f
* Remove profilePathOnHost from bootImageConfigPaul Duffin2022-10-051-2/+2
| | | | | | | | | | | | | | | | The use of this field to return information from bootImageProfileRule up the call stack to one of the users resulted in data races being detected. This change simply returns the profile path back up the call stack. Bug: 245956352 Test: m nothing go test -race ./sdk/... -run TestSnapshotWithBootclasspathFragment_ImageName -test.count 100 # Run the previous command without this change and sometimes it # shows the data race around profilePathOnHost. With this change # that data race is not reported. Although there is still another # data race. Change-Id: I03b09e514cc94f2a6c9d5117d3b2f130cc2e4f5b
* Push Hidden_api inside HiddenAPIFlagFilePropertiesPaul Duffin2022-08-191-2/+2
| | | | | | | | | | | | | | | | | | | All usages of HiddenAPIFlagFileProperties use it as the type of a Hidden_api field. This change pushes the field inside the struct and just embeds the struct inside the structs that need it making it simpler and more consistent with how the HiddenApiPackageProperties struct is used. This is extracted as a separate change as while the change is simple it does affect a lot of lines. Keeping it separate makes it easier to review the changes. Bug: 240406019 Test: packages/modules/common/build/mainline_modules_sdks.sh # Ran the previous command with and without this change to make # sure that this change does not change the sdk snapshot # contents. Change-Id: I664453029574ef68dc5712f7bf137a1a6e78e864
* Propagate min and max sdk versions to classpaths.proto configs.satayev2021-12-011-1/+0
| | | | | | | | | | These attributed define a range for dessert releases where the jars should be active, and included in corresponding CLASSPATH varibles by derive_classpath. Bug: 190818041 Test: presubmit Change-Id: Ieb9aef29657ad0694d48a63019f93faca2678252
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-23 21:34:35 +0000