AndFix,全称是Android hot-fix。是阿里开源的1个热补钉框架,允许APP在不重新发布版本的情况下修复线上的bug。支持Android 2.3 到 7.0,并且支持arm 与 X86系统架构的装备。完善支持Dalvik与ART的Runtime,补钉文件是以 .apatch 结尾的文件,并且是立即生效的
项目地址https://github.com/alibaba/AndFix
官方ReadMe
大致修复图
How to Use(官方)
Initialize PatchManager,
`patchManager = new PatchManager(context);
patchManager.init(appversion);//current version`
Load patch,
`patchManager.loadPatch();`
You should load patch as early as possible, generally, in the initialization phase of your application(such as Application.onCreate()).
Add patch,
`patchManager.addPatch(path);//path of the patch file that was downloaded`
When a new patch file has been downloaded, it will become effective immediately
by addPatch
还有1点就是混淆需要注意
`-keep class * extends java.lang.annotation.Annotation
-keepclasseswithmembernames class * {
native <methods>;
}
-keep class com.alipay.euler.andfix.** { *; }
`
如何制作1个apatch呢,阿里在这个开源项目中提供了1个工具https://github.com/alibaba/AndFix/blob/master/tools/apkpatch⑴.0.3.zip
,这里先大致介绍1下原理:通过diff增量比对两个apk改变的地方,在其上通过加上注解标记,生成1个apatch
例如旧的apk为1.apk,新的apk为2.apk, -o表示补钉的输出目录,-k表示keystore, -p表示keystore的密码,-a表示alias, -e表示entry password。
命令输入有点麻烦,可以自己写1个win的脚本
apkpatch -f 2.apk -t 1.apk -o . -k finance.keystore -p finance.tech.netease.com -a android.finance.163.com -e finance.tech.netease.com
这样基本可以照猫画虎折腾热更新了,固然不要忘记添加读写权限
`<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>`
andfix 深入
补钉深入
andfix的核心原理就是方法替换 在通过其apath工具给需要替换的方法加上注解@repleaceMethod,这样在履行时把有bug的方法替换成补钉文件中履行的方法。(在Native 层使用指针替换的方式替换bug的方法,从而到达修复bug的目的),具体进程以下图:
使用虚拟机的JarFile加载的补钉文件,读取PATCH.MF文件得到补钉类名称
使用DexFile读取patch文件的dex文件,获得后根据注解获得补钉方法
获得bug所在的方法
根据注解中获得到的类名和方法,使用ClassLaoder获得到class,然后根据反射得到bug Method,并将其访问属性修改成public
—————————————–java 层————————————————————-
Native 层替换方法
使用JNI来替换bug所在方法对象的属性来修复bug
扼要类之间关系图
修复的具体进程为:
1)我们及时修复好bug以后,我们可以apkpatch工具将两个apk做1次对照,然后找出不同的部份。生成的apatch了文件。若果这个时候,我们把后缀改成zip再解压开,里面有1个dex文件。反编译以后查看1下源码,里面就是被修复的代码所在的类文件,这些更改过的类都加上了1个_CF的后缀,并且变动的方法都被加上了1个叫@MethodReplace的annotation,通过clazz和method指定了需要替换的方法。(后面补钉原理睬说到)
2)客户端得到补钉文件后就会根据annotation来寻觅需要替换的方法。从AndFixManager.fix方法开始,客户端找到对应的需要替换的方法,然后在fix方法的具体实现中调用fixClass方法进行方法替换进程。
3)由JNI层完成方法的替换。fixClass方法遍历补钉class里的方法,在jni层对所需要替换的方法进行逐一替换。(AndfixManager#replaceMethod)
源码解析
遵守使用时4步走:
Step1:初始化PatchManger
`PatchManager patchManager = new PatchManager();`
参阅 patchManager类源码——>AndfixManager 其中包括了Compat兼容性检测类、SecurityChecker安全性检查类
`public AndFixManager(Context context) {
mContext = context;
//判断机型是不是支持Andfix 阿里的YunOs不支持
mSupport = Compat.isSupport();
if (mSupport) {
//初始化签名判断类
mSecurityChecker = new SecurityChecker(mContext);
mOptDir = new File(mContext.getFilesDir(), DIR);
// make directory fail
if (!mOptDir.exists() && !mOptDir.mkdirs()) {
mSupport = false;
Log.e(TAG, "opt dir create error.");
} else if (!mOptDir.isDirectory()) {// not directory
//如果不是目录则删除
mOptDir.delete();
mSupport = false;
}
}
}`
Step2:使用PatchManger检查版本
`patchManager.init(apk版本)`
参阅patchManager#init ——>Patch 构造函数初始化 init
主要是版本比对,记录版本号;根据版本号将patch清除或加载到缓存中
参阅Patch#init
` public void init(String appVersion) {
if (!mPatchDir.exists() && !mPatchDir.mkdirs()) {// make directory fail
Log.e(TAG, "patch dir create error.");
return;
} else if (!mPatchDir.isDirectory()) {// not directory
mPatchDir.delete();
return;
}
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();//初始化patch列表,把本地的patch加载到内存中
}
}
private void initPatchs() {
File[] files = mPatchDir.listFiles();
for (File file : files) {
addPatch(file);
}
}`
Patch文件的加载 使用JarFile读取Patch文件,读取1些属性如patchname,createtime,其中如果本地保存了多个补钉,那末AndFix会依照补钉生成的时间顺序加载补钉。具体是根据.apatch文件中的PATCH.MF的字段Created-Time。
step3:loadPatch
`patchManager.loadPatch();`
参阅patchManager#loadPatch
提供了3个重载方法
`public void loadPatch()//andfix 初始化以后调用
private void loadPatch(Patch patch)//下载补钉完成后调用,addPatch(path)
public void loadPatch(String patchName, ClassLoader classLoader)//提供了自定义类加载器的实现
`
这3个核心都是调用了public synchronized void fix(File file, ClassLoader classLoader, List classes)
参看AndfixManager#fix
`public synchronized void fix(File file, ClassLoader classLoader,
List<String> classes) {
if (!mSupport) {
return;
}
//判断补钉的签名
if (!mSecurityChecker.verifyApk(file)) {// security check fail
return;
}
try {
File optfile = new File(mOptDir, file.getName());
boolean saveFingerprint = true;
if (optfile.exists()) {
// need to verify fingerprint when the optimize file exist,
// prevent someone attack on jailbreak device with
// Vulnerability-Parasyte.
// btw:exaggerated android Vulnerability-Parasyte
// http://secauo.com/Exaggerated-Android-Vulnerability-Parasyte.html
//如果本地已存在补钉文件,则校验指纹信息
if (mSecurityChecker.verifyOpt(optfile)) {
saveFingerprint = false;
} else if (!optfile.delete()) {
return;
}
}
//加载patch文件中的dex
final DexFile dexFile = DexFile.loadDex(file.getAbsolutePath(),
optfile.getAbsolutePath(), Context.MODE_PRIVATE);
if (saveFingerprint) {
mSecurityChecker.saveOptSig(optfile);
}
ClassLoader patchClassLoader = new ClassLoader(classLoader) {
//重写了ClassLoader的findClass方法
@Override
protected Class<?> findClass(String className)
throws ClassNotFoundException {
Class<?> clazz = dexFile.loadClass(className, this);
if (clazz == null
&& className.startsWith("com.alipay.euler.andfix")) {
return Class.forName(className);// annotation注解class
// not found
}
if (clazz == null) {
throw new ClassNotFoundException(className);
}
return clazz;
}
};
Enumeration<String> entrys = dexFile.entries();
Class<?> clazz = null;
while (entrys.hasMoreElements()) {
String entry = entrys.nextElement();
if (classes != null && !classes.contains(entry)) {
continue;// skip, not need fix
}
clazz = dexFile.loadClass(entry, patchClassLoader);//获得有bug的类文件
if (clazz != null) {
fixClass(clazz, classLoader);//核心-
}
}
} catch (IOException e) {
Log.e(TAG, "pacth", e);
}
}`
fix——>fixclass——>replaceMethod——>Andfix#replaceMethod(Method dest,Method src) Native方法
`private void fixClass(Class<?> clazz, ClassLoader classLoader) {
//反射找到clazz中的所有方法
Method[] methods = clazz.getDeclaredMethods();
//MethodReplace的注解
MethodReplace methodReplace;
String clz;
String meth;
for (Method method : methods) {
//遍历所有方法,找到有MethodReplace注解的方法,即需要替换的方法
methodReplace = method.getAnnotation(MethodReplace.class);//获得此方法的注解,有bug的方法生成patch的类中的方法都是有注解的
if (methodReplace == null)
continue;
clz = methodReplace.clazz(); //获得注解中的clazz的值
meth = methodReplace.method(); //获得注解中method的值
if (!isEmpty(clz) && !isEmpty(meth)) {
//找到需要替换的方法后调用replaceMethod替换方法
replaceMethod(classLoader, clz, meth, method);
}
}
}
`
`private void replaceMethod(ClassLoader classLoader, String clz,
String meth, Method method) {
try {
String key = clz + "@" + classLoader.toString();
//根据key查找缓存中的数据,该缓存记录了已被修复过得class
Class<?> clazz = mFixedClass.get(key);
if (clazz == null) {// class not load
//找不到说明该class没有被修复过,则通过类加载器去加载
Class<?> clzz = classLoader.loadClass(clz);
// initialize target class
//通过C层改写accessFlag,把需要替换的类的所有方法(Field)改成了public
clazz = AndFix.initTargetClass(clzz);//初始化target class
}
if (clazz != null) {// initialize class OK
mFixedClass.put(key, clazz);
Method src = clazz.getDeclaredMethod(meth,
method.getParameterTypes()); //根据反射拿到有bug的类的方法
//这里是调用了jni,art和dalvik分别履行不同的替换逻辑,在cpp进行实现
AndFix.addReplaceMethod(src, method);//替换方法 src是有bug的方法,method是补钉方法
}
} catch (Exception e) {
Log.e(TAG, "replaceMethod", e);
}
}`
Natvie方法的分析
见下面
前3步都是1开始初始化时候要做的,而最后1步第4步则是补钉下载好以后再做的
step4: 添加Patch
`patchManager.addPatch(path)`
参阅PatchManager#addPatch,终究还是履行loadpatch
appPatch——>copy到andfix默许的文件夹下——>履行loadPatch(补钉立即生效)
` public void addPatch(String path) throws IOException {
File src = new File(path);
File dest = new File(mPatchDir, src.getName());
if(!src.exists()){
throw new FileNotFoundException(path);
}
if (dest.exists()) {
Log.d(TAG, "patch [" + path + "] has be loaded.");
return;
}
//这1步很重要,通过这1步将你所下载保存的patch文件,copy到andfix自己默许的文件夹内存的data/data/apatch
FileUtil.copyFile(src, dest);// copy to patch's directory
Patch patch = addPatch(dest);
if (patch != null) {
//加载patch 补钉立即生效
loadPatch(patch);
}
}`
小结1下:
可以看出andfix的核心就是两大步
- java层 实现加载补钉文件,安全验证等操作,然后根据补钉汇总的注解找到将要替换的方法,交给Native层去处理替换方法
- native层:利用java hook的技术来替换要修复的方法
在JNI目录下 art和darvik文件中
andfix.cpp#replaceMethod——>art_method_replace.cpp(根据版本)——art_method_replace_5_0.cpp
Dalvik
Dalvik是Google公司自己设计用于Android平台的Java虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动装备平台的核心组成部份之1。它可以支持已转换为 .dex(即Dalvik Executable)格式的Java利用程序的运行,.dex格式是专为Dalvik设计的1种紧缩格式,合适内存和处理器速度有限的系统。Dalvik 经过优化,允许在有限的内存中同时运行多个虚拟机的实例,并且每个Dalvik 利用作为1个独立的Linux 进程履行。独立的进程可以避免在虚拟机崩溃的时候所有程序都被关闭。
ART
Android操作系统已成熟,Google的Android团队开始将注意力转向1些底层组件,其中之1是负责利用程序运行的Dalvik运行时。Google开发者已花了两年时间开发更快履行效力更高更省电的替换ART运行时。 ART代表Android Runtime,其处理利用程序履行的方式完全不同于Dalvik,Dalvik是依托1个Just-In-Time (JIT)编译器去解释字节码。开发者编译后的利用代码需要通过1个解释器在用户的装备上运行,这1机制其实不高效,但让利用能更容易在不同硬件和架构上运 行。ART则完全改变了这套做法,在利用安装时就预编译字节码到机器语言,这1机制叫Ahead-Of-Time (AOT)编译。在移除解释代码这1进程后,利用程序履行将更有效力,启动更快。
-优缺点
ART优点:
1、系统性能的显著提升。
2、利用启动更快、运行更快、体验更流畅、触感反馈更及时。
3、更长的电池续航能力。
4、支持更低的硬件。
ART缺点:
1、更大的存储空间占用,可能会增加10%⑵0%。
2、更长的利用安装时间。
总的来讲ART的功效就是“空间换时间”。
其他重要函数
PatchManage#removeAllPatch()
这个函数是在PatchManage#init(viersin) verision不同时调用的方法1样,清空补钉目录文件,这在做保护的时候10分重要。
` public void removeAllPatch() {
cleanPatch();
SharedPreferences sp = mContext.getSharedPreferences(SP_NAME,
Context.MODE_PRIVATE);
sp.edit().clear().commit();
}`
比如在laodPatch,包括初始化的时候patchManager.loadPatch()和patchManager.addPatch(其实也是调用loadpath)
`public void loadPatch() {
mLoaders.put("*", mContext.getClassLoader());// wildcard
Set<String> patchNames;
List<String> classes;
for (Patch patch : mPatchs) {
patchNames = patch.getPatchNames();
for (String patchName : patchNames) {
classes = patch.getClasses(patchName);//获得patch对用的class类集合
mAndFixManager.fix(patch.getFile(), mContext.getClassLoader(),
classes);//核心-修复bug方法
}
}
}`
因此需要在以下两处做好保护
`public void starAndfix() {
try {
mPatchManager = new PatchManager(context);
mPatchManager.init(BuildConfig.VERSION_NAME);//更换版本号,补钉会被清除
AppLog.d(TAG, "inited.");
mPatchManager.loadPatch();
……
requestHotFixServer(lastSign);
} catch (Throwable throwable) {
mPatchManager.removeAllPatch();
AppLog.d(TAG, "outer catch error remove apatch");
}
}`
` try{
mPatchManager.addPatch(context.getFilesDir() + "/" + DIR + APATCH_PATH);
}catch (Throwable throwable){
mPatchManager.removeAllPatch();
AppLog.d(TAG, "inner catch error remove apatch");
}`
apkpatch是1个jar包,并没有开源出来,我们可使用JD-GUI来查看其源码。首先找到Main.class 位于com.euler.patch包下,找到main方法 Main#97
`public static void main(final String[] args) {
.....
//根据上面命令输入拿到参数
ApkPatch apkPatch = new ApkPatch(from, to, name, out, keystore, password, alias, entry);
apkPatch.doPatch();
}`
——>ApkPatch#doPatch
` public void doPatch() {
try {
//生成smail文件夹
File smaliDir = new File(this.out, "smali");
if (!smaliDir.exists())
smaliDir.mkdir();
try
{
FileUtils.cleanDirectory(smaliDir);
} catch (IOException e) {
throw new RuntimeException(e);
}
//新建diff.dex文件
File dexFile = new File(this.out, "diff.dex");
if ((dexFile.exists()) && (!dexFile.delete())) {
throw new RuntimeException("diff.dex can't be removed.");
}
//新建diff.apatch文件
File outFile = new File(this.out, "diff.apatch");
if ((outFile.exists()) && (!outFile.delete())) {
throw new RuntimeException("diff.apatch can't be removed.");
}
//第1步:拿到两个apk文件对照,对照信息写入DiffInfo
DiffInfo info = new DexDiffer().diff(this.from, this.to);
//第2步:将对照结果info写入.smail文件中,然后打包成dex文件
this.classes = buildCode(smaliDir, dexFile, info);
//第3步:将生成的dex文件写入jar包,并根据输入的签名信息进行签名生成diff.apatch文件
build(outFile, dexFile);
//第4步:将diff.apatch文件重命名
release(this.out, dexFile, outFile);
} catch (Exception e) {
e.printStackTrace();
}
}`
代码翻译1下:
主要的就是对照文件信息的DexDiffer().diff(this.from, this.to)方法
——>diff#DexDiffer#diff
`public DiffInfo diff(File newFile, File oldFile)
throws IOException
{
//提取新apk的dex文件
DexBackedDexFile newDexFile = DexFileFactory.loadDexFile(newFile, 19,
true);
//提取旧apk的dex文件
DexBackedDexFile oldDexFile = DexFileFactory.loadDexFile(oldFile, 19,
true);
DiffInfo info = DiffInfo.getInstance();
boolean contains = false;
for (DexBackedClassDef newClazz : newDexFile.getClasses()) {
Set oldclasses = oldDexFile
.getClasses();
for (DexBackedClassDef oldClazz : oldclasses) {
//对照相同的方法,存储为修改的方法
if (newClazz.equals(oldClazz)) {
//对照class文件的变量
compareField(newClazz, oldClazz, info);
//对照class的方法,如果同1个类中没有相同的方法,则判断为新增方法(后面方法)
compareMethod(newClazz, oldClazz, info);
contains = true;
break;
}
}
if (!contains)
{
info.addAddedClasses(newClazz);
}
}
return info;
}`
从这段代码可以看出dex diff得到两个apk文件的差别信息,变量和方法
变量
`public void addAddedFields(DexBackedField field) {
this.addedFields.add(field);
throw new RuntimeException("can,t add new Field:" +
field.getName() + "(" + field.getType() + "), " + "in class :" +
field.getDefiningClass());
}
public void addModifiedFields(DexBackedField field) {
this.modifiedFields.add(field);
throw new RuntimeException("can,t modified Field:" +
field.getName() + "(" + field.getType() + "), " + "in class :" +
field.getDefiningClass());
}
`
可以看出不支持增加成员变量,也不支持修改成员变量。
方法
`public void addAddedMethods(DexBackedMethod method) {
System.out.println("add new Method:" + method.getReturnType() +
" " + method.getName() + "(" +
Formater.formatStringList(method.getParameterTypes()) +
") in Class:" + method.getDefiningClass());
this.addedMethods.add(method);
if (!this.modifiedClasses.contains(method.classDef))
this.modifiedClasses.add(method.classDef);
}
public void addModifiedMethods(DexBackedMethod method) {
System.out.println("add modified Method:" + method.getReturnType() +
" " + method.getName() + "(" +
Formater.formatStringList(method.getParameterTypes()) +
") in Class:" + method.getDefiningClass());
this.modifiedMethods.add(method);
if (!this.modifiedClasses.contains(method.classDef))
this.modifiedClasses.add(method.classDef);
}
}`
可以看出对照方法进程中对照两个dex文件中同时存在的方法,如果方法实现不同则存储为修改过的方法;如果方法名不同,存储为新增的方法,也就是说AndFix支持增加新的方法
最后还有1点需要注意下:
在diff#DexDiffer#diff中
//提取新apk的dex文件
DexBackedDexFile newDexFile = DexFileFactory.loadDexFile(newFile, 19, true);
——>org#jf#dexlib2#DexFileFactory
`public static DexBackedDexFile loadDexFile(String path, int api, boolean experimental)
throws IOException
{
return loadDexFile(new File(path), "classes.dex", new Opcodes(api, experimental));
}`
可以看出只提取出了classes.dex这个文件,所以其实不支持multidex,如果使用了multidex方案,并且修复的类不在同1个dex文件中,那末补钉就不会生效。
当时在研究热更新时出现了使用release包加壳后的补钉不能使,为了更好地研究生成的补钉的使用,需要进1步研究1下生成的补钉具体是甚么。
工具: jadx
使用参考:https://liuzhichao.com/2016/jadx-decompiler.html
将加壳前和加壳后生成的补钉,后缀改成zip,得到noshell.out.zip和shell.out.zip,解压后2者都是由两部份组成
通过jadx查看 未加壳生成的补钉dex文件
可以清楚看到加注解的方法,注解当中写了clazz和method的值,对应着apk包中的类名和方法名称;然后就是前后替换的地方
而当用jadx查看加壳后引发1场的补钉时候,
可以看出,加壳以后两个apk根本没法通过diff正确生成补钉,初步推断应当是加壳引入更大的混淆,是的前后两个apk根本没法通过增量比对判断变化,这类error补钉后补钉加入以后会引发 java.lang.VerifyError
因此做好异常保护10分重要
优点
1)可以屡次打补钉。如果本地保存了多个补钉,那末AndFix会依照补钉生成的时间顺序加载补钉。具体是根据.apatch文件中的PATCH.MF的字段Created-Time。
2)安全性
readme提示开发者需要验证下载过来的apatch文件的签名是不是就是在使用apkpatch工具时使用的签名,如果不验证那末任何人都可以制作自己的apatch文件来对你的APP进行修改。 但是我看到AndFix已做了验证,如果补钉文件的证书和当前apk的证书不是同1个的话,就不能加载补钉。 官网还有1条,提示需要验证optimize file的指纹,应当是为了避免有人替换掉本地保存的补钉文件,所以要验证MD5码,但是SecurityChecker类里面也已做了这个工作。。但是这个MD5码是保存在sharedpreference里面,如果手机已root那末还是可以被访问的。
3)不需要重启APP便可利用补钉。
缺点
1)不支持YunOS
2)没法添加新类和新的字段
3)需要使用加固前的apk制作补钉,但是补钉文件很容易被反编译,也就是修改过的类源码容易泄漏
4)使用加固平台可能会使热补钉功能失效
5)没法添加类和字段
6)如果使用了multidex方案,并且修复的类不在同1个dex文件中,那末补钉就不会生效。
andfix热补钉的原理就是,通过加载差分补钉,把需要替换的方法注入到native层,然后通过替换新老方法的函数指针,从而到达bug修复的目的,但是由于Andfix是动态的跳过了类的初始化,所以对静态方法,静态成员变量,构造方法,是不能处理的,而且也不支持新增成员变量和修改成员变量。