To build a better world !

Android类动态加载技术

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

Android类动态加载技术

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

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

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

类加载机制

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

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

       例如,在使用标准Java虚拟机时,我们经常自定义继承自ClassLoader的类加载器。然后通过defineClass方法来从一个二进制流中加载Class。然而,这在Android里是行不通的,大家就没必要走弯路了。参看源码我们知道,AndroidClassLoaderdefineClass方法具体是调用VMClassLoaderdefineClass本地静态方法。而这个本地方法除了抛出一个“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派生出了两个类:DexClassLoaderPathClassLoader。其中需要特别说明的是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的类加载器,本质上是重载了ClassLoaderfindClass方法。在执行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;

}


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

       DexClassLoaderPathClassLoader其实都是通过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则是通过其静态方法loadDexpath, outpath, 0)得到DexFile对象。这两者的区别在于DexClassLoader需要提供一个可写的outpath路径,用来释放.apk包或者.jar包中的dex文件。换个说法来说,就是PathClassLoader不能主动从zip包中释放出dex,因此只支持直接操作dex格式文件,或者已经安装的apk(因为已经安装的apkcache中存在缓存的dex文件)。而DexClassLoader可以支持.apk.jar.dex文件,并且会在指定的outpath路径释放出dex文件。

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


实际操作

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

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

       加载好类后,通常我们可以通过Java反射机制来使用这个类。但是这样效率相对不高,而且老用反射代码也比较复杂凌乱。更好的做法是定义一个interface,并将这个interface写进容器端。待加载的类,继承自这个interface,并且有一个参数为空的构造函数,以使我们能够通过ClassnewInstance方法产生对象。然后将对象强制转换为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.);在AndroidDalvik源码中我们也能看到RawDexFile的身影(不过没有具体实现)。

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


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

posted on 2011-10-29 21:51 zh.weir 阅读(36225) 评论(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 --xk1411@139.com.  回复  更多评论   

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

@林风

呵呵,其实右上方的公告里有写。zh.weir@gmail.com 。

欢迎交流!  回复  更多评论   

# 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中存在的那个类的实例覆盖,没有实现动态加载的意义,请问你找到解决方法了么?  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

大家好!欢迎光临我的 Android 技术博客!



本博客旨在交流与 Android 操作系统相关的各种技术及信息。

博客内的文章会尽量以开源的形式提供给大家,希望我们能相互交流,共同提高!

有不足之处,请不吝赐教!

我的邮箱:zh.weir@gmail.com
我的新浪微博:@囧虎张建伟

 

导航

<2011年10月>
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

统计

留言簿(18)

随笔分类(24)

随笔档案(18)

文章档案(1)

搜索

最新评论

阅读排行榜

评论排行榜