Don't change the behavior of findLibrary

8f712189dfc02285573337e2b4ab17678011db14 chaged the behavior of
BaseDexClassLoader.findLibrary (to be specific any classloader
that uses DexPathList). findLibrary no longer returns null
even when the requested library isn't found in the native search path of
the classloader (because it could be loadable via namespace links even
when it's not in the search paths). However, it looks like this is
breaking some apps. To minimize the app compat problem, findLibrary()
returns its original behavior of returning null when the library is not
found. Instead, the RuntimeClass is modified to have a special case for
handling the null return from PathClassLoader.

Bug: 143649498
Bug: 109720125
Test:  run the app that was mentioned in 143649498
Change-Id: I445592b57c62782b62a1adceb4fb4f5a016d65ee

2 files changed, 19 insertions, 7 deletions

diff --git a/dalvik/src/main/java/dalvik/system/DexPathList.java b/dalvik/src/main/java/dalvik/system/DexPathList.java
index e430b5580f..c63bb13477 100644
--- a/dalvik/src/main/java/dalvik/system/DexPathList.java
+++ b/dalvik/src/main/java/dalvik/system/DexPathList.java
@@ -603,12 +603,8 @@ public final class DexPathList {
                 return path;
             }
         }
-        // Don't give up even if we failed to find the library in the native lib paths.
-        // The underlying dynamic linker might be able to find the lib in one of the linker
-        // namespaces associated with the current linker namespace. In order to give the
-        // dynamic linker a chance, proceed to load the library with its soname, which
-        // is the fileName.
-        return fileName;
+
+        return null;
     }
 
     /**
diff --git a/ojluni/src/main/java/java/lang/Runtime.java b/ojluni/src/main/java/java/lang/Runtime.java
index bb0bcb4d1d..f5c52e7b9d 100644
--- a/ojluni/src/main/java/java/lang/Runtime.java
+++ b/ojluni/src/main/java/java/lang/Runtime.java
@@ -35,7 +35,8 @@ import sun.reflect.CallerSensitive;
 import java.lang.ref.FinalizerReference;
 import java.util.ArrayList;
 import java.util.List;
-import dalvik.system.BaseDexClassLoader;
+import dalvik.system.DelegateLastClassLoader;
+import dalvik.system.PathClassLoader;
 import dalvik.system.VMDebug;
 import dalvik.system.VMRuntime;
 import sun.reflect.Reflection;
@@ -1058,6 +1059,21 @@ public class Runtime {
         // have returned null; therefore we treat BootClassLoader the same as null here.
         if (loader != null && !(loader instanceof BootClassLoader)) {
             String filename = loader.findLibrary(libraryName);
+            if (filename == null &&
+                    (loader.getClass() == PathClassLoader.class ||
+                     loader.getClass() == DelegateLastClassLoader.class)) {
+                // Don't give up even if we failed to find the library in the native lib paths.
+                // The underlying dynamic linker might be able to find the lib in one of the linker
+                // namespaces associated with the current linker namespace. In order to give the
+                // dynamic linker a chance, proceed to load the library with its soname, which
+                // is the fileName.
+                // Note that we do this only for PathClassLoader  and DelegateLastClassLoader to
+                // minimize the scope of this behavioral change as much as possible, which might
+                // cause problem like b/143649498. These two class loaders are the only
+                // platform-provided class loaders that can load apps. See the classLoader attribute
+                // of the application tag in app manifest.
+                filename = System.mapLibraryName(libraryName);
+            }
             if (filename == null) {
                 // It's not necessarily true that the ClassLoader used
                 // System.mapLibraryName, but the default setup does, and it's