Don't magically use implementations for modules in the same apex
To reduce the complexity of the apex logic, remove the apex top down
mutator, and make the build system more understandable, remove the
logic that automatically uses implementations of modules that have
stubs but are in the same apex. Modules in an apex that want to
depend on the implementations of another module should depend on it
using <dep>#impl. Misuse of the #impl syntax to depend on a module
that is not in the same will be detected and reported as an error
by the apex when it sees a transitive dependency linked against an
implementation library that is not in the apex.
Bug: 372543712
Test: all apex tests pass
Test: builds
Change-Id: I28a1bb0ca71d5cfeaae145e951c436315aadf5ca
diff --git a/cc/cc.go b/cc/cc.go
index c3c6bc2..59b13ef 100644
--- a/cc/cc.go
+++ b/cc/cc.go
@@ -3316,8 +3316,6 @@
}
func ShouldUseStubForApex(ctx android.ModuleContext, dep android.Module) bool {
- depName := ctx.OtherModuleName(dep)
-
inVendorOrProduct := false
bootstrap := false
if linkable, ok := ctx.Module().(LinkableInterface); !ok {
@@ -3347,9 +3345,8 @@
useStubs = isNotInPlatform && !bootstrap
} else {
- // If building for APEX, use stubs when the parent is in any APEX that
- // the child is not in.
- useStubs = !android.DirectlyInAllApexes(apexInfo, depName)
+ // If building for APEX, always use stubs (can be bypassed by depending on <dep>#impl)
+ useStubs = true
}
return useStubs