Android热补丁之AndFix原理解析

背景

2015年下半年开源了很多Android热更新的项目,其中大部分是以QQ空间技术团队写的那篇文章为依据写出的基于multidex的热更新框架,包括NuwaHotFixDroidFix等;还有这篇文章的主角,阿里开源的AndFix

在这之前,热补丁框架并没有那么火,原因无非就是要么用起来太重,要么不支持ART。比如携程出品的DynamicAPK,这种框架是为了解决平台级的产品相关业务开发之间的解耦,热补丁只是其附属功能,对于量级没有那么大的项目,没有必要采用这种很重的框架。另外就是基于阿里出品的基于Xposed的AOP框架dexposed,剥离掉Xposed的root部分功能,主要应该与AOP编程、插桩 (如测试、性能监控等)、在线热补丁、SDK hooking等,用起来比较重并且不支持ART
众多的热补丁框架为开发者带来了福利,不用发版本就可以紧急修复线上版本的bug。

这篇文章主要是分析AndFix的实现原理。

AndFix

使用方法

引用

1
2
3
dependencies {
compile 'com.alipay.euler:andfix:0.3.1@aar'
}

初始化

1
2
patchManager = new PatchManager(context);
patchManager.init(appversion);//current version

加载补丁,尽量在ApplicationonCreate方法中使用

1
patchManager.loadPatch();

应用补丁

1
patchManager.addPatch(path);//path of the patch file that was downloaded

项目中提供了一个生成补丁(后缀为.apatch)的工具apkpatch
用法:

1
usage: apkpatch -f <new> -t <old> -o <output> -k <keystore> -p <***> -a <alias> -e <***>
 -a,--alias <alias>     keystore entry alias.
 -e,--epassword <***>   keystore entry password.
 -f,--from <loc>        new Apk file path.
 -k,--keystore <loc>    keystore path.
 -n,--name <name>       patch name.
 -o,--out <dir>         output dir.
 -p,--kpassword <***>   keystore password.
 -t,--to <loc>          old Apk file path.

如下生成补丁文件

1
./apkpatch.sh -f new.apk -t old.apk -o ./ -k ../one.keystore -p *** -a one -e ***

apkPatch工具解析

apkpatch是一个jar包,并没有开源出来,我们可以用JD-GUI或者procyon来看下它的源码,版本1.0.3。
首先找到Main.class,位于com.euler.patch包下,找到Main()方法

1
2
3
4
5
6
public static void main(final String[] args) {
.....
//根据上面命令输入拿到参数
final ApkPatch apkPatch = new ApkPatch(from, to, name, out, keystore, password, alias, entry);
apkPatch.doPatch();
}

ApkPatchdoPatch方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public void doPatch() {
try {
//生成smali文件夹
final File smaliDir = new File(this.out, "smali");
if (!smaliDir.exists()) {
smaliDir.mkdir();
}
//新建diff.dex文件
final File dexFile = new File(this.out, "diff.dex");
//新建diff.apatch文件
final File outFile = new File(this.out, "diff.apatch");
//第一步,拿到两个apk文件对比,对比信息写入DiffInfo
final DiffInfo info = new DexDiffer().diff(this.from, this.to);
//第二步,将对比结果info写入.smali文件中,然后打包成dex文件
this.classes = buildCode(smaliDir, dexFile, info);
//第三步,将生成的dex文件写入jar包,并根据输入的签名信息进行签名,生成diff.apatch文件
this.build(outFile, dexFile);
//第四步,将diff.apatch文件重命名,结束
this.release(this.out, dexFile, outFile);
}
catch (Exception e2) {
e2.printStackTrace();
}
}

以上可以简单描述为两步

  1. 对比apk文件,得到需要的信息
  2. 将结果打包为apatch文件

对比apk文件

DexDiffer().diff()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public DiffInfo diff(final File newFile, final File oldFile) throws IOException {
//提取新apk的dex文件
final DexBackedDexFile newDexFile = DexFileFactory.loadDexFile(newFile, 19, true);
//提取旧apk的dex文件
final DexBackedDexFile oldDexFile = DexFileFactory.loadDexFile(oldFile, 19, true);
final DiffInfo info = DiffInfo.getInstance();
boolean contains = false;
for (final DexBackedClassDef newClazz : newDexFile.getClasses()) {
final Set<? extends DexBackedClassDef> oldclasses = oldDexFile.getClasses();
for (final DexBackedClassDef oldClazz : oldclasses) {
//对比相同的方法,存储为修改的方法
if (newClazz.equals(oldClazz)) {
//对比class文件的变量
this.compareField(newClazz, oldClazz, info);
//对比class文件的方法,如果同一个类中没有相同的方法
//则判定为新增方法
this.compareMethod(newClazz, oldClazz, info);
contains = true;
break;
}
}
if (!contains) {
//否则是新增的类
info.addAddedClasses(newClazz);
}
}
//返回包含diff信息的DiffInfo对象
return info;
}

