aboutsummaryrefslogtreecommitdiff
path: root/apex/systemserver_classpath_fragment_test.go
Commit message (Collapse)AuthorAgeFilesLines
* Propagate profile_guided requirement of imports to top-level apexSpandan Das2024-01-301-8/+12
| | | | | | | | | | | | | | | | | | | | | | For prebuilts, the dexpreopt rules of system server jars are now generated from the context of the top-level prebuilt apex and not in the context of the shim java_import modules. Since `dex_preopt.profile_guided` property is defined in java_import, this needs to be bubbled up to the top-level apex. This will be done using deapxerInfo. If profile_guided of a transitive java_import is true, the deapexed .prof file will be set as dexreopter.inputProfilePathOnHost before invoking dexpreopter.dexpreopt. This ensures that only that java_import undergoes profile guided dexpreopt, and not every other transitive java_import Test: go test ./apex -run TestPrebuiltStandaloneSystemserverclasspathFragmentContents Test: lunch cf_x86_64_only_phone-next-userdebug && m $ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex Test: du -sh $ANDROID_PRODUCT_OUT/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex 24K Bug: 308790457 Change-Id: Ibf46ecb400b3f126b243fc8d27b08d9a1aa4cc97
* Fix the args used to dexpreopt system server jars in prebuilt apexesSpandan Das2024-01-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For prebuilts, java.dexpreopt gets called twice 1. in the context of the top-level prebuilt apex 2. in the context of the java_library shim Only the artifacts of (1) get installed. The artifacts generated by 2) are unused. However the args used to generate the artifacts of (1) are incorrect. It uses moduleName(ctx) to do special-handling of apex system server jars. This special-handling does not happen in (1), so although dexpreopt artficats get generated, they get generated with the wrong args. To fix this, add an additional parameter in java.dexpreopt to pass the libraryName explicitly. Details - Delete moduleName function. This was used to determine the java library name, which is no longer safe - Add a libraryName parameter to java.dexpreopt - Most module types will use j.Name() as libraryName - prebuilt_apex and apex_set will iterate over its `contents` and use each element as libraryName when invoking java.dexpreopt With the correct args passed from (1), we can drop j.dexpreopt from (2) completely. Dropping (2) also breaks profile guided dexpreopt tests. These currently operate on (2). They will be moved to (1) in the next CL of this stack. Test: presubmits Test: lunch cf_x86_64_auto-trunk_staging-userdebug && m nothing (this was a postsubmit failure with aosp/2923733) Test: art_standalone_dexpreopt_tests on next https://android-build.corp.google.com/builds/abtd/run/L86000030001579256 Test: art-gtest on git_master-art-host https://android-build.corp.google.com/builds/abtd/run/L07800030001550262 Bug: 308790457 Bug: 322255144 Change-Id: I8eb604c82f1fa5289d3cd1a20084d56e4d7485e3
* Handle installation rules for co-existing prebuiltsSpandan Das2024-01-111-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Every module belonging to a single mainline module family will be hidden from make, except the one which has been flagged using apex_contributions Details - Introduce a new `source_apex_name` property to prebuilt_apex and override_apex. This property will be used to identify the source equivalent of a prebuilt soong apex module. - Create an N-ary tree from source to prebuilt(s). The tree wil be rooted at the source module. - In a subsequent mutator, visit every node in the tree(s). Query apex_contributions and store the handle of the node which is "active" (if any) - In the same mutator, do another pass over the tree. Invoke `HideFromMake` on every node which is not "active". The two-pass approach is needed PrebuiltSelectionInfoProvider does not know about the inter source-prebuilt dependency, this dependency can only be known by doing a graph walk of the N-ary tree. Some tangential implementation details - Each prebuilt apex has an internal deapxer module that is responsible for generating the deapex ninja rules. The name of this internal module uses the BaseModuleName (without the prebuilt_ prefix). Since we can have multiple prebuilt soong modules in trunk stable, change this to follow the name of the prebuilt module in order to avoid name collisions. Update existing unit tests accordingly Bug: 316179314 Test: go test ./apex -run TestInstallationRulesForMultipleApexPrebuilts Test: m nothing --no-skip-soong-tests Test: presubmits Change-Id: I58aa99d5e6a9859954614e6db9a8e9e2e581642d
* Move dexpreopt processing from java_*_import to prebuilt_apexSpandan Das2023-12-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dexpreopt of apex system server from prebuilts involves three soong modules 1. prebuilt_apex / apex_set 2. an internal deapexer module created by the prebuilt apex 3. java_import/java_sdk_library (3) acts as a shim for the deapexer to set the dexjar extracted from the prebuilt apex. This methodolody requires a 1:1 correspondence across the three modules This breaks down when we have multiple versions of the same prebuilt apex in the tree. In preparation for this, move the dexpreopt processing from (3) to (1). Each prebuilt_apex will create the necessary rules for dexpreopting the jars deapexed from itself. In the future, apex_contributions will be used to pick which service-foo.{odex|.vdex} to install depending on which prebuilt apex is selected. Implementation details - Embed dexpreopter in prebuiltApex structs so that this module type can register the dexpreopt rules. Since a single apex can have multiple system server jars, this also requires creating an additional scope in dexpreopt.go to prevent name collisions - Add the dexpreopt modules as required in initApexFilesForAndroidMk - Add the depreopt modules to androidMk in AndroidMkEntries. Drop the equivalent from java_import and java_sdk_library_import Bug: 308790457 Test: existing soong unit tests Test: lunch cf_x86_64_phone-next-userdebug && m out/target/product/vsoc_x86_64/system/apex/com.google.android.adservices.apex Test: Verified that the above command installs /out/target/product/vsoc_x86_64/system/framework/oat/x86_64/apex@com.android.adservices@javalib@service-adservices.jar@classes.{odex|vdex} and the equivalent files of service-sdksandbox Test: presubmits Change-Id: I01cea8956d2857fb864b415e73d3d2686d069b5e
* apex: Remove apexPackagingMutatorJooyung Han2023-08-231-5/+5
| | | | | | Bug: 279835185 Test: m Change-Id: I2f5293a5a86d2ea66c1107659abc2e746fe2775e
* Use the profiles in the APEX to dexpreopt system server jars.Jiakai Zhang2023-02-151-5/+53
| | | | | | | | | | | | | | | | | | | | | After this change, if "profile_guided: true" is set, profile-guided compilation will be enabled for the jar and the ".prof" file next to the jar in the APEX ("javalib/<name>.jar.prof") will be used as the profile when dexpreopting for the prebuilt APEX. Bug: 241823638 Test: m nothing Test: - 1. (on internal master) Patch aosp/2426453. 2. Build the APEX bundle and the module SDK of com.android.wifi 3. (on tm-dev) Patch this CL and aosp/2141972. 4. Copy the APEX bundle and the module SDK built on step 2 to the source tree 5. Disable hiddenapi check 6. lunch cf_x86_64_phone-userdebug && m MODULE_BUILD_FROM_SOURCE=false com.google.android.wifi 7. cat out/soong/.intermediates/prebuilts/module_sdk/Wifi/current/prebuilt_service-wifi/android_common_com.android.wifi/dexpreopt/oat/x86_64/javalib.invocation 8. See the profile being used. Change-Id: I55a5a295e9c5d6f0564afb139c5fb7da91ab8cae
* Add tests for the ignored "profile_guided: true" property.Jiakai Zhang2023-02-151-6/+55
| | | | | | | | This is tricky and is worth some tests. Bug: 241823638 Test: m nothing Change-Id: I9c09451d075dca7563eb42c63812375cfd974fbf
* Install system server jar profiles into the APEX.Jiakai Zhang2023-02-081-2/+32
| | | | | | | | | | | | | | | After this change, if profile-guided compilation is enabled for an APEX system server jar, the profile will be installed next to the jar with the ".prof" suffix, ("javalib/<name>.jar.prof"). This file will later be used by odrefresh and dexpreopt from prebuilt APEX. Bug: 241823638 Test: m nothing Test: - 1. Patch ag/20581649 PS2. 2. banchan com.android.btservices x86_64 && m 3. Check that "javalib/service-bluetooth.jar.prof" exists in the APEX. Change-Id: Ibcfc6257dade92bd40a6d4b7368148717d0863b9
* Add entries for STANDALONE_SYSTEMSERVER_JARS to systemserverclasspath.pbJiakai Zhang2021-11-301-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL updates platform_systemserverclasspath, systemserverclasspath_fragment, and prebuilt_systemserverclasspath_fragment to write entries for STANDALONE_SYSTEMSERVER_JARS to systemserverclasspath.pb. A new property `standalone_contents` is aded to `systemserverclasspath_fragment` and `prebuilt_systemserverclasspath_fragment` to list the standalone system server jars in the APEX, and entries will be written to systemserverclasspath.pb accordingly at build time. To add more context, these entries will be consumed by derive_classpath in order to generate an environment variable PRODUCT_STANDALONE_SYSTEM_SERVER_JARS. The environment variable will then be comsumed by odrefresh to determine what jars to preopt on early boot. Note that the variable should not end with "CLASSPATH" because the list is not used by runtime as a classpath. It is just a colon-separated list of jars. System server loads the jars separately with paths hardcoded in the code. Bug: 203198541 Test: manual - 1. Add some jars to PRODUCT_STANDALONE_SYSTEM_SERVER_JARS 2. Add some other jars to PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS and standalone_contents. 3. Build an image. 4. Flash the image to a device. 5. adb shell echo \$STANDALONE_SYSTEMSERVER_JARS 6. See the correct list of jars. Change-Id: I09a6fd1d3db85c194330da9b751702a9bf069e26
* Update variable name in error messages.Ulya Trafimovich2021-10-041-1/+1
| | | | | | | | | Variable PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS was renamed to PRODUCT_APEX_SYSTEM_SERVER_JARS in https://r.android.com/1779472. Bug: 191127295 Test: m nothing Change-Id: I0c8ae839cab443c824760b40d30b4374982010f9
* Add exported_systemserverclasspath_fragments to prebuilt_apex rule.Jiakai Zhang2021-09-301-1/+20
| | | | | | | | | | This is for exporting the contents of systemserverclasspath_fragment for dexpreopting. Bug: 194150908 Test: manual - 1. Patch aosp/1818020 and aosp/1834534 2. m SOONG_CONFIG_art_module_source_build=false com.android.art Change-Id: I7d2d2e02869d8a523f7c0efbbff81706672a95c5
* Add prebuilt_systemserverclasspath_fragment rule.Jiakai Zhang2021-09-301-0/+31
| | | | | | | | | | | | This is the prebuilt side of systemserverclasspath_fragment, currently for used for dexpreopting. The change to automactially generate prebuilt_systemserverclasspath_fragment rules will be in a separate CL. Bug: 194150908 Test: m nothing Change-Id: Ibf5322f80f78ac3ca037489f4a279456fe38a23f
* Make sure that classpath fragment contents appear in make vars.satayev2021-08-161-0/+51
| | | | | | | | | | | The source of truth for what jars are in BOOTCLASSPATH and SYSTEMSERVERCLASSPATH is make; adding a classpath fragment in soong with a new jar in the contents without having it declared in make is wrong (excluding test apexes). Bug: 191369843 Test: m nothing Change-Id: Ifd313776ee7ad206031244534ed3870126e4f835
* Fix tests to use correct fixtures for configuring (Apex)BootJars.satayev2021-08-101-0/+3
| | | | | | | | | | 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
* Add classpath fragment property to skip proto generation.satayev2021-06-171-0/+51
| | | | | | | | | | | | This must always be true for updatable apexes, but is not necessary for non-updatable apexes like com.android.i18n. In a follow up this will be used to figure out whether apex boot jars should be bundled into platform_bootclasspath. Bug: 191127295 Test: atest CtsClasspathsTestCases derive_classpath_test Change-Id: Ib7dc5b057cb24955222fb97f3ff9da079f30ed77
* Rename generate proto config file to match classpath type.satayev2021-05-241-1/+1
| | | | | | | | There is no need to leak soong module names. Bug: 180105615 Test: m && launch_cvd; atest CtsClasspathsTestCases Change-Id: I04f4e181d2f42b9d71641980a2c7c4e8cbc8e426
* Add systemserverclasspath_fragments property to apex.satayev2021-05-171-0/+78
- All contents of the fragment are added as java_lib dependencies. - Generated classpaths.proto is added into etc as required. Bug: 180105615 Test: m nothing Change-Id: I8e8e8b019c4ca2909182f205a47deffa946de6da
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 07:35:44 +0000