局限和未来大计划

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版本中解决。