Overridden APEX doesn't contribute to the file contexts
This change fixes the problem that when an apex module is overridden by
another override_apex, the <apex_name>-file_contexts are duplicated when
creating the system-level file-contexts.
Fixing this by not emitting the file_context info for the overridden
apex.
In doing so, OverridableModule interface was extended to have
GetOverriddenBy() method which can be used to test whether a module is
an overridden one or not.
Bug: 144338929
Test: m (apex_test amended)
Test: add "override_apex {name:"com.googlge.android.tzdata",
Change-Id: I5e9401c32899bb9987c90cba4185f571dc1a87f0
base:"com.android.tzdata"}" and the build is successful
diff --git a/android/override_module.go b/android/override_module.go
index f946587..45f7be0 100644
--- a/android/override_module.go
+++ b/android/override_module.go
@@ -82,13 +82,16 @@
// Interface for overridable module types, e.g. android_app, apex
type OverridableModule interface {
+ Module
+ moduleBase() *OverridableModuleBase
+
setOverridableProperties(prop []interface{})
addOverride(o OverrideModule)
getOverrides() []OverrideModule
override(ctx BaseModuleContext, o OverrideModule)
- getOverriddenBy() string
+ GetOverriddenBy() string
setOverridesProperty(overridesProperties *[]string)
@@ -97,6 +100,10 @@
OverridablePropertiesDepsMutator(ctx BottomUpMutatorContext)
}
+type overridableModuleProperties struct {
+ OverriddenBy string `blueprint:"mutated"`
+}
+
// Base module struct for overridable module types
type OverridableModuleBase struct {
// List of OverrideModules that override this base module
@@ -114,12 +121,17 @@
// override information is propagated and aggregated correctly.
overridesProperty *[]string
- overriddenBy string
+ properties overridableModuleProperties
}
func InitOverridableModule(m OverridableModule, overridesProperty *[]string) {
m.setOverridableProperties(m.(Module).GetProperties())
m.setOverridesProperty(overridesProperty)
+ m.AddProperties(&m.moduleBase().properties)
+}
+
+func (o *OverridableModuleBase) moduleBase() *OverridableModuleBase {
+ return o
}
func (b *OverridableModuleBase) setOverridableProperties(prop []interface{}) {
@@ -162,11 +174,15 @@
}
}
}
- b.overriddenBy = o.Name()
+ b.properties.OverriddenBy = o.Name()
}
-func (b *OverridableModuleBase) getOverriddenBy() string {
- return b.overriddenBy
+// GetOverriddenBy returns the name of the override module that has overridden this module.
+// For example, if an override module foo has its 'base' property set to bar, then another local variant
+// of bar is created and its properties are overriden by foo. This method returns bar when called from
+// the new local variant. It returns "" when called from the original variant of bar.
+func (b *OverridableModuleBase) GetOverriddenBy() string {
+ return b.properties.OverriddenBy
}
func (b *OverridableModuleBase) OverridablePropertiesDepsMutator(ctx BottomUpMutatorContext) {
@@ -247,7 +263,7 @@
func replaceDepsOnOverridingModuleMutator(ctx BottomUpMutatorContext) {
if b, ok := ctx.Module().(OverridableModule); ok {
- if o := b.getOverriddenBy(); o != "" {
+ if o := b.GetOverriddenBy(); o != "" {
// Redirect dependencies on the overriding module to this overridden module. Overriding
// modules are basically pseudo modules, and all build actions are associated to overridden
// modules. Therefore, dependencies on overriding modules need to be forwarded there as well.