Android类动态加载技术

转自大牛博客：http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html 

把回复一同转载，便于学习只用。

Android应用开发在一般情况下，常规的开发方式和代码架构就能满足我们的普通需求。但是有些特殊问题，常常引发我们进一步的沉思。我们从沉思中产生顿悟，从而产生新的技术形式。

如何开发一个可以自定义控件的Android应用？就像eclipse一样，可以动态加载插件；如何让Android应用执行服务器上的不可预知的代码？如何对Android应用加密，而只在执行时自解密，从而防止被破解？……

熟悉Java技术的朋友，可能意识到，我们需要使用类加载器灵活的加载执行的类。这在Java里已经算是一项比较成熟的技术了，但是在Android中，我们大多数人都还非常陌生。

类加载机制

       Dalvik虚拟机如同其他Java虚拟机一样，在运行程序时首先需要将对应的类加载到内存中。而在Java标准的虚拟机中，类加载可以从class文件中读取，也可以是其他形式的二进制流。因此，我们常常利用这一点，在程序运行时手动加载Class，从而达到代码动态加载执行的目的。

       然而Dalvik虚拟机毕竟不算是标准的Java虚拟机，因此在类加载机制上，它们有相同的地方，也有不同之处。我们必须区别对待。

       例如，在使用标准Java虚拟机时，我们经常自定义继承自ClassLoader的类加载器。然后通过defineClass方法来从一个二进制流中加载Class。然而，这在Android里是行不通的，大家就没必要走弯路了。参看源码我们知道，Android中ClassLoader的defineClass方法具体是调用VMClassLoader的defineClass本地静态方法。而这个本地方法除了抛出一个“UnsupportedOperationException”之外，什么都没做，甚至连返回值都为空。

static  void Dalvik_java_lang_VMClassLoader_defineClass( const u4* args,

    JValue* pResult)

{

    Object* loader = (Object*) args[0];

    StringObject* nameObj = (StringObject*) args[1];

    const u1* data = (const u1*) args[2];

    int offset = args[3];

    int len = args[4];

    Object* pd = (Object*) args[5];

    char* name = NULL;

 

    name = dvmCreateCstrFromString(nameObj);

    LOGE("ERROR: defineClass(%p, %s, %p, %d, %d, %p)\n",

        loader, name, data, offset, len, pd);

    dvmThrowException("Ljava/lang/UnsupportedOperationException;",

        "can't load this type of class file");

 

    free(name);

    RETURN_VOID();

}

Dalvik虚拟机类加载机制

       那如果在Dalvik虚拟机里，ClassLoader不好使，我们如何实现动态加载类呢？Android为我们从ClassLoader派生出了两个类：DexClassLoader和PathClassLoader。其中需要特别说明的是PathClassLoader中一段被注释掉的代码：

/* --this doesn't work in current version of Dalvik--

    if (data != null) {

        System.out.println("--- Found class " + name

            + " in zip[" + i + "] '" + mZips[i].getName() + "'");

        int dotIndex = name.lastIndexOf('.');

        if (dotIndex != -1) {

            String packageName = name.substring(0, dotIndex);

            synchronized (this) {

                Package packageObj = getPackage(packageName);

                if (packageObj == null) {

                    definePackage(packageName, null, null,

                            null, null, null, null, null);

                }

            }

        }

 

        return defineClass(name, data, 0, data.length);

    }

*/

       这从另一方面佐证了defineClass函数在Dalvik虚拟机里确实是被阉割了。而在这两个继承自ClassLoader的类加载器，本质上是重载了ClassLoader的findClass方法。在执行loadClass时，我们可以参看ClassLoader部分源码：

protected Class<?> loadClass(String className,  boolean resolve) 

throws ClassNotFoundException  {

Class<?> clazz = findLoadedClass(className);

 

    if (clazz == null) {

        try {

            clazz = parent.loadClass(className, false);

        } catch (ClassNotFoundException e) {

            // Don't want to see this.

        }

 

        if (clazz == null) {

            clazz = findClass(className);

        }

    }

 

    return clazz;

}

       因此DexClassLoader和PathClassLoader都属于符合双亲委派模型的类加载器（因为它们没有重载loadClass方法）。也就是说，它们在加载一个类之前，回去检查自己以及自己以上的类加载器是否已经加载了这个类。如果已经加载过了，就会直接将之返回，而不会重复加载。

       DexClassLoader和PathClassLoader其实都是通过DexFile这个类来实现类加载的。这里需要顺便提一下的是，Dalvik虚拟机识别的是dex文件，而不是class文件。因此，我们供类加载的文件也只能是dex文件，或者包含有dex文件的.apk或.jar文件。

        也许有人想到，既然DexFile可以直接加载类，那么我们为什么还要使用ClassLoader的子类呢？DexFile在加载类时，具体是调用成员方法loadClass或者loadClassBinaryName。其中loadClassBinaryName需要将包含包名的类名中的”.”转换为”/”。我们看一下loadClass代码就清楚了：

public Class loadClass(String name, ClassLoader loader)  {

        String slashName = name.replace('.', '/');

        return loadClassBinaryName(slashName, loader);

}

       在这段代码前有一段注释，截取关键一部分就是说：If you are not calling this from a class loader, this is most likely not going to do what you want. Use {@link Class#forName(String)} instead. 这就是我们需要使用ClassLoader子类的原因。至于它是如何验证是否是在ClassLoader中调用此方法的，我没有研究，大家如果有兴趣可以继续深入下去。

       有一个细节，可能大家不容易注意到。PathClassLoader是通过构造函数new DexFile(path)来产生DexFile对象的；而DexClassLoader则是通过其静态方法loadDex（path, outpath, 0）得到DexFile对象。这两者的区别在于DexClassLoader需要提供一个可写的outpath路径，用来释放.apk包或者.jar包中的dex文件。换个说法来说，就是PathClassLoader不能主动从zip包中释放出dex，因此只支持直接操作dex格式文件，或者已经安装的apk（因为已经安装的apk在cache中存在缓存的dex文件）。而DexClassLoader可以支持.apk、.jar和.dex文件，并且会在指定的outpath路径释放出dex文件。

       另外，PathClassLoader在加载类时调用的是DexFile的loadClassBinaryName，而DexClassLoader调用的是loadClass。因此，在使用PathClassLoader时类全名需要用”/”替换”.”。

实际操作

       这一部分比较简单，因此我就不赘言了。只是简单的说下。

       可能使用到的工具都比较常规：javac、dx、eclipse等。其中dx工具最好是指明--no-strict，因为class文件的路径可能不匹配。

       加载好类后，通常我们可以通过Java反射机制来使用这个类。但是这样效率相对不高，而且老用反射代码也比较复杂凌乱。更好的做法是定义一个interface，并将这个interface写进容器端。待加载的类，继承自这个interface，并且有一个参数为空的构造函数，以使我们能够通过Class的newInstance方法产生对象。然后将对象强制转换为interface对象，于是就可以直接调用成员方法了。

关于代码加密的一些设想

       最初设想将dex文件加密，然后通过JNI将解密代码写在Native层。解密之后直接传上二进制流，再通过defineClass将类加载到内存中。

       现在也可以这样做，但是由于不能直接使用defineClass，而必须传文件路径给dalvik虚拟机内核，因此解密后的文件需要写到磁盘上，增加了被破解的风险。

       Dalvik虚拟机内核仅支持从dex文件加载类的方式是不灵活的，由于没有非常深入的研究内核，我不能确定是Dalvik虚拟机本身不支持还是Android在移植时将其阉割了。不过相信Dalvik或者是Android开源项目都正在向能够支持raw数据定义类方向努力。

       我们可以在文档中看到Google说：Jar or APK file with "classes.dex". (May expand this to include "raw DEX" in the future.)；在Android的Dalvik源码中我们也能看到RawDexFile的身影（不过没有具体实现）。

       在RawDexFile出来之前，我们都只能使用这种存在一定风险的加密方式。需要注意释放的dex文件路径及权限管理，另外，在加载完毕类之后，除非出于其他目的否则应该马上删除临时的解密文件。


转载请注明出处：http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html 

posted on 2011-10-29 21:51 zh.weir 阅读(11336) 评论(25)  编辑  收藏 所属分类: Android软件安全

评论

# re: Android类动态加载技术 2011-11-30 13:25 android动态加载

更好的做法是定义一个interface，并将这个interface写进容器端 
>容器端做interface的强制类型转换时出现异常，java.lang.ClassCastException: 
不知道您有没有遇到？  回复  更多评论   

# re: Android类动态加载技术 2011-11-30 20:52 zh-weir

检查一下，是否在Host端和Plugin端分别都定义了liangzijian这个接口。如果都定义了，且均被编译进了字节码文件中就会发生类似的问题。原因是 newInstance生成的对象实现的是Plugin端的liangzijian接口，而你想要转化的是Host端的liangzijian接口。两个接口虽然名字相同，甚至可能包名也一样，但是它们是由不同的类加载器加载的，所以不同不能实现转化。 

解决办法是不要将liangzijian接口编译进Plugin端的字节码中。具体做法是导入liangzijian接口的jar库时，不要使用添加外部jar库，而应使用user library。后一种方式不会将库中的类编译进字节码中，而是在运行时去动态链接。 
  回复  更多评论   

# re: Android类动态加载技术 2011-12-01 15:15 android动态加载

@zh-weir 
问题解决了，需要注意两点： 
1、Host端和Plugin端interface文件的包名需要一致 
2、jar文件打包时不要包含interface文件 

另外，DexClassLoader的最后一个参数使用getClassLoader()或者VMStack.getCallingClassLoader()；  回复  更多评论   

# re: Android类动态加载技术 2011-12-02 10:31 zephyranthes

有点问题想请教楼主,之前使用dexclassloader想加载另一个apk的activity会出现activitynotfoundexception异常,似乎这种方式行不通.

后来想到是不时只是写一个jni的native activity,当apk运行时,会先运行这个jni so,然后该so生成解密的dex文件,再通过dexclassloader加载该dex中的activity?

麻烦楼主解答,谢谢  回复  更多评论   

# re: Android类动态加载技术 2012-02-17 23:59 passbye

反复反复反复反复反复反复反复反复反复  回复  更多评论   

# re: Android类动态加载技术 2012-02-18 00:01 pass

请问对于（对Android应用加密，而只在执行时自解密，从而防止被破解？）这句话该如何理解，是对本地的（已安装好的）apk加密还是什么操作？请大家指教。谢谢，希望大家共同进步。  回复  更多评论   

# re: Android类动态加载技术 2012-02-28 09:19 zh_weir

@pass

由于apk应用需要经过Android系统的解析和安装，因此是不能对它进行直接加密的哦。那样会导致apk无法安装或者无法运行。

我的意思是将核心代码抽取出来，作为二进制资源，由APK应用在运行时动态加载。  回复  更多评论   

# re: Android类动态加载技术 2012-03-08 20:05 林风

@android动态加载 
可否留个邮箱，交流一下，My Email [email protected].  回复  更多评论   

# re: Android类动态加载技术 2012-03-09 17:06 zh.weir

@林风

呵呵，其实右上方的公告里有写。[email protected] 。

欢迎交流！  回复  更多评论   

# re: Android类动态加载技术 2012-03-26 10:04 ljj

小弟现正开发一个这样一个应用，这个应用做为主应用，只需要实现一些基本的功能就行， 
如果要扩展功能的话，就通过开发一些小插件来实现 

实现原理是这样的： 
主应用（Host）定义一个接口： 
public abstract interface IExtension｛ 
void method1(WebView webview,....); 
void method2(); 
｝ 

public class AbstractExtension extends ContextWrapper implements IExtension{ 
..... 
基本是对IExtension的空实现 

} 


这里应用反射来实例化一个插件： 
ClassLoader localExtensionClassLoader = context.createPackageContext(this.mPackageName,Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY).getClassLoader(); 
ClassLoader localSystemClassLoader = OlivePackageManager.getSystemClassLoader(); 

ClassLoaderWrapper localClassLoaderWrapper = new ClassLoaderWrapper(localExtensionClassLoader, localSystemClassLoader); 

String localClassName = String.valueOf(this.mPackageName) + ".Extension"; 
Class<?> localClass = localClassLoaderWrapper.loadClass(localClassName); 

Constructor<?> localConstructor = localClass.getConstructor( new Class[]{Context.class} ); 
localConstructor.setAccessible(true); 

Object instance = localConstructor.newInstance( new Object[]{context} ); 




public class ClassLoaderWrapper extends ClassLoader｛ 

public ClassLoaderWrapper(ClassLoader extensionClassLoader, ClassLoader systemClassLoader) { 
super(systemClassLoader); 
this.mLoader = extensionClassLoader; 
} 

protected Class<?> findClass(String className) throws ClassNotFoundException { 
System.out.println("mLoader type === " + mLoader.toString()); 
Class<?> localClass = null; 

if (localClass == null){ 
//这个地方，就是这个地方，加载失败 
localClass = this.mLoader.loadClass(className); 
} 

System.out.println("mLoader.loadClass============="+localClass); 
return localClass; 
} 

protected Class<?> loadClass(String className, boolean paramBoolean){ 
Class<?> localClass = null; 
try { 
localClass = getParent().loadClass(className); 
} catch (ClassNotFoundException localClassNotFoundException) { 
localClass = findLoadedClass(className); 

if (localClass == null) { 
try { 
localClass = findClass(className); 
} catch (ClassNotFoundException e) { 
} 
} 
} 

return localClass; 
} 
｝ 



在插件工程中： 
public class Extension extends AbstractExtension｛ 
...实现IExtension接口 
｝ 

这样做的话，插件工程必须加入对主工程(Host)的引用 



思想是好的，但是问题出来了，我主应用的类加载器总是load不到插件工程的Extension类， 
但是如果我的插件工程里面不extends AbstractExtension 的话，是ok的，但是不继承，就失去了意义。 

分析原因： 
public ClassLoaderWrapper(ClassLoader extensionClassLoader, ClassLoader systemClassLoader) { 
super(systemClassLoader); 
this.mLoader = extensionClassLoader; 
} 
这个构造函数里面，extensionClassLoader作为父类加载器，extensionClassLoader作为插件的类加载器， 

loadClass方法里面，先用systemClassLoader加载，应该是加载不到插件的Extension的，那么接下来就使用extensionClassLoader来加载，这个时候extensionClassLoader与插件的Extension是同一Context,理所当然能够加载到，但是问题是Extension extends AbstractExtension，它肯定是加载不到AbstractExtension，导致插件的Extension也加载失败 

这个问题困扰了我多日了，希望哪位给个意见，帮助分析一下，我应该怎么做？ 

  回复  更多评论   

# re: Android类动态加载技术 2012-03-26 15:09 zh-weir

@ljj

之前的评论有说：

需要注意两点： 
1、Host端和Plugin端interface文件的包名需要一致 
2、jar文件打包时不要包含interface文件 

另外，DexClassLoader的最后一个参数使用getClassLoader()或者VMStack.getCallingClassLoader()；  回复  更多评论   

# re: Android类动态加载技术 2012-03-26 15:39 ljj

楼主，我用的是自定的classloader，没用DexClassLoader，我现在就是要动态加载插件的 
类Class<?> localClass = localClassLoaderWrapper.loadClass(localClassName);但是在自定义的classloader中的@Override 
protected Class<?> findClass(String className) 
throws ClassNotFoundException { 
System.out.println("mLoader type === " + mLoader.toString()); 
Class<?> localClass = null; 
if ((this.mLoader instanceof PathClassLoader)){ 
//localClass = a(paramString); 

} 
if (localClass == null) { 
// 这个地方，就是这个地方，加载失败 
localClass = this.mLoader.loadClass(className); 
} 

System.out.println("mLoader.loadClass=============" + localClass); 
return localClass; 
} 

我没有用到jar包，谢谢  回复  更多评论   

# re: Android类动态加载技术 2012-03-26 16:45 zh-weir

@ljj

没有用到jar，那你是从哪个文件里load类？这点需要明确。个人认为，第一可能是没有指明从哪个文件load类；第二是IExtension被不同的类加载器加载了两次，这样两个IExtension虽然名字相同、包名相同，但是它们是不同的类。  回复  更多评论   

# re: Android类动态加载技术 2012-03-26 17:25 ljj

@zh-weir 

我是要加载插件中的类 

String localClassName = String.valueOf(packageName)+ ".Extension"; 


其中ClassLoaderWrapper 是自定义的classloader 
IExtension只在主host定义的接口 
在主host基本是对IExtension的空实现 

在插件中具体实现 

ClassLoaderWrapper localClassLoaderWrapper = new ClassLoaderWrapper (localExtensionClassLoader , localSystemClassLoader ); 
String localClassName = String.valueOf(this.c)+ ".Extension"; 
Class<?> localClass = localClassLoaderWrapper.loadClass(localClassName); 


  回复  更多评论   

# re: Android类动态加载技术 2012-03-26 17:37 zh.weir

@ljj

String localClassName = String.valueOf(this.c)+ ".Extension"; 
Class<?> localClass = localClassLoaderWrapper.loadClass(localClassName); 

这是load插件中的类吗？你的“插件”存在于哪？是安装好的apk，还是未安装的apk，还是jar或者dex文件？总需要一个路径的。  回复  更多评论   

# re: Android类动态加载技术 2012-03-27 08:17 ljj

@zh-weir 
我的插件是已安装好的apk， 


String localClassName = String.valueOf(this.c)+ ".Extension"; 
Class<?> localClass = localClassLoaderWrapper.loadClass(localClassName); 


localClassName 是要去动态加载的插件中的类名，现在就是加载不上， 
自定义的classloader中 

@Override 
protected Class<?> findClass(String className) 
throws ClassNotFoundException { 
System.out.println("mLoader type === " + mLoader.toString()); 
Class<?> localClass = null; 
if ((this.mLoader instanceof PathClassLoader)){ 
//localClass = a(paramString); 

} 
if (localClass == null) { 
// 这个地方，就是这个地方，加载失败 
localClass = this.mLoader.loadClass(className); 
} 

System.out.println("mLoader.loadClass=============" + localClass); 
return localClass; 
}  回复  更多评论   

# re: Android类动态加载技术 2012-03-27 19:54 zh-weir

又看了一下你的代码。首先应该是AbstractExtension这个类没有加载到。这个类，理论上应该是由Host端的类加载器加载好的。所以问题是，plugin端可能并没有发现由host端加载好的AbstractExtension类。分析了可能的原因，觉得ClassLoader localSystemClassLoader = OlivePackageManager.getSystemClassLoader();这个Classloader可能并不是ClassLoader localExtensionClassLoader = context.createPackageContext(this.mPackageName,Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY).getClassLoader(); 这个ClassLoader的parent……  回复  更多评论   

# re: Android类动态加载技术 2012-03-27 20:14 ljj

我把插件工程 和主host 的代码发到你邮箱了，帮看下吧，谢谢！  回复  更多评论   

# re: Android类动态加载技术 2012-03-29 08:34 zh-weir

不好意思，我可能周末才有时间看你的这份代码哦……
办公室不让收外部邮箱邮件，业余时间又少得可怜。  回复  更多评论   

# re: Android类动态加载技术[未登录] 2012-03-30 14:37 123

@zh-weir
按照这个方法我依然没有实现，我用的是PathClassLoader。  回复  更多评论   

# re: Android类动态加载技术[未登录] 2012-03-30 15:04 123

@zh-weir
你好，看了你的帖子的确让我学到不少。

但是我的实现依然存在问题。
以下是我最近一个项目的需求：我要使我的App（容器端）中某个固定的View可以替换为其他开发者开发的任意自定义控件。目前利用PathClassLoader已经实现了基本的替换功能。但是存在一个问题，跟上面几位朋友讨论的问题相似，在容器端我需要定义一些接口（目前是为了实现观察者模式，当然以后可能提供更多的接口用以添加容器端和插件端的交互），在插件端的自定义控件可以实现这些接口，但是根据楼上提供的方法，依然存在ClassCastException的问题。

以下是我实现的一些细节，请LZ看看哪里有问题：
1.我使用的是PathClassLoader，因为插件需要被安装，所以不用DexClassLoader。
2.PathClassLoader构造的时候使用的是getSystemClassLoader。
3.利用Eclipse将接口导出到jar（我这里不太清楚是否需要用dx工具将jar里面的.class类型转化，我目前的做法是没有转化），且不含源文件，插件端可以编译通过。  回复  更多评论   

# re: Android类动态加载技术 2012-05-15 19:45 briancol

博主：请教个问题:
Dalvik 在加载类时， 如果该类已被加载，就不会重新加载。有么有办法让dalvik强制重新加载？
这个需求的原因是因为： android系统有些自带类会有各种限制，所以我想通过写一个和系统某个类同包名同类名的类，然后让dalvik加载我的这个类，从而突破某些限制。
博主有没有什么思路？  回复  更多评论   

# re: Android类动态加载技术 2013-01-23 14:45 菜鸟1234

不是很明白，既然有最后解密的过程，自然就可以找到解密的算法和密钥，再怎么动态加载类又有什么用呢？  回复  更多评论   

# re: Android类动态加载技术 2013-05-08 11:28 chuan

说理清晰，thx  回复  更多评论   

# re: Android类动态加载技术 2013-07-05 14:36 卷起铺盖流浪

@briancol
我和你在做同样的事情，如果我想动态替换报名类名都相同的一个类，那么这个类dex加载后会被apk中存在的那个类的实例覆盖，没有实现动态加载的意义，请问你找到解决方法了么？  回复  更多评论