Qihoo360/RePlugin 局限和未来大计划 未来很快将支持的 近期明确不支持的

RePlugin可以支持绝大部分“单品”开发时的特性,包括常用的Activity中的LaunchMode、Task-Affinity、Theme(透明和非透明),Service、Provider、Receiver,以及android:process的支持等等,同时也支持“主程序加固”等。

然而,仍然有一些功能,是目前RePlugin所不能支持的。有些是“至少近期内明确不支持的”,也有一些是“未来可以支持的”。

以下将分别做说明。

未来很快将支持的

以下是各App接入方提出的一些,我们认为有必要在未来几个版本支持的特性。因为现在还不支持,为了“不坑大家”,故在此列出来,但将来版本支持后将“去掉”这些限制。

Application和主程序相关

交互

  • 暂不支持“宿主和插件之间直接调用类和方法”(宿主和主程序形成父子类ClassLoader)方案
    • 建议:采用经过验证的“反射”、Binder等方式,可做到“天然的”版本控制。同时,近期会推出“稳定共享代码”方案(和业界做法不是很一样),敬请期待。
    • 原因:这是RePlugin的性质所决定的。也即——尽可能的稳定,不要有直接调用带来的问题。因篇幅所限,请点击此处阅读《FAQ》了解这块儿的更多内容。

近期明确不支持的

注意:这里列出的限制中,有些是出于系统原因,不仅RePlugin,而是各插件化方案都不能很好的支持。而非“仅RePlugin不支持”,特此说明。谢谢您的理解!

如果您有一个能“破除限制”的点子,且对稳定无影响(0 Hook),欢迎随时和我们联系,并提出您的PR。感谢!

Application和主程序相关

  • 插件权限声明无效,只认主程序的
    • 建议:将真正需要用到的权限提前在“主程序”中声明好。
    • 原因:权限部分是系统在安装主程序时,会读取其AndroidManifest.xml中的权限部分,并放入系统的package.xml中,除了系统自己的核心应用(和Root)以外,外界根本无法修改。目前已知的插件化、热更新方案均不支持“动态权限的增删改”。

抛开技术细节不谈,其实我非常赞同新权限必须走“主程序升级”,这样可以保证Android生态的健康发展,且能让插件化方案能“走的更稳一些”。

  • 插件声明Target SDK无效,只认主程序的

    • 建议:根据需要来调整主程序的Target SDK,同时插件和主程序最好同时调整。这样即便插件变成单品,也能做到“天然的适配”。
    • 原因同上,不赘述
  • 不支持“双开应用”功能。也即:“不经修改,直接将任意APK放入RePlugin进行‘免安装运行’”

    • 建议:RePlugin的核心诉求是在“稳定(1 Hook,0 Binder Hook)的前提下”,尽可能保持灵活,且以最小的成本,产生更多的插件,而非“免修改APK直接运行”
    • 如确实需要开发双开、免安装应用,或公司接入的插件均“只提供APK(不含混淆后的AAR)”的,可使用我们360的另一套成熟的框架:DroidPlugin,或 @Lody 罗迪的 VirtualApp
    • 原理:要想实现这种效果,必须先Hook AMS、PackageManager,甚至还要做很多Native Hook的工作。Hook点会很多,也会有不少的适配工作。但只要Hook齐了,就能让一个应用“直接运行起来”,但代价是“适配量太大”,对未来新增的机型充满了“未知性”。

值得说明的是,360手机卫士的另一项作品:“360分身大师”就是自研了一套这样的双开方案,虽然有大量的Hook,但其双开效果还是非常不错的。

此外,如需了解RePlugin的使命,欢迎查看我们的README文档

  • 不支持Notification的Layout资源
    • 建议:可在主程序中预埋一些Layout模板,插件可以套用此模板。另外,“图片资源”以及文案等,是可以通过Drawable和String来透传的,是完美支持的。
    • 原因:RemoteViews的性质决定的。

Activity

  • overridePendingTransition,仅支持使用宿主和系统的
    • 建议:将动画资源“预埋在主程序里”,且确保其ID为固定(利用public.xml),这样可以通过拿主程序的动画ID来传递给系统,实现相应效果。目前手机卫士等产品都是这样做的,效果不错。
    • 原因:此方法仅会传给AMS两个int值,且由AMS层进行资源解析并实现动画效果,根本到不了客户端。目前市面上所有插件化、热更新方案均无法实现此功能。

交互

  • 不支持“宿主和主程序无缝使用资源”(共享资源)方案

    • 建议:采用更稳定的一些API来“迂回的”获取资源。顺便说一句,RePlugin支持“共享View”方案(例如公共UI库的使用等),这样“无缝获取资源”的场景,在其它方面也能得到满足。
    • 原因:这是RePlugin的性质所决定的。也即——尽可能的稳定,不要有适配代码。因篇幅所限,请点击此处阅读《FAQ》了解这块儿的更多内容。
  • 不支持“主程序退出后”的静态广播

    • 建议:请尽量避免过分依赖“主程序停止后”的“静态广播”(Android 8.0以上更是如此,因为原生就禁用了)。此外,只要常驻进程存在,则静态广播将一直生效。
    • 原因:毕竟是“模拟的”静态广播,本质上仍是“动态注册广播”。这和系统直接唤起应广播所在进程,然后发送的“静态广播”是不一样的。

Android 8.0起,一旦应用退出(或被回收),则隐式广播将不再生效,也就是此限制将不再有用。此外,该行为和RePlugin无关,是系统默认行为。详细请参见《Android O 行为变更》部分

过去不支持,但现在已经支持的

  • 暂不支持“同版本覆盖”

已在 RePlugin 2.1.5版本中解决。