summaryrefslogtreecommitdiff
path: root/java/dexpreopt_config_test.go
AgeCommit message (Collapse)Author
2025-01-31Add t.Parallel() to java tests Colin Cross
Speeds up go test ./java from 32 seconds to 9 seconds. Test: go test ./java Change-Id: I4c6640e787c0744c6dfda03b7382839b452e24cf
2023-07-14Refactor dexpreopt for boot jars to make it flexible to config changes. Jiakai Zhang
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
2023-03-16Revert^2 "Generate a boot image extension for mainline BCP... Jiakai Zhang
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
2023-03-02Revert "Generate a boot image extension for mainline BCP jars." Jiakai Zhang
This reverts commit 3830308fb8be13df66437b9798122789c85c7e37. Reason for revert: Caused various SH regressions. Bug: 271036161 Change-Id: Ia785324f83006a095e262c251b24d49fd778427e
2023-02-24Generate a boot image extension for mainline BCP jars. Jiakai Zhang
Bug: 269230245 Test: m Test: atest art_standalone_dexpreopt_tests Change-Id: I253c30d938eee2cf2549ec2338425d53956e7cbb
2022-10-07Properly skip TestBootImageConfig on non-Linux platforms Paul Duffin
Bug: 245956352 Test: m nothing Change-Id: I6402573b378eee77d802829ec5dfacf4c514d3b8
2022-10-06Skip TestBootImageConfig on non-Linux platforms Paul Duffin
Bug: 245956352 Test: m nothing Change-Id: I4c0bfd24febd308d8efa62da9603795a7e5ed222
2022-10-06Test bootImageConfig/Variant fields Paul Duffin
Most of the fields in the bootImageConfig/Variant structs are assigned inside a Once func so are guaranteed to be only set once. However, some are assigned outside. This change adds comprehensive tests for those structs and verifies that the constant fields are preserved and the mutated fields have the correct value. The check for the constant fields is added in a new TestBootImageConfig test. The check for the mutated fields is added into TestSnapshotWithBootclasspathFragment_ImageName as that test checks an art bootclasspath_fragment in the following configurations: * source on its own * prebuilt on its own * source and prebuilt with source preferred * source and prebuilt with prebuilt It reveals a couple of interesting facts: * All the *installs fields are set to the same value irrespective of whether the source or prebuilt is preferred. The information is constructed solely from information already within the bootImageConfig/Variant and so can be moved within Once. * The licenseMetadataFile is incorrect when prebuilt is preferred. That is due to both the source and prebuilt modules setting it and the source module always wins as the source module depends on the prebuilt so always runs its GenerateAndroidBuildActions after it. Those issues will be cleaned up in following changes. Bug: 245956352 Test: m nothing Change-Id: If917cfbcb3b1c842a8682d51cc1ee1fed1c51add