其原理就是根据 dex diff得到两个apk文件的差别信息。对比方法过程中对比两个dex文件中同时存在的方法,如果方法实现不同则存储为修改过的方法;如果方法名不同,存储为新增的方法,也就是说AndFix支持增加新的方法,这一点已经测试证明。另外,在比较Field的时候有如下代码

1
2
3
4
5
6
7
8
9
10
11
12
13
public void addAddedFields(DexBackedField field) {
addedFields.add(field);
throw new RuntimeException("can,t add new Field:" +
field.getName() + "(" + field.getType() + "), " + "in class :" +
field.getDefiningClass());
}

public void addModifiedFields(DexBackedField field) {
modifiedFields.add(field);
throw new RuntimeException("can,t modified Field:" +
field.getName() + "(" + field.getType() + "), " + "in class :" +
field.getDefiningClass());
}

也就是说AndFix不支持增加成员变量,但是支持在新增方法中增加的局部变量也不支持修改成员变量。已经测试证明这一点。
还有一个地方要注意,就是提取dex文件的地方,在DexFileFactory类中

1
2
3
4
public static DexBackedDexFile loadDexFile(File dexFile, int api, boolean experimental) throws IOException
{

return loadDexFile(dexFile, "classes.dex", new Opcodes(api, experimental));
}

可以看到,只提取出了classes.dex这个文件,所以源生工具并不支持multidex,如果使用了multidex方案,并且修复的类不在同一个dex文件中,那么补丁就不会生效。所以这里并不像作者在issue中提到的支持multidex那样,不过我们可以通过JavaAssist工具修改apkpatch这个jar包,来达到支持multidex的目的,后续我们会讲到。

将对比结果打包

这一步我们重点关注拿到DiffInfo后将其存入smali文件的过程
ApkPatch.buildCode()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
private static Set<String> buildCode(final File smaliDir, final File dexFile, final DiffInfo info) throws IOException, RecognitionException, FileNotFoundException {
final ClassFileNameHandler outFileNameHandler = new ClassFileNameHandler(smaliDir, ".smali");
final ClassFileNameHandler inFileNameHandler = new ClassFileNameHandler(smaliDir, ".smali");
final DexBuilder dexBuilder = DexBuilder.makeDexBuilder();
for (final DexBackedClassDef classDef : list) {
final String className = classDef.getType();
baksmali.disassembleClass(classDef, outFileNameHandler, options);
final File smaliFile = inFileNameHandler.getUniqueFilenameForClass(TypeGenUtil.newType(className));
classes.add(TypeGenUtil.newType(className).substring(1, TypeGenUtil.newType(className).length() - 1).replace('/', '.'));
SmaliMod.assembleSmaliFile(smaliFile, dexBuilder, true, true);
}
dexBuilder.writeTo(new FileDataStore(dexFile));
return classes;
}

将上一步得到的diff信息写入smali文件,并且生成diff.dex文件。smali文件的命名以_CF.smali结尾,并且在修改的地方用自定义的Annotation(MethodReplace)标注,用于在替换之前查找修复的变量或方法,如下。

1
2
3
4
5
6
.method private getUserProfile()V
.locals 2
.annotation runtime Lcom/alipay/euler/andfix/annotation/MethodReplace;
clazz = "com.boohee.account.UserProfileActivity"
method = "getUserProfile"
.end annotation

在打包生成的diff.dex文件中,反编译出来可以看到这段代码

1
2
3
4
5
6
7
8
//生成的注解
@MethodReplace(clazz="com.boohee.account.UserProfileActivity", method="onCreate")
public void onCreate(Bundle paramBundle)
{

super.onCreate(paramBundle);
getUserProfile();
addPatch();
}

然后就是签名,打包,加密的流程,就不具体分析了。注意,apkPatch在生成.apatch补丁文件的时候会加入签名信息,并且会进行加密操作,在应用补丁的时候会验证签名信息是否正确。

打补丁原理

Java层

PatchManager.init()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public void init(String appVersion) {
SharedPreferences sp = mContext.getSharedPreferences(SP_NAME,
Context.MODE_PRIVATE);
String ver = sp.getString(SP_VERSION, null);
//根据版本号加载补丁文件,版本号不同清空缓存目录
if (ver == null || !ver.equalsIgnoreCase(appVersion)) {
cleanPatch();
sp.edit().putString(SP_VERSION, appVersion).commit();
} else {
initPatchs();
}
}

private void initPatchs() {
// 缓存目录data/data/package/file/apatch/会缓存补丁文件
// 即使原目录被删除也可以打补丁
File[] files = mPatchDir.listFiles();
for (File file : files) {
addPatch(file);
}
}

addPatchloadPatch()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public void addPatch(String path) throws IOException {
...
FileUtil.copyFile(src, dest);// copy to patch's directory
Patch patch = addPatch(dest);
if (patch != null) {
loadPatch(patch);
}
}

private void loadPatch(Patch patch) {
Set<String> patchNames = patch.getPatchNames();
ClassLoader cl;
List<String> classes;
for (String patchName : patchNames) {
if (mLoaders.containsKey("*")) {
cl = mContext.getClassLoader();
} else {
cl = mLoaders.get(patchName);
}
if (cl != null) {
classes = patch.getClasses(patchName);
mAndFixManager.fix(patch.getFile(), cl, classes);
}
}
}

再看下AndFixManagerfix()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
...
//省略掉验证签名信息、安全检查的代码,安全方面做得很好
...

private void fixClass(Class<?> clazz, ClassLoader classLoader) {
...
for (Method method : methods) {
//还记得对比过程中生成的Annotation注解吗
//这里通过注解找到需要替换掉的方法
methodReplace = method.getAnnotation(MethodReplace.class);
if (methodReplace == null)
continue;
//标记的类
clz = methodReplace.clazz();
//需要替换的方法
meth = methodReplace.method();
if (!isEmpty(clz) && !isEmpty(meth)) {
//所有找到的方法,循环替换
replaceMethod(classLoader, clz, meth, method);
}
}
}

private static native void replaceMethod(Method dest, Method src);
private static native void setFieldFlag(Field field);

public static void addReplaceMethod(Method src, Method dest) {
try {
replaceMethod(src, dest);
initFields(dest.getDeclaringClass());
} catch (Throwable e) {
Log.e(TAG, "addReplaceMethod", e);
}
}

后面就是调用native层的方法,写在jni中,打包为.so文件供java层调用。

总结一下,java层的功能就是找到补丁文件,根据补丁中的注解找到将要替换的方法然后交给jni层去处理替换方法的操作。好了,继续往下看。

Native层

jni的代码中支持DalvikART,那么这是怎么区分的呢?在AndFixManager的构造方法中有这么一句

1
mSupport = Compat.isSupport();
1
2
3
4
5
6
7
8
9
10
11
12
public static synchronized boolean isSupport() {
if (isChecked)
return isSupport;

isChecked = true;
// not support alibaba's YunOs
//SDK android 2.3 to android 6.0
if (!isYunOS() && AndFix.setup() && isSupportSDKVersion()) {
isSupport = true;
}
return isSupport;
}

AndFix的`setUp()``方法

1
2
3
4
5
6
7
8
9
10
11
12
13
public static boolean setup() {
try {
final String vmVersion = System.getProperty("java.vm.version");
//判断是否是ART
boolean isArt = vmVersion != null && vmVersion.startsWith("2");
int apilevel = Build.VERSION.SDK_INT;
//这里也是native方法
return setup(isArt, apilevel);
} catch (Exception e) {
Log.e(TAG, "setup", e);
return false;
}
}

最后调用setup(isArt, apilevel);native方法,在andfix.cpp中注册jni方法

1
2
3
4
5
6
7
static JNINativeMethod gMethods[] = {
/* name, signature, funcPtr */
{ "setup", "(ZI)Z", (void*) setup },
{ "replaceMethod",
"(Ljava/lang/reflect/Method;Ljava/lang/reflect/Method;)V",(void*) replaceMethod },
{ "setFieldFlag",
"(Ljava/lang/reflect/Field;)V", (void*) setFieldFlag }, };

native实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
static jboolean setup(JNIEnv* env, jclass clazz, jboolean isart,
jint apilevel)
{

isArt = isart;
LOGD("vm is: %s , apilevel is: %i", (isArt ? "art" : "dalvik"),
(int )apilevel);
if (isArt) {
return art_setup(env, (int) apilevel);
} else {
return dalvik_setup(env, (int) apilevel);
}
}

static void replaceMethod(JNIEnv* env, jclass clazz, jobject src,
jobject dest)
{

if (isArt) {
art_replaceMethod(env, src, dest);
} else {
dalvik_replaceMethod(env, src, dest);
}
}

根据上层传过来的isArt判断调用Dalvik还是Art的方法。
Dalvik为例,继续往下分析,代码在dalvik_method_replace.cpp
dalvik_setup方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
extern jboolean __attribute__ ((visibility ("hidden"))) dalvik_setup(
JNIEnv* env, int apilevel) {
jni_env = env;
void* dvm_hand = dlopen("libdvm.so", RTLD_NOW);
if (dvm_hand) {
...
//使用dlsym方法将dvmCallMethod_fnPtr函数指针指向libdvm.so中的 //dvmCallMethod方法,也就是说可以通过调用该函数指针执行其指向的方法
//下面会用到dvmCallMethod_fnPtr
dvmCallMethod_fnPtr = dvm_dlsym(dvm_hand,
apilevel > 10 ?
"_Z13dvmCallMethodP6ThreadPK6MethodP6ObjectP6JValuez" :
"dvmCallMethod");
...
}
}

替换方法的关键在于native层怎么影响内存里的java代码,我们知道java代码里将一个方法声明为native方法时,对此函数的调用就会到native世界里找,AndFix原理就是将一个不是native的方法修改成native方法,然后在native层进行替换,通过dvmCallMethod_fnPtr函数指针来调用libdvm.so中的dvmCallMethod()来加载替换后的新方法,达到替换方法的目的。Jni反射调用java方法时要用到一个jmethodID指针,这个指针在Dalvik里其实就是Method类,通过修改这个类的一些属性就可以实现在运行时将一个方法修改成native方法。

看下dalvik_replaceMethod(env, src, dest);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
extern void __attribute__ ((visibility ("hidden"))) dalvik_replaceMethod(
JNIEnv* env, jobject src, jobject dest) {
jobject clazz = env->CallObjectMethod(dest, jClassMethod);
ClassObject* clz = (ClassObject*) dvmDecodeIndirectRef_fnPtr(
dvmThreadSelf_fnPtr(), clazz);
//设置为初始化完毕
clz->status = CLASS_INITIALIZED;
//meth是将要被替换的方法
Method* meth = (Method*) env->FromReflectedMethod(src);
//target是新的方法
Method* target = (Method*) env->FromReflectedMethod(dest);
LOGD("dalvikMethod: %s", meth->name);

meth->jniArgInfo = 0x80000000;
//修改method的属性,将meth设置为native方法
meth->accessFlags |= ACC_NATIVE;

int argsSize = dvmComputeMethodArgsSize_fnPtr(meth);
if (!dvmIsStaticMethod(meth))
argsSize++;
meth->registersSize = meth->insSize = argsSize;
//将新的方法信息保存到insns
meth->insns = (void*) target;
//绑定桥接函数,java方法的跳转函数
meth->nativeFunc = dalvik_dispatcher;
}

static void dalvik_dispatcher(const u4* args, jvalue* pResult,
const Method* method, void* self)
{


Method* meth = (Method*) method->insns;
meth->accessFlags = meth->accessFlags | ACC_PUBLIC;
if (!dvmIsStaticMethod(meth)) {
Object* thisObj = (Object*) args[0];
ClassObject* tmp = thisObj->clazz;
thisObj->clazz = meth->clazz;
argArray = boxMethodArgs(meth, args + 1);
if (dvmCheckException_fnPtr(self))
goto bail;

dvmCallMethod_fnPtr(self, (Method*) jInvokeMethod,
dvmCreateReflectMethodObject_fnPtr(meth), &result, thisObj,
argArray);

thisObj->clazz = tmp;
} else {
argArray = boxMethodArgs(meth, args);
if (dvmCheckException_fnPtr(self))
goto bail;

dvmCallMethod_fnPtr(self, (Method*) jInvokeMethod,
dvmCreateReflectMethodObject_fnPtr(meth), &result, NULL,
argArray);
}
bail: dvmReleaseTrackedAlloc_fnPtr((Object*) argArray, self);
}

通过dalvik_dispatcher这个跳转函数完成最后的替换工作,到这里就完成了两个方法的替换,有问题的方法就可以被修复后的方法取代。ART的替换方法就不讲了,原理上差别不大。

总结

AndFix热补丁原理就是在native动态替换方法java层的代码,通过native层hook java层的代码。

优点

  • 因为是动态的,所以不需要重启应用就可以生效
  • 支持ART与Dalvik
  • 与multidex方案相比,性能会有所提升(Multi Dex需要修改所有class的class_ispreverified标志位,导致运行时性能有所损失)
  • 支持新增加方法
  • 支持在新增方法中新增局部变量
  • 足够轻量,生成补丁文件简单
  • 安全性够高,验证签名

缺点

  • 因为是动态的,跳过了类的初始化,设置为初始化完毕,所以对于静态方法、静态成员变量、构造方法或者class.forname()的处理可能会有问题
  • 不支持新增成员变量和修改成员变量
  • 官方apkPatch工具不支持multidex,但是可以通过修改工具来达到支持multidex的目的
  • 由于是在native层替换方法,某些缺心眼厂商可能会修改源生关键部分的native层实现,导致可能在某些特定ROM支持不够好

参考

项目地址:AndFix,本文分析版本:AndFix:0.3.1

本文地址 http://w4lle.github.io/2016/03/03/Android热补丁之AndFix原理解析/