Shadow

Shadow copied to clipboard

主进程挂了，再次启动应用的时候插件启动不了

1

启动插件后，如果主进程挂了再次启动应用的时候插件启动不了 https://github.com/lidongdong139/Shadow/tree/bundle。 第二次提交

chenlin139

Maven依赖SDK

3

大佬，想问一下怎么把sdk推送到Maven仓库，按照文档操作了一下，没有成功

TA-J

manage和plugin包远程服务下载，校验是否已下载和是否有更新

1

请问下，宿主app动态下载加载manage-project和插件plugin，目前shadow支持判断是否已经下载完manage和plugin包并且判断版本号，是否有新版本需要重新下载？还是说这些判断都是需要我这边自己去写代码做判断。感谢

cq0702

多插件多进程多PPS

11

这都2022年了，shadow官方还是没有对“多插件多进程多PPS”的情况做支持吗？

jxllh123456

多插件的几个疑问

4

需求： 项目中接入多个插件，每个插件支持单独更新，插件由外部提供 问题： 1、由于接入的插件都是外部开发后提供的，项目只提供下载插件和插件交互功能，多个插件的情形下是不是每个插件都要接入loader和runtime模块？这种情况是不是得给每个插件设置一个pps并且设置不同的uuid 2、每个插件支持单独更新的情况下，是不是每个插件都得写个manager模块。能否把manager移植到宿主工程中，将插件的下载和管理放到宿主中，不用单独打成apk

chenlin139

使用maven源码实现多插件启动的问题

11

我用sample下maven作为我的开发源码， 一、将plugin-project复制了一份，作为另外一个插件，然后将里面的partKey 改为 'sample-plugin2'。将包名改为“com.tencent.shadow.sample.plugin2”。打包成zip后再重命名为"plugin2-debug.zip" 二、将manager-project 里面的 samplePluginManager.java中enter函数中复制了一个代码如下： public void enter(final Context context, long fromId, Bundle bundle, final EnterCallback callback) { if (fromId == Constant.FROM_ID_START_ACTIVITY) { bundle.putString(Constant.KEY_PLUGIN_ZIP_PATH, "/data/local/tmp/plugin-debug.zip"); bundle.putString(Constant.KEY_PLUGIN_PART_KEY, "sample-plugin"); bundle.putString(Constant.KEY_ACTIVITY_CLASSNAME,...

pangliang071

我在应用生成测试的时候发现bugly后台有这个偶发的问题，请教一下该怎么去避免呢，这个产生原因是什么呀

7

连接Service超时 ,等待了：10001 com.test.plugin_manager.SamplePluginManager.onLoadClass(SamplePluginManager.java:115)

yexingyun

plugin中无法获取Host中的自定义属性

4

#1000 基于这个场景修改了，API27 为MixResources，但是会遇到其他问题，plugin中获取不到Host的主题属性 case: https://github.com/Tencent/Shadow/commit/81ba5a5ea93f8c415e698d7a22b91399dee0a587 API 27测试失败 API 31测试成功，能够在插件中读取到Host的主题属性

hc1991

接入文档召集(易用性)

20

希望能够加强项目描述,接入指引之类的文档,大片原理看着很爽,但是梳理项目项目做开发或者阅读的时候真的很费劲

yizems

与Tinker使用的问题

1

具体错误： java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: Cannot cast androidx.core.app.CoreComponentFactory to com.tencent.shadow.core.runtime.ShadowAppComponentFactory 分析： Tinker在加载dex时会使用DelegateClassLoader，导致宿主ClassLoader的继承关系变为： PluginClassLoader->DelegateClassLoader->Runtime所在的ClassLoader->PathClassLoader 正常情况下是： PluginClassLoader->PatchClassLoader->Runtime所在的ClassLoader 具体原因为： 正常情况： PluginClassLoader.loadClass中会优先从其specialclassLoader（就是runtime）中加载，正常是无法加载， 因为runtime中没有这个类，就会走PluginClassLoader自己的加载逻辑，加载插件中的AppComponentFactory， 因为插件中的这个类的父类被改成了ShadowAppComponentFactory，从而可以强转 Tinker中的情况： specialClassLoader的parent的PathClassLoader，所以直接加载了宿主的AppCompoentFactory，所以强转失败。 目前想到的是需要修改Runtime的hack点： 1、现有的Runtime的classLoader是默认改为宿主classLoader的parent，tinker这种修改了宿主classLoader就出问题了，应该是要将runtime设为宿主的pathclassLoader的parent，所以要从宿主的classLoader一直往上找到PathClassLoader 2、LoadApkBloc中会将宿主classLoader的parent设为PluginClassLoader的specialClassLoader，在Tinker那种classLoader关系下就会是PathClassLoader,其实也应该是找到PathClassLoader的parent

xiongping