Commit be024ad6 authored Mar 31, 2020 by Jiyong Park

Don't allow a lib having stubs to become a member of VNDK

If a lib has stubs, that means the library provides stable C APIs and
the APIs are guaranteed to be maintained in a backwards compatible
manner. Then there is no reason to have the same library in VNDK,
because VNDK is for libraries (usually having C++ interfaces) where API
stability across the yearly releases is hard (or impossible) to be
guaranteed.

This change triggers an error when the build system finds a VNDK lib
which has stubs defined. Users are suggested to make the lib an LLNDK
one.

Exempt-From-Owner-Approval: cherry-pick from AOSP

Bug: 151303316
Test: m
Merged-In: Id305196a9d5a6fc7e7f9c02f3fa076859dc9a282
(cherry picked from commit ea97f51a)
Change-Id: Id305196a9d5a6fc7e7f9c02f3fa076859dc9a282

parent a59774eb

cc/vndk.go

+4 −0

Original line number	Diff line number	Diff line
		@@ -309,6 +309,10 @@ func processVndkLibrary(mctx android.BottomUpMutatorContext, m *Module) {
		panic(err)
		}

		if m.HasStubsVariants() {
		mctx.PropertyErrorf("vndk.enabled", "This library provides stubs. Shouldn't be VNDK. Consider making it as LLNDK")
		}

		vndkLibrariesLock.Lock()
		defer vndkLibrariesLock.Unlock()