Better linking of native bridged methods

This change adds a fallback mechanism when linking native methods
with classes loaded by classloaders without associated linker
namespace.

Bug: 393035780
Test: 1. Boot and run CtsJniTestCases with v7 on native bridge (berberis)
Test: 2. Boot and run CtsJniTestCases with v8 on native bridge (berberis)
         (with aosp/3473652)
Change-Id: I6e100f7fbe62af63a2b40e0a9bedb273bc962b52

1 files changed, 7 insertions, 1 deletions

diff --git a/runtime/jni/jni_internal.cc b/runtime/jni/jni_internal.cc
index 588c2cd04d..a9a5d8b868 100644
--- a/runtime/jni/jni_internal.cc
+++ b/runtime/jni/jni_internal.cc
@@ -2701,7 +2701,13 @@ class JNI {
         // TODO: make this a hard register error in the future.
       }
 
-      if (is_class_loader_namespace_natively_bridged) {
+      // It is possible to link a class with native methods from a library loaded by
+      // a different classloader. In this case IsClassLoaderNamespaceNativelyBridged
+      // fails detect if native bridge is enabled and may return false.
+      // For this reason we always check method with native bridge (see b/393035780
+      // for details).
+      if (is_class_loader_namespace_natively_bridged ||
+          android::NativeBridgeIsNativeBridgeFunctionPointer(fnPtr)) {
         fnPtr = GenerateNativeBridgeTrampoline(fnPtr, m);
       }
       const void* final_function_ptr = class_linker->RegisterNative(soa.Self(), m, fnPtr);