Android系统实现DroidPlugin插件机制

360手机助手使用的 DroidPlugin,它是360手机助手团队在Android系统上实现了一种插件机制。它可以在无需安装、修改的情况下运行APK文件,此机制对改进大型APP的架构,实现多团队协作开发具有一定的好处。

它是一种新的插件机制,一种免安装的运行机制

github地址:https://github.com/DroidPluginTeam/DroidPlugin

参考博客:http://blog.csdn.net/hejjunlin/article/details/52124397

DroidPlugin的的基本原理:

  共享进程:为android提供一个进程运行多个apk的机制,通过API欺骗机制瞒过系统

  占坑:通过预先占坑的方式实现不用在manifest注册,通过一带多的方式实现服务管理

  Hook机制:动态代理实现函数hook,Binder代理绕过部分系统服务限制,IO重定向(先获取原始Object-->Read,然后动态代理Hook Object后-->Write回去,达到瞒天过海的目的)

public abstract class Hook { private boolean mEnable = false;//能否hook protected Context mHostContext;//宿主context,外部传入 protected BaseHookHandle mHookHandles; public void setEnable(boolean enable, boolean reInstallHook) { this.mEnable = enable; } public final void setEnable(boolean enable) { setEnable(enable, false); } public boolean isEnable() { return mEnable; } protected Hook(Context hostContext) { mHostContext = hostContext; mHookHandles = createHookHandle(); } protected abstract BaseHookHandle createHookHandle();//用于子类创建Hook机制 protected abstract void onInstall(ClassLoader classLoader) throws Throwable;//插件安装 protected void onUnInstall(ClassLoader classLoader) throws Throwable {//插件卸载 } } public class HookedMethodHandler {//Hook方法 private static final String TAG = HookedMethodHandler.class.getSimpleName(); protected final Context mHostContext; /** * 调用方法的时候会到AppOpsService进行判断uid(宿主apk)和插件的包名是否匹配,此处是不匹配的 * 此时就可以经过转换欺骗系统让程序认为是宿主apk调过来的(这样的前提就需要宿主把所有的权限都申请了) * 因为系统只会去检测宿主apk * **/ private Object mFakedResult = null;//用于欺骗系统 private boolean mUseFakedResult = false; public HookedMethodHandler(Context hostContext) { this.mHostContext = hostContext; } public synchronized Object doHookInner(Object receiver, Method method, Object[] args) throws Throwable { long b = System.currentTimeMillis(); try { mUseFakedResult = false; mFakedResult = null; boolean suc = beforeInvoke(receiver, method, args); Object invokeResult = null; if (!suc) {//false执行原始方法 invokeResult = method.invoke(receiver, args); } afterInvoke(receiver, method, args, invokeResult); if (mUseFakedResult) {//true返回欺骗结果,false返回正常的调用方法 return mFakedResult; } else { return invokeResult; } } finally { long time = System.currentTimeMillis() - b; if (time > 5) { Log.i(TAG, "doHookInner method(%s.%s) cost %s ms", method.getDeclaringClass().getName(), method.getName(), time); } } } public void setFakedResult(Object fakedResult) { this.mFakedResult = fakedResult; mUseFakedResult = true; } /** * 在某个方法被调用之前执行,如果返回true,则不执行原始的方法,否则执行原始方法 */ protected boolean beforeInvoke(Object receiver, Method method, Object[] args) throws Throwable { return false; } protected void afterInvoke(Object receiver, Method method, Object[] args, Object invokeResult) throws Throwable { } public boolean isFakedResult() { return mUseFakedResult; } public Object getFakedResult() { return mFakedResult; } }

abstract class BinderHook extends Hook implements InvocationHandler { private Object mOldObj; public BinderHook(Context hostContext) { super(hostContext); } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { if (!isEnable()) {//如果不能Hook,执行原方法 return method.invoke(mOldObj, args); } HookedMethodHandler hookedMethodHandler = mHookHandles.getHookedMethodHandler(method); if (hookedMethodHandler != null) { return hookedMethodHandler.doHookInner(mOldObj, method, args); } else { return method.invoke(mOldObj, args); } } catch (InvocationTargetException e) { Throwable cause = e.getTargetException(); if (cause != null && MyProxy.isMethodDeclaredThrowable(method, cause)) { throw cause; } else if (cause != null) { RuntimeException runtimeException = !TextUtils.isEmpty(cause.getMessage()) ? new RuntimeException(cause.getMessage()) : new RuntimeException(); runtimeException.initCause(cause); throw runtimeException; } else { RuntimeException runtimeException = !TextUtils.isEmpty(e.getMessage()) ? new RuntimeException(e.getMessage()) : new RuntimeException(); runtimeException.initCause(e); throw runtimeException; } } catch (IllegalArgumentException e) { try { StringBuilder sb = new StringBuilder(); sb.append(" DROIDPLUGIN{"); if (method != null) { sb.append("method[").append(method.toString()).append("]"); } else { sb.append("method[").append("NULL").append("]"); } if (args != null) { sb.append("args[").append(Arrays.toString(args)).append("]"); } else { sb.append("args[").append("NULL").append("]"); } sb.append("}"); String message = e.getMessage() + sb.toString(); throw new IllegalArgumentException(message, e); } catch (Throwable e1) { throw e; } } catch (Throwable e) { if (MyProxy.isMethodDeclaredThrowable(method, e)) { throw e; } else { RuntimeException runtimeException = !TextUtils.isEmpty(e.getMessage()) ? new RuntimeException(e.getMessage()) : new RuntimeException(); runtimeException.initCause(e); throw runtimeException; } } } abstract Object getOldObj() throws Exception; void setOldObj(Object mOldObj) { this.mOldObj = mOldObj; } public abstract String getServiceName();//具体Hook哪一个service /** * 先调用ServiceManagerCacheBinderHook的onInstall()方法更新一下service cache * 然后生成一个新的代理对象放到mProxiedObjCache里。这样下次不管是从cache里取,还是直接通过binder调用,就都会返回我们的代理对象。 * **/ @Override protected void onInstall(ClassLoader classLoader) throws Throwable { new ServiceManagerCacheBinderHook(mHostContext, getServiceName()).onInstall(classLoader); mOldObj = getOldObj(); Class<?> clazz = mOldObj.getClass();//得到class List<Class<?>> interfaces = Utils.getAllInterfaces(clazz); Class[] ifs = interfaces != null && interfaces.size() > 0 ? interfaces.toArray(new Class[interfaces.size()]) : new Class[0]; //用原始对象的classloader传入动态代理,得到代理对象 Object proxiedObj = MyProxy.newProxyInstance(clazz.getClassLoader(), ifs, this); MyServiceManager.addProxiedObj(getServiceName(), proxiedObj); } }

结论就是读取插件apk,和宿主的uid对比,然后进行包替换,在利用binder代理Hook,启动插件,这概括很是大概,不过涉及太复杂

然后是使用了,结束和使用都很多资料,很详细,不过自己研究了一翻记录下心得,也能加深理解和印象

public class MainActivity extends AppCompatActivity { private String filepath = null, packageName = "cn.liuzhen.plugin"; private TextView tv_val; private Context context; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); context = MainActivity.this; tv_val = (TextView)findViewById(R.id.tv_val); filepath = Environment.getExternalStorageDirectory().getAbsolutePath().concat("/test.apk"); } public void click(View view) { if (filepath == null){ Toast.makeText(context,"filepath is null",Toast.LENGTH_SHORT).show(); return; } String result = null; int code = -1; try { switch (view.getId()) { case R.id.btn_install: code = PluginManager.getInstance().installPackage(filepath, PackageManagerCompat.INSTALL_REPLACE_EXISTING); result = "install"; switch (code) { case PluginManager.INSTALL_FAILED_NO_REQUESTEDPERMISSION: result = "安装失败,文件请求的权限太多"; break; case PackageManagerCompat.INSTALL_FAILED_NOT_SUPPORT_ABI: result = "宿主不支持插件的abi环境,可能宿主运行时为64位,但插件只支持32位"; break; case PackageManagerCompat.INSTALL_SUCCEEDED: result = "安装完成"; break; } break; case R.id.btn_del: PluginManager.getInstance().deletePackage(packageName, 0); result = "del"; break; case R.id.btn_open: PackageManager pm = getPackageManager(); Intent intent = pm.getLaunchIntentForPackage("cn.liuzhen.plugin"); if (intent == null){ result = "intent is null"; }else startActivity(intent); break; } } catch (RemoteException e) { result = "安装失败 "+e.getMessage(); } tv_val.setText(result); } }

运行程序成功,然后把运行的apk复制一份,我上面的名称是写死的,test.apk,然后放在根目录,点击安装,显示成功后在点击打开,就能见到跳转到插件界面了,插件化通了。

接下来就是看自己怎么设计和开发了,什么东西也不能随便使用,得好好考虑,个人觉得插件化不宜大范围使用,适合小菜单的集成,毕竟都是反射的,而且还得考虑好安全问题。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

时间: 2024-09-27 12:21:29

Android系统实现DroidPlugin插件机制的相关文章

详细分析Android中onTouch事件传递机制_Android

onTach介绍 ontach是Android系统中整个事件机制的基础.Android中的其他事件,如onClick.onLongClick等都是以onTach为基础的. onTach包括从手指按下到离开手机屏幕的整个过程,在微观形式上,具体表现为action_down.action_move和action_up等过程. onTach两种主要定义形式如下: 1.在自定义控件中,常见的有重写onTouchEvent(MotionEvent ev)方法.如在开发中经常可以看到重写的onTouchEv

Android数据持久化之ContentProvider机制详解

本文实例讲述了Android数据持久化之ContentProvider机制.分享给大家供大家参考,具体如下: 一般而言,android操作系统的应用程序所建立的数据只允许自己使用,应用程序彼此间无法借助公用存储器来共享数据,android系统提供了一个机制,即内容提供器(ContentProvider),来公开自己私有的数据到数据内容器,通过该机制,可以供其他应用程序来读取自己内部的数据,当然也可以访问其他应用程序的数据.通常,内容提供器背后都有SQLite数据库的支持,用以存储内容提供内部数据

浅谈Android系统的基本体系结构与内存管理优化

Android运行环境一览 Android基于linux内核,面向移动终端的操作系统.主要包括以下几个方面: Application Framework: 这一层为应用开发者提供了丰富的应用编程接口,如 Activity Manager,Content Provider,Notification Manager,以及各种窗口 Widget 资源等.所有的APP都是运行在这一层之上. Dalvik 虚拟机: Dalvik VM采用寄存器架构,而不是JVM的栈架构,更适于移动设备.java源代码经过

详细分析Android中onTouch事件传递机制

onTach介绍 ontach是Android系统中整个事件机制的基础.Android中的其他事件,如onClick.onLongClick等都是以onTach为基础的. onTach包括从手指按下到离开手机屏幕的整个过程,在微观形式上,具体表现为action_down.action_move和action_up等过程. onTach两种主要定义形式如下: 1.在自定义控件中,常见的有重写onTouchEvent(MotionEvent ev)方法.如在开发中经常可以看到重写的onTouchEv

Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析_Android

        在前面几篇文章中,我们详细介绍了Android系统进程间通信机制Binder的原理,并且深入分析了系统提供的Binder运行库和驱动程序的源代码.细心的读者会发现,这几篇文章分析的Binder接口都是基于C/C++语言来实现的,但是我们在编写应用程序都是基于Java语言的,那么,我们如何使用Java语言来使用系统的Binder机制来进行进程间通信呢?这就是本文要介绍的Android系统应用程序框架层的用Java语言来实现的Binder接口了.        熟悉Android系统

Android系统进程间通信(IPC)机制Binder中的Client获得Server远程接口过程源代码分析_Android

     在上一篇文章中,我们分析了Android系统进程间通信机制Binder中的Server在启动过程使用Service Manager的addService接口把自己添加到Service Manager守护过程中接受管理.在这一篇文章中,我们将深入到Binder驱动程序源代码去分析Client是如何通过Service Manager的getService接口中来获得Server远程接口的.Client只有获得了Server的远程接口之后,才能进一步调用Server提供的服务.       

Android系统进程间通信(IPC)机制Binder中的Server启动过程源代码分析_Android

        在前面一篇文章Android系统进程间通信(IPC)机制Binder中的Server和Client获得Service Manager接口之路中,介绍了在Android系统中Binder进程间通信机制中的Server角色是如何获得Service Manager远程接口的,即defaultServiceManager函数的实现.Server获得了Service Manager远程接口之后,就要把自己的Service添加到Service Manager中去,然后把自己启动起来,等待Cl

Android系统进程间通信(IPC)机制Binder中的Server和Client获得Service Manager接口之路_Android

        在前面一篇文章浅谈Service Manager成为Android进程间通信(IPC)机制Binder守护进程之路中,介绍了Service Manager是如何成为Binder机制的守护进程的.既然作为守护进程,Service Manager的职责当然就是为Server和Client服务了.那么,Server和Client如何获得Service Manager接口,进而享受它提供的服务呢?本文将简要分析Server和Client获得Service Manager的过程.     

理解Android系统Binder机制_Android

一.Binder机制概述 在Android开发中,很多时候我们需要用到进程间通信,所谓进程间通信,实现进程间通信的机制有很多种,比如说socket.pipe等,Android中进程间通信的方式主要有三种: 1.标准Linux Kernel IPC 接口: 2.标准D-BUS接口: 3.Binder接口. 其中,Binder机制是使用最且最被认可的,因为Binder机制有以下优点: 1.相对于其它IPC机制,Binder机制更加简洁和快速: 2.消耗的内存相对更少: 3.传统的IPC机制可能会增加