libbinder_ndk: ABpBinder linkern'space muliplicity
Previously, if the same process loaded the same class in two different
linker namespaces, you could not have an ABpBinder which pointed to the
same service in both of them.
I kind of did this intentionally, because at the time I was still
figuring out a lot of this stuff, and I didn't want to make the
implementation unnecessarily complicated. I also wanted a chance to
investigate these issues. In some cases, this may mean that an ODR
issue is less noticeable (however - the way we should fix these is
by having the build system and linkers detect when we overwrite a
symbol which is not binary identical - a very difficult a noisy
task, but a neglected and unfortunate one). Anyway, we have other
checks for ODR issues now in the AIDL build system. It's okay.
Anyway - it turns out the stability mechanism in AIDL is really
awesome and enables some awesome usecases, so we need this support
now. Well.
Fixes: 262463798
Test: libbinder_ndk_unit_test
Change-Id: Idce05e13768cd4ad10c64873f393535d74cd4d3e
diff --git a/libs/binder/ndk/ibinder_internal.h b/libs/binder/ndk/ibinder_internal.h
index 8699f85..67bb092 100644
--- a/libs/binder/ndk/ibinder_internal.h
+++ b/libs/binder/ndk/ibinder_internal.h
@@ -56,6 +56,11 @@
// AIBinder instance is instance of this class for a local object. In order to transact on a
// remote object, this also must be set for simplicity (although right now, only the
// interfaceDescriptor from it is used).
+ //
+ // WARNING: When multiple classes exist with the same interface descriptor in different
+ // linkernamespaces, the first one to be associated with mClazz becomes the canonical one
+ // and the only requirement on this is that the interface descriptors match. If this
+ // is an ABpBinder, no other state can be referenced from mClazz.
const AIBinder_Class* mClazz;
std::mutex mClazzMutex;
};