这样实现的好处是：由于我们要实现一个复杂的Launcher，如果所有的小应用、动画效果都在Launcher中实现，那Launcher会做得很庞大，也不利于后面的升级，通过Launcher的根据需要动态加载某些APK中的Activity，可以很好地解决这个问题。
本来是想通过已有的Widget机制来实现的，但Widget中无法实现一些复杂的动画效果，所以这个方案只能放弃。Launcher中动态加载Activity的原理，可以参考下这个文章：《Android中如何给app widget添加复杂view》，现在主要讲加载Activity遇到的问题，及如何解决此问题。
在Launcher中如果通过如下方式来加载其它APK中的Activity，显示正常：
LocalActivityManager lam = this.getLocalActivityManager();
Intent intent = null;
Window w = null;
View v = null;
intent = new Intent(this, TestActivity2.class);
w = lam.startActivity("TestActivity2", intent);
v = w.getDecorView(); LocalActivityManager lam = this.getLocalActivityManager();
Intent intent = null;
Window w = null;
View v = null;
intent = new Intent("com.example.testa.MainActivity.LOAD_ACTIVITY");
w = lam.startActivity("MainActivity1", intent);
v = w.getDecorView();原文链接： http://www.apkbus.com/blog-67608-39328.html
Android动态加载——加载已安装APK中的类
一、目标 注意：被调用的APK在Android系统中是已经安装的。 从当前APK中调用另外一个已安装APK的字符串、颜色值、图片、布局文件资源以及Activity。
二、实现 2.1 被调用工程 基本沿用上个工程的，添加了被调用的字符串、图片等，所以这里就不贴了，后面有下载工程的链接。 2.2 调用工程代码
[代码]java代码：
public class TestAActivity extends Activity {
/** TestB包名 */
private static final String PACKAGE_TEST_B = "com.nmbb.b";
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
try {
final Context ctxTestB = getTestBContext();
Resources res = ctxTestB.getResources();
// 获取字符串string
String hello = res.getString(getId(res, "string", "hello"));
((TextView) findViewById(R.id.testb_string)).setText(hello);
// 获取图片Drawable
Drawable drawable = res
.getDrawable(getId(res, "drawable", "testb"));
((ImageView) findViewById(R.id.testb_drawable))
.setImageDrawable(drawable);
// 获取颜色值
int color = res.getColor(getId(res, "color", "white"));
((TextView) findViewById(R.id.testb_color))
.setBackgroundColor(color);
// 获取布局文件
View view = getView(ctxTestB, getId(res, "layout", "main"));
LinearLayout layout = (LinearLayout) findViewById(R.id.testb_layout);
layout.addView(view);
// 启动TestB Activity
findViewById(R.id.testb_activity).setOnClickListener(
new OnClickListener() {
@Override
public void onClick(View v) {
try {
@SuppressWarnings("rawtypes")
Class cls = ctxTestB.getClassLoader()
.loadClass("com.nmbb.TestBActivity");
startActivity(new Intent(ctxTestB, cls));
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
});
} catch (NameNotFoundException e) {
e.printStackTrace();
}
}
/**
* 获取资源对应的编号
*
* @param testb
* @param resName
* @param resType
* layout、drawable、string
* @return
*/
private int getId(Resources testb, String resType, String resName) {
return testb.getIdentifier(resName, resType, PACKAGE_TEST_B);
}
/**
* 获取视图
*
* @param ctx
* @param id
* @return
*/
public View getView(Context ctx, int id) {
return ((LayoutInflater) ctx
.getSystemService(Context.LAYOUT_INFLATER_SERVICE)).inflate(id,
null);
}
/**
* 获取TestB的Context
*
* @return
* @throws NameNotFoundException
*/
private Context getTestBContext() throws NameNotFoundException {
return createPackageContext(PACKAGE_TEST_B,
Context.CONTEXT_IGNORE_SECURITY | Context.CONTEXT_INCLUDE_CODE);
}基本原理：通过package获取被调用应用的Context，通过Context获取相应的资源、类。
注意：
a). 网上许多文章是通过当前工程的R.id来调用被调用工程的资源 ，这是错误的，即使不报错那也是凑巧，因为R是自动生成的，两个应用的id是没有办法对应的，所以需要通过getIdentifier来查找。
b). Context.CONTEXT_INCLUDE_CODE一般情况下是不需要加的，如果layout里面包含了自定义控件，就需要加上。注意不能在当前工程强制转换获得这个自定义控件，因为这是在两个ClassLoader中，无法转换。
c). 获取这些资源是不需要shareUserId的。
三、总结
与上篇文章相比，获取资源更加方便，但也存在一些限制：
3.1 被调用的apk必须已经安装，降低用户体验。
3.2 style是无法动态设置的，即使能够取到。
3.3 从目前研究结果来看，被调用工程如果使用自定义控件，会受到比较大的限制，不能强制转换使用（原因前面已经讲过）。
3.4 由于一个工程里面混入了两个Context，比较容易造成混淆，取资源也比较麻烦。这里分享一下批量隐射两个apk id的办法，可以通过反射获取两个apk的R类，一次获取每一个id和值，通过名称一一匹配上，这样就不用手工传入字符串了。
[代码]java代码：
@SuppressWarnings("rawtypes")
private static HashMap<String, Integer> getR(Class cls) throws ClassNotFoundException, InstantiationException, IllegalAccessException {
HashMap<String, Integer> result = new HashMap<String, Integer>();
for (Class r : cls.getClasses()) {
if (!r.getName().endsWith("styleable")) {
Object owner = r.newInstance();
for (Field field : r.getFields()) {
result.put(field.getName(), field.getInt(owner));
}
}
}
return result;
}
Android类动态加载技术
Android类动态加载技术
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虚拟机里，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文件路径及权限管理，另外，在加载完毕类之后，除非出于其他目的否则应该马上删除临时的解密文件。
1126
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
