platform_build_soong/java/platform_bootclasspath.go

427 lines
18 KiB
Go
Raw Normal View History

// Copyright 2021 Google Inc. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package java
import (
"fmt"
"android/soong/android"
"android/soong/dexpreopt"
)
func init() {
registerPlatformBootclasspathBuildComponents(android.InitRegistrationContext)
}
func registerPlatformBootclasspathBuildComponents(ctx android.RegistrationContext) {
ctx.RegisterParallelSingletonModuleType("platform_bootclasspath", platformBootclasspathFactory)
}
// The tags used for the dependencies between the platform bootclasspath and any configured boot
// jars.
var (
platformBootclasspathArtBootJarDepTag = bootclasspathDependencyTag{name: "art-boot-jar"}
platformBootclasspathBootJarDepTag = bootclasspathDependencyTag{name: "platform-boot-jar"}
platformBootclasspathApexBootJarDepTag = bootclasspathDependencyTag{name: "apex-boot-jar"}
)
type platformBootclasspathModule struct {
android.SingletonModuleBase
ClasspathFragmentBase
properties platformBootclasspathProperties
// The apex:module pairs obtained from the configured modules.
configuredModules []android.Module
// The apex:module pairs obtained from the fragments.
fragments []android.Module
// Path to the monolithic hiddenapi-flags.csv file.
hiddenAPIFlagsCSV android.OutputPath
// Path to the monolithic hiddenapi-index.csv file.
hiddenAPIIndexCSV android.OutputPath
// Path to the monolithic hiddenapi-unsupported.csv file.
hiddenAPIMetadataCSV android.OutputPath
// Path to a srcjar containing all the transitive sources of the bootclasspath.
srcjar android.OutputPath
}
type platformBootclasspathProperties struct {
BootclasspathFragmentsDepsProperties
HiddenAPIFlagFileProperties
}
func platformBootclasspathFactory() android.SingletonModule {
m := &platformBootclasspathModule{}
m.AddProperties(&m.properties)
initClasspathFragment(m, BOOTCLASSPATH)
android.InitAndroidArchModule(m, android.DeviceSupported, android.MultilibCommon)
return m
}
var _ android.OutputFileProducer = (*platformBootclasspathModule)(nil)
func (b *platformBootclasspathModule) AndroidMkEntries() (entries []android.AndroidMkEntries) {
entries = append(entries, android.AndroidMkEntries{
Class: "FAKE",
// Need at least one output file in order for this to take effect.
OutputFile: android.OptionalPathForPath(b.hiddenAPIFlagsCSV),
Include: "$(BUILD_PHONY_PACKAGE)",
})
entries = append(entries, b.classpathFragmentBase().androidMkEntries()...)
return
}
// Make the hidden API files available from the platform-bootclasspath module.
func (b *platformBootclasspathModule) OutputFiles(tag string) (android.Paths, error) {
switch tag {
case "hiddenapi-flags.csv":
return android.Paths{b.hiddenAPIFlagsCSV}, nil
case "hiddenapi-index.csv":
return android.Paths{b.hiddenAPIIndexCSV}, nil
case "hiddenapi-metadata.csv":
return android.Paths{b.hiddenAPIMetadataCSV}, nil
case ".srcjar":
return android.Paths{b.srcjar}, nil
}
return nil, fmt.Errorf("unknown tag %s", tag)
}
func (b *platformBootclasspathModule) DepsMutator(ctx android.BottomUpMutatorContext) {
Use the correct bootjars for hiddneapi when multiple prebuilts exist 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
2023-12-20 21:13:34 +01:00
// Create a dependency on all_apex_contributions to determine the selected mainline module
ctx.AddDependency(ctx.Module(), apexContributionsMetadataDepTag, "all_apex_contributions")
b.hiddenAPIDepsMutator(ctx)
if !dexpreopt.IsDex2oatNeeded(ctx) {
return
}
// Add a dependency onto the dex2oat tool which is needed for creating the boot image. The
// path is retrieved from the dependency by GetGlobalSoongConfig(ctx).
dexpreopt.RegisterToolDeps(ctx)
}
func (b *platformBootclasspathModule) hiddenAPIDepsMutator(ctx android.BottomUpMutatorContext) {
if ctx.Config().DisableHiddenApiChecks() {
return
}
// Add dependencies onto the stub lib modules.
apiLevelToStubLibModules := hiddenAPIComputeMonolithicStubLibModules(ctx.Config())
hiddenAPIAddStubLibDependencies(ctx, apiLevelToStubLibModules)
}
func (b *platformBootclasspathModule) BootclasspathDepsMutator(ctx android.BottomUpMutatorContext) {
Refactor dexpreopt for boot jars to make it flexible to config changes. 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-07-13 12:03:38 +02:00
// Add dependencies on all the ART jars.
global := dexpreopt.GetGlobalConfig(ctx)
Use the correct bootjars for hiddneapi when multiple prebuilts exist 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
2023-12-20 21:13:34 +01:00
addDependenciesOntoSelectedBootImageApexes(ctx, "com.android.art")
// TODO: b/308174306 - Remove the mechanism of depending on the java_sdk_library(_import) directly
Refactor dexpreopt for boot jars to make it flexible to config changes. 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-07-13 12:03:38 +02:00
addDependenciesOntoBootImageModules(ctx, global.ArtApexJars, platformBootclasspathArtBootJarDepTag)
Refactor dexpreopt for boot jars to make it flexible to config changes. 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-07-13 12:03:38 +02:00
// Add dependencies on all the non-updatable jars, which are on the platform or in non-updatable
// APEXes.
addDependenciesOntoBootImageModules(ctx, b.platformJars(ctx), platformBootclasspathBootJarDepTag)
Refactor dexpreopt for boot jars to make it flexible to config changes. 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-07-13 12:03:38 +02:00
// Add dependencies on all the updatable jars, except the ART jars.
apexJars := dexpreopt.GetGlobalConfig(ctx).ApexBootJars
Use the correct bootjars for hiddneapi when multiple prebuilts exist 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
2023-12-20 21:13:34 +01:00
apexes := []string{}
for i := 0; i < apexJars.Len(); i++ {
apexes = append(apexes, apexJars.Apex(i))
}
addDependenciesOntoSelectedBootImageApexes(ctx, android.FirstUniqueStrings(apexes)...)
// TODO: b/308174306 - Remove the mechanism of depending on the java_sdk_library(_import) directly
addDependenciesOntoBootImageModules(ctx, apexJars, platformBootclasspathApexBootJarDepTag)
// Add dependencies on all the fragments.
b.properties.BootclasspathFragmentsDepsProperties.addDependenciesOntoFragments(ctx)
}
func addDependenciesOntoBootImageModules(ctx android.BottomUpMutatorContext, modules android.ConfiguredJarList, tag bootclasspathDependencyTag) {
for i := 0; i < modules.Len(); i++ {
apex := modules.Apex(i)
name := modules.Jar(i)
addDependencyOntoApexModulePair(ctx, apex, name, tag)
}
}
// GenerateSingletonBuildActions does nothing and must never do anything.
//
// This module only implements android.SingletonModule so that it can implement
// android.SingletonMakeVarsProvider.
func (b *platformBootclasspathModule) GenerateSingletonBuildActions(android.SingletonContext) {
// Keep empty
}
func (d *platformBootclasspathModule) MakeVars(ctx android.MakeVarsContext) {
d.generateHiddenApiMakeVars(ctx)
}
func (b *platformBootclasspathModule) GenerateAndroidBuildActions(ctx android.ModuleContext) {
// Gather all the dependencies from the art, platform, and apex boot jars.
artModules := gatherApexModulePairDepsWithTag(ctx, platformBootclasspathArtBootJarDepTag)
platformModules := gatherApexModulePairDepsWithTag(ctx, platformBootclasspathBootJarDepTag)
apexModules := gatherApexModulePairDepsWithTag(ctx, platformBootclasspathApexBootJarDepTag)
// Concatenate them all, in order as they would appear on the bootclasspath.
var allModules []android.Module
allModules = append(allModules, artModules...)
allModules = append(allModules, platformModules...)
allModules = append(allModules, apexModules...)
b.configuredModules = allModules
var transitiveSrcFiles android.Paths
for _, module := range allModules {
depInfo, _ := android.OtherModuleProvider(ctx, module, JavaInfoProvider)
if depInfo.TransitiveSrcFiles != nil {
transitiveSrcFiles = append(transitiveSrcFiles, depInfo.TransitiveSrcFiles.ToList()...)
}
}
jarArgs := resourcePathsToJarArgs(transitiveSrcFiles)
jarArgs = append(jarArgs, "-srcjar") // Move srcfiles to the right package
b.srcjar = android.PathForModuleOut(ctx, ctx.ModuleName()+"-transitive.srcjar").OutputPath
TransformResourcesToJar(ctx, b.srcjar, jarArgs, transitiveSrcFiles)
// Gather all the fragments dependencies.
b.fragments = gatherApexModulePairDepsWithTag(ctx, bootclasspathFragmentDepTag)
// Check the configuration of the boot modules.
// ART modules are checked by the art-bootclasspath-fragment.
b.checkPlatformModules(ctx, platformModules)
b.checkApexModules(ctx, apexModules)
b.generateClasspathProtoBuildActions(ctx)
bootDexJarByModule := b.generateHiddenAPIBuildActions(ctx, b.configuredModules, b.fragments)
buildRuleForBootJarsPackageCheck(ctx, bootDexJarByModule)
}
// Generate classpaths.proto config
func (b *platformBootclasspathModule) generateClasspathProtoBuildActions(ctx android.ModuleContext) {
configuredJars := b.configuredJars(ctx)
// ART and platform boot jars must have a corresponding entry in DEX2OATBOOTCLASSPATH
classpathJars := configuredJarListToClasspathJars(ctx, configuredJars, BOOTCLASSPATH, DEX2OATBOOTCLASSPATH)
b.classpathFragmentBase().generateClasspathProtoBuildActions(ctx, configuredJars, classpathJars)
}
func (b *platformBootclasspathModule) configuredJars(ctx android.ModuleContext) android.ConfiguredJarList {
// Include all non APEX jars
jars := b.platformJars(ctx)
// Include jars from APEXes that don't populate their classpath proto config.
remainingJars := dexpreopt.GetGlobalConfig(ctx).ApexBootJars
for _, fragment := range b.fragments {
info, _ := android.OtherModuleProvider(ctx, fragment, ClasspathFragmentProtoContentInfoProvider)
if info.ClasspathFragmentProtoGenerated {
remainingJars = remainingJars.RemoveList(info.ClasspathFragmentProtoContents)
}
}
for i := 0; i < remainingJars.Len(); i++ {
jars = jars.Append(remainingJars.Apex(i), remainingJars.Jar(i))
}
return jars
}
func (b *platformBootclasspathModule) platformJars(ctx android.PathContext) android.ConfiguredJarList {
Refactor dexpreopt for boot jars to make it flexible to config changes. 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-07-13 12:03:38 +02:00
global := dexpreopt.GetGlobalConfig(ctx)
return global.BootJars.RemoveList(global.ArtApexJars)
}
// checkPlatformModules ensures that the non-updatable modules supplied are not part of an
// apex module.
func (b *platformBootclasspathModule) checkPlatformModules(ctx android.ModuleContext, modules []android.Module) {
// TODO(satayev): change this check to only allow core-icu4j, all apex jars should not be here.
for _, m := range modules {
apexInfo, _ := android.OtherModuleProvider(ctx, m, android.ApexInfoProvider)
fromUpdatableApex := apexInfo.Updatable
if fromUpdatableApex {
// error: this jar is part of an updatable apex
ctx.ModuleErrorf("module %q from updatable apexes %q is not allowed in the platform bootclasspath", ctx.OtherModuleName(m), apexInfo.InApexVariants)
} else {
// ok: this jar is part of the platform or a non-updatable apex
}
}
}
// checkApexModules ensures that the apex modules supplied are not from the platform.
func (b *platformBootclasspathModule) checkApexModules(ctx android.ModuleContext, modules []android.Module) {
for _, m := range modules {
apexInfo, _ := android.OtherModuleProvider(ctx, m, android.ApexInfoProvider)
fromUpdatableApex := apexInfo.Updatable
if fromUpdatableApex {
// ok: this jar is part of an updatable apex
} else {
name := ctx.OtherModuleName(m)
if apexInfo.IsForPlatform() {
Workaround to make AlwaysUsePrebuiltSdks() work with platform_bootclasspath 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
2021-05-19 10:36:09 +02:00
// If AlwaysUsePrebuiltSdks() returns true then it is possible that the updatable list will
// include platform variants of a prebuilt module due to workarounds elsewhere. In that case
// do not treat this as an error.
// TODO(b/179354495): Always treat this as an error when migration to bootclasspath_fragment
// modules is complete.
if !ctx.Config().AlwaysUsePrebuiltSdks() {
// error: this jar is part of the platform
ctx.ModuleErrorf("module %q from platform is not allowed in the apex boot jars list", name)
Workaround to make AlwaysUsePrebuiltSdks() work with platform_bootclasspath 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
2021-05-19 10:36:09 +02:00
}
} else {
// TODO(b/177892522): Treat this as an error.
// Cannot do that at the moment because framework-wifi and framework-tethering are in the
// PRODUCT_APEX_BOOT_JARS but not marked as updatable in AOSP.
}
}
}
}
// generateHiddenAPIBuildActions generates all the hidden API related build rules.
func (b *platformBootclasspathModule) generateHiddenAPIBuildActions(ctx android.ModuleContext, modules []android.Module, fragments []android.Module) bootDexJarByModule {
// Save the paths to the monolithic files for retrieval via OutputFiles().
b.hiddenAPIFlagsCSV = hiddenAPISingletonPaths(ctx).flags
b.hiddenAPIIndexCSV = hiddenAPISingletonPaths(ctx).index
b.hiddenAPIMetadataCSV = hiddenAPISingletonPaths(ctx).metadata
bootDexJarByModule := extractBootDexJarsFromModules(ctx, modules)
// Don't run any hiddenapi rules if hidden api checks are disabled. This is a performance
// optimization that can be used to reduce the incremental build time but as its name suggests it
// can be unsafe to use, e.g. when the changes affect anything that goes on the bootclasspath.
if ctx.Config().DisableHiddenApiChecks() {
paths := android.OutputPaths{b.hiddenAPIFlagsCSV, b.hiddenAPIIndexCSV, b.hiddenAPIMetadataCSV}
for _, path := range paths {
ctx.Build(pctx, android.BuildParams{
Rule: android.Touch,
Output: path,
})
}
return bootDexJarByModule
}
// Construct a list of ClasspathElement objects from the modules and fragments.
classpathElements := CreateClasspathElements(ctx, modules, fragments)
monolithicInfo := b.createAndProvideMonolithicHiddenAPIInfo(ctx, classpathElements)
// Extract the classes jars only from those libraries that do not have corresponding fragments as
// the fragments will have already provided the flags that are needed.
classesJars := monolithicInfo.ClassesJars
// Create the input to pass to buildRuleToGenerateHiddenAPIStubFlagsFile
input := newHiddenAPIFlagInput()
// Gather stub library information from the dependencies on modules provided by
// hiddenAPIComputeMonolithicStubLibModules.
input.gatherStubLibInfo(ctx, nil)
// Use the flag files from this module and all the fragments.
input.FlagFilesByCategory = monolithicInfo.FlagsFilesByCategory
// Generate the monolithic stub-flags.csv file.
stubFlags := hiddenAPISingletonPaths(ctx).stubFlags
buildRuleToGenerateHiddenAPIStubFlagsFile(ctx, "platform-bootclasspath-monolithic-hiddenapi-stub-flags", "monolithic hidden API stub flags", stubFlags, bootDexJarByModule.bootDexJars(), input, monolithicInfo.StubFlagSubsets)
// Generate the annotation-flags.csv file from all the module annotations.
annotationFlags := android.PathForModuleOut(ctx, "hiddenapi-monolithic", "annotation-flags-from-classes.csv")
buildRuleToGenerateAnnotationFlags(ctx, "intermediate hidden API flags", classesJars, stubFlags, annotationFlags)
// Generate the monolithic hiddenapi-flags.csv file.
//
// Use annotation flags generated directly from the classes jars as well as annotation flag files
// provided by prebuilts.
allAnnotationFlagFiles := android.Paths{annotationFlags}
allAnnotationFlagFiles = append(allAnnotationFlagFiles, monolithicInfo.AnnotationFlagsPaths...)
allFlags := hiddenAPISingletonPaths(ctx).flags
buildRuleToGenerateHiddenApiFlags(ctx, "hiddenAPIFlagsFile", "monolithic hidden API flags", allFlags, stubFlags, allAnnotationFlagFiles, monolithicInfo.FlagsFilesByCategory, monolithicInfo.FlagSubsets, android.OptionalPath{})
// Generate an intermediate monolithic hiddenapi-metadata.csv file directly from the annotations
// in the source code.
intermediateMetadataCSV := android.PathForModuleOut(ctx, "hiddenapi-monolithic", "metadata-from-classes.csv")
buildRuleToGenerateMetadata(ctx, "intermediate hidden API metadata", classesJars, stubFlags, intermediateMetadataCSV)
// Generate the monolithic hiddenapi-metadata.csv file.
//
// Use metadata files generated directly from the classes jars as well as metadata files provided
// by prebuilts.
//
// This has the side effect of ensuring that the output file uses | quotes just in case that is
// important for the tools that consume the metadata file.
allMetadataFlagFiles := android.Paths{intermediateMetadataCSV}
allMetadataFlagFiles = append(allMetadataFlagFiles, monolithicInfo.MetadataPaths...)
metadataCSV := hiddenAPISingletonPaths(ctx).metadata
b.buildRuleMergeCSV(ctx, "monolithic hidden API metadata", allMetadataFlagFiles, metadataCSV)
// Generate an intermediate monolithic hiddenapi-index.csv file directly from the CSV files in the
// classes jars.
intermediateIndexCSV := android.PathForModuleOut(ctx, "hiddenapi-monolithic", "index-from-classes.csv")
buildRuleToGenerateIndex(ctx, "intermediate hidden API index", classesJars, intermediateIndexCSV)
// Generate the monolithic hiddenapi-index.csv file.
//
// Use index files generated directly from the classes jars as well as index files provided
// by prebuilts.
allIndexFlagFiles := android.Paths{intermediateIndexCSV}
allIndexFlagFiles = append(allIndexFlagFiles, monolithicInfo.IndexPaths...)
indexCSV := hiddenAPISingletonPaths(ctx).index
b.buildRuleMergeCSV(ctx, "monolithic hidden API index", allIndexFlagFiles, indexCSV)
return bootDexJarByModule
}
// createAndProvideMonolithicHiddenAPIInfo creates a MonolithicHiddenAPIInfo and provides it for
// testing.
func (b *platformBootclasspathModule) createAndProvideMonolithicHiddenAPIInfo(ctx android.ModuleContext, classpathElements ClasspathElements) MonolithicHiddenAPIInfo {
// Create a temporary input structure in which to collate information provided directly by this
// module, either through properties or direct dependencies.
temporaryInput := newHiddenAPIFlagInput()
// Create paths to the flag files specified in the properties.
temporaryInput.extractFlagFilesFromProperties(ctx, &b.properties.HiddenAPIFlagFileProperties)
// Create the monolithic info, by starting with the flag files specified on this and then merging
// in information from all the fragment dependencies of this.
monolithicInfo := newMonolithicHiddenAPIInfo(ctx, temporaryInput.FlagFilesByCategory, classpathElements)
// Store the information for testing.
android.SetProvider(ctx, MonolithicHiddenAPIInfoProvider, monolithicInfo)
return monolithicInfo
}
func (b *platformBootclasspathModule) buildRuleMergeCSV(ctx android.ModuleContext, desc string, inputPaths android.Paths, outputPath android.WritablePath) {
rule := android.NewRuleBuilder(pctx, ctx)
rule.Command().
BuiltTool("merge_csv").
Flag("--key_field signature").
FlagWithOutput("--output=", outputPath).
Inputs(inputPaths)
rule.Build(desc, desc)
}
// generateHiddenApiMakeVars generates make variables needed by hidden API related make rules, e.g.
// veridex and run-appcompat.
func (b *platformBootclasspathModule) generateHiddenApiMakeVars(ctx android.MakeVarsContext) {
if ctx.Config().IsEnvTrue("UNSAFE_DISABLE_HIDDENAPI_FLAGS") {
return
}
// INTERNAL_PLATFORM_HIDDENAPI_FLAGS is used by Make rules in art/ and cts/.
ctx.Strict("INTERNAL_PLATFORM_HIDDENAPI_FLAGS", b.hiddenAPIFlagsCSV.String())
}