Provides a simple
ClassLoader implementation that operates on a
list of jar/apk files with classes.dex entries. The directory that
holds the optimized form of the files is specified explicitly. This
can be used to execute code not installed as part of an application.
The best place to put the optimized DEX files is in app-specific
storage, so that removal of the app will automatically remove the
optimized DEX files. If other storage is used (e.g. /sdcard), the
app may not have an opportunity to remove them.
Finds a class.
Finds a native library.
Finds a resource.
Returns package information for the given package.
From class java.lang.ClassLoader
From class java.lang.Object
DexClassLoader that finds interpreted and native
code. Interpreted classes are found in a set of DEX files contained
in Jar or APK files.
The path lists are separated using the character specified by
the "path.separator" system property, which defaults to ":".
|dexPath||the list of jar/apk files containing classes and resources|
|dexOutputDir||directory where optimized DEX files should be written|
|libPath||the list of directories containing native libraries; may be null|
|parent||the parent class loader|
Finds a class. This method is called by
loadClass() after the
parent ClassLoader has failed to find a loaded class of the same name.
|name||The name of the class to search for, in a human-readable form like "java.lang.String" or "java.net.URLClassLoader$3$1".|
Classobject representing the class
|ClassNotFoundException||if the class cannot be found|
Finds a native library. This method is called after the parent ClassLoader has failed to find a native library of the same name.
|libname||The name of the library to find|
nullif the library is not found.
Finds a resource. This method is called by
the parent ClassLoader has failed to find a loaded resource of the same
|name||The name of the resource to find|
nullif the resource is not found.
Returns package information for the given package. Unfortunately, the
DexClassLoader doesn't really have this information, and as a non-secure
ClassLoader, it isn't even required to, according to the spec. Yet, we
want to provide it, in order to make all those hopeful callers of
myClass.getPackage().getName() happy. Thus we construct a
Package object the first time it is being requested and fill most of the
fields with dummy values. The Package object is then put into the
ClassLoader's Package cache, so we see the same one next time. We don't
create Package objects for null arguments or for the default package.
There a limited chance that we end up with multiple Package objects representing the same package: It can happen when when a package is scattered across different JAR files being loaded by different ClassLoaders. Rather unlikely, and given that this whole thing is more or less a workaround, probably not worth the effort.
|name||the name of the class|
nullif there is not package information available for it