Creator 版本： 3.8.5
目标平台： android
重现方式：必现
首个报错： 无
之前哪个版本是正常的： 3.8.3
手机型号： android 手机，和 cocos 模拟器
场景说明：
一个主工程，多个子工程，主工程是启动逻辑 用于 构建 主bundle和内置 bundle，其他子工程：构建出 其他 子bundle。
app启动之后，动态更改远端服务器地址，生成manifest。 然后 checkUpdate，检测更新。
之前3.8.3 可以正常热更新，升级3.8.5之后 checkUpdate 没有任何反应，也没有报错信息。
所有工程都已经升级 3.8.5 了。
主工程自己的热资源可以热更新下来，其他的子bundle，由其他工程构建的热更资源无法更新（检测没有任何回调和报错）。
将工程版本再次切回 3.8.3，是可以正常热更新。
没人遇到相同问题？
有解决方案吗 ？
大哥 是不是 走错片场了 ？ 
出bug了,不是回你这个帖的,不知道怎么跳过来了 
会不会是cdn缓存了
就算有缓存了，也应该返回检测结果呀！！
动态的mainfest里面是最新的bundle的版本号是吧？checkupdate拉取的最新mainfest本地查看一下是不是预期的
我们2.4之前遇到过这种情况,apk包获取cdn的mainfest文件是缓存,但是网页下载的是最新的,后面在下载mainfest文件时加上时间戳就行了
所有bundle的热更资源 ，发布构建仍然的3.8.5 版本，只是把安装包退回用 3.8.3 打包，就不会有checkUpdate不返回结果的问题。 这个应该和热更新逻辑没太大问题。
时间戳怎么加啊？
加在哪个地方啊？
我的业务需求是，实例了多个 native.assmanager 并发的发起热更操作 , 然而3.8.5 源码里assmanager 弄了个静态变量，每次 init ，这样导致 最后一次实例会覆盖原来的实例，导致前面发起的就没有后续的更新操作。
把红框的代码删除掉就正常了，不晓得 官方这个做法的用意！！
用我的插件可以磨平 C++ 这部分的差异 
https://store.cocos.com/app/detail/6756
emm… 文字太少好像也不太行
Q：插件是如何磨平的呢？
A：插件的实现，本身不会用到 AssetManager 相关的 jsb 接口，因此也无需关心 AssetManager 这部分相关的 C++ 代码，因此能磨平不同版本 CocosCreator 这部分的实现，用户就不用改这部分的 C++代码
Q：不用 AssetManager ，那你是怎么检查更新、下载之类的？
A：插件是基于更低的 API 做处理的，具体来说，插件只用到 Cocos 提供的 DownloadTask 来下载，其他所有逻辑全部在 ts 端完成，除非 Cocos 的更底层 API DownloadTask 出现问题（这个概率比 AssetManager 更低），否则插件能向后兼容很多个版本
