Mechanism to select a specific version of java_sdk_library_import
This CL is the java_sdk_library_import equivalent of aosp/2928483. With trunk stable, we will have multiple apex prebuilts in the tree. Each apex prebuilt will have its own module sdk. This means that it is possible to have mutliple versions of `framework-foo` in the tree. This CL introduces a mechanism to select a specific versioned java_sdk_library prebuilt. Implementation details - Add a `source_module_name` property to java_sdk_library_import. This will identify the source equivalent of the jsl in packages/modules. This used to be implicit - i.e. the name without the prebuilt_ prefix. With multiple prebuilts, this has to become explicit. - Set appropriate `source_module_name`(s) in the dynamically created child modules. e.g. the source_module_name on sdklib.v1.stubs and sdklib.v2.stubs will both be sdklib.stubs, assuming `source_module_name` on the top-level jsl_import is sdklib - Add a private Created_by_java_sdk_library_name property to java_import and prebuilt_stubs_sources modules. This will be used to idenfity the top level java_sdk_library_import that was used to create these child modules. This is necessary because java_sdk_library_imoprt is a macro that creates 1:many modules. However, to avoid toil, only the top-level java_sdk_library_import will be listed in `apex_contributions`. This new property will be used for source/prebuilt selection in android/prebuuilt.go - Rename BaseModuleName in commonSdkLibraryAndImportModule to RootLibraryName. This is necesssary because the former is now reserved to identify the source equivalent of a prebuilt module (maybe we should rename it?) Bug: 322175508 Test: Added a unit test Change-Id: If6aa6b0e939a07f8263874941413908383c81a78
Loading
Please register or sign in to comment