liaohuqiu / android-uctoast Goto Github PK

vivo y66 6.0.1 会被系统禁用，需要手动引导开启

无效

RT, 建议使用WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE | WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON组合。

Caused by: android.view.WindowManager$BadTokenException: Unable to add window -- window android.view.ViewRootImpl$W@f8fe192 has already been added

我把java的版本改到1.8为什么就不行了啊

你好 Huqiu,

感谢你的这个Demo，我往我的 "AnyCopy"添加了类似的功能。这个App的主要作用就是可以自动保存你任何复制到粘贴板的文本内容，然后提供离线访问，即时搜索等。然后我添加了Undo的功能，因为有些用户可能不想保存某些内容。然而我发现，这个功能在大多数机器上运行的都正常，不要求android.permission.SYSTEM_ALERT_WINDOW权限，也能弹出内容。但是我发现Samsung S3 I9100 的崩溃率是100％。我觉得好奇。于是我下载了genymotion 然后创建了一个Samsung S3 I9100模拟器，再安装UC浏览器，我想通过验证UC浏览器是否正常工作，来确定是我自己集成的方法有问题，还是这个本身就是因为Samsung做了特殊的修改，所以不行。

结果我发现UC浏览器居然能够正常弹出悬浮窗。这让我很是吃惊。我不认为我的代码集成的有问题。于是，我又把UC浏览器请求的权限在手机里过滤了一遍，而且手机的确没有说它请求了android.permission.SYSTEM_ALERT_WINDOW的权限，但是在模拟器里却显示请求了这个权限。

（这个解释可能可以归类为Android 6.0权限重构了，所以不再显示了？）

为了再次确认，我翻译了 UC 的源代码，发现事实上它还是的确继续 请求了 android.permission.SYSTEM_ALERT_WINDOW 这个权限。否则的话，无法保证所有的机器都会运行成功。

所以目前的结论是 在原生Android系统里，可以使用这个方法来规避这个权限，但是很可能某些系统就会有各种坑。

在我的实际生产环境中,TYPE_TOAST有两个非常严重的问题：

1.TYPE_TOAST的点击事件只有在API-18之上才可以生效,这也表示必须是4.4及+的手机才可以使用TYPE_TOAST，否则只能看不能点击(不过中间的一个版本4.0.x上也是可以的，它有FLAG_WATCH_OUTSIDE_TOUCH属性,关于TYPE_TOAST的源代码,google书写很随意,不同SDK版本源码完全不同,折腾-)。
2.在同一个Activity中即有PopupWindow又有TYPE_TOAST的悬浮窗会导致PopupWindow弹出后为全透明,看起来似乎没有效果，其实PopupWindow是已经弹出来的,并可点击.
PopupWindow其实是属于悬浮窗的TYPE_APPLICATION_PANEL，它的值是1000.
TYPE_TOAST的值是2000+5;
不同的悬浮窗层级的堆砌会导致很诡异的问题,存在彼此被覆盖不能正常显示。

我在我的生产环境中测试发现这两个问题会导致很严重的APP使用体验,因此我并不建议为了减少申请一个权限就使用TYPE_TOAST....最后我在实际环境中使用了TYPE_APPLICATION_ATTACHED_DIALOG和TYPE_PHONE...

7、为什么WindowManager.addView TYPE_TOAST不能显示自定义Toast
MIUI取消了对TYPE_TOAST的支持，只能使用zhiandroid.widget.Toast.setView来实现自定义Toast。
用其他方式使用TYPE_TOAST，会报告permission denied for this window type错误，后果取决于应用实现，或者闪退，或者内容无法显示。
这是官方给的解释

MIUI8 上面不显示，UC浏览器也是一样的