x

@getActivity 没有的，直接依赖的组件：api 'com.github.getActivity:Toaster:12.3'

> > 小伙子，我看了一下 12.3 版本的代码，ActivityToast 肯定是不会去调用 GlobalToast 的，不信你可以翻源码看一下。 > > 那是bugly自动解析的问题，原始日志如下，调用的是GlobalToast的show，在mShowRunnable中出现的异常 android.view.WindowManager$InvalidDisplayException Unable to add window android.view.ViewRootImpl$W@913e4 -- the specified display can not be found android.view.ViewRootImpl.setView(ViewRootImpl.java:1733) android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:451) android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:325) android.view.WindowManagerImpl.addView(WindowManagerImpl.java:176) i5.i.run(SourceFile:93)...

 被混淆的3行代码分别是：ToastStrategy#ShowToastRunnable -> GlobalToast#show -> ToastImpl#mShowRunnable，是直接依赖的组件，没有进行任何修改

> 小伙子，从你目前提供的信息来分析，加上无法复现，我无法判断这个问题的具体原因，请提供更多的信息，例如：发生崩溃时的日志，复现步骤等等有用的信息。 确实没有明确的复现路径，更大概率是系统的BUG。目前该异常都是出现在Android 14的小米设备上，应该是小米澎湃在特定场景下会出现该问题，是否可以考虑先catch住？如果能更进一步，在出现特殊异常导致悬浮窗显示失败时使用系统toast代替就更好了

两边都有反馈的，但系统进行排查和修复的周期会比较长，甚至可能不修复。由于该问题【已经】在线上出现，有上百台设备受影响，所以希望框架可以先兼容一下。catch并不是为了追求数据好看，而是不希望用户在操作过程中由于toast提示导致应用闪退，数据丢失的体验是非常糟糕的，希望可以采纳。

好的，谢谢

@getActivity 可以考虑单独对 InvalidDisplayException 这个异常处理一下，不用全部catch