diff options
author | Tobias Thierer <tobiast@google.com> | 2018-07-27 20:26:29 +0100 |
---|---|---|
committer | Tobias Thierer <tobiast@google.com> | 2018-07-28 01:51:29 +0100 |
commit | 73f9342b1c104c070d8de122a413d0b9c3d38bc5 (patch) | |
tree | 60c70b18962e9668a2ce5d287bff16c81282617b /annotations/generate_annotated_java_files.py | |
parent | b7e8552681a4383778a10a74104e3dac5b957024 (diff) |
Make Runtime.loadLibrary0() consistent with Class.getClassLoader().
On Android, Class.getClassLoader() can return BootClassLoader, which
does not implement findLibrary(). This CL changes
Runtime.loadLibrary0(ClassLoader, String) to check for BootClassLoader
before attempting to call findLibrary() on it.
This CL should not affect the behavior of any public API because
the public method loadLibrary(String) uses the native method
VMStack.getCallingClassLoader() which circumvents Class.getClassLoader()
and returns null rather than BootClassLoader.
This CL does change the behavior of loadLibrary(ClassLoader,String)
and loadLibrary(String,ClassLoader) in the case where the BootClassLoader
is passed, but those methods are private (greylisted) API so they are
not supported, and the new behavior is more correct for BootClassLoader.
The changed area of code was already carrying (undocumented) changes,
so I've used Android-note to document the change. The missing
Android-changed marker is left to a follow-up CL.
Bug: 111850480
Bug: 111867869
Test: At this CL, only treehugger. Ran CtsLibcoreTestCases at the
follow-up CL, which replaces uses of VMStack.getCallingClassLoader()
with code based on Class.getClassLoader() (which may therefore
encounter BootClassLoader).
Change-Id: I0389380c77efc827b95b82bbf42619df966ae8ed
Diffstat (limited to 'annotations/generate_annotated_java_files.py')
0 files changed, 0 insertions, 0 deletions