最近项目里要做一个桌面小工具，类似360悬浮球清理内存的那个效果。 写下来发现坑好多，所以做个记录。 6.0权限相关知识：https://blog.coding.net/blog/understanding-marshmallow-runtime-permission

注意：以下小米手机系统都是（MUI8，基于6.0.1）！！不同版本的MUI悬浮窗是不一样的 进入设置页面设置这个：

第一个疑问：设置了这个“允许在其他应用上层展示”之后，悬浮窗权限设置并没有给（在权限列表里可以看到）！但是悬浮窗可以显示了！ 上面的这张图里的权限类似于TYPE_TOAST只有显示而没有交互的权限（在6.0的手机上TYPE_TOAST的WindowManager是不需要申请权限的） 而小米手机比较特殊（其他手机待验证），即使是TYPE_TOAST也是需要申请的，申请的方式如下： //参考https://developer.android.com/reference/android/Manifest.permission.html#SYSTEM_ALERT_WINDOW Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION); intent.setData(Uri.parse("package:" + getPackageName())); startActivityForResult(intent, REQUEST_CODE); 验证是否申请成功： onActivityResult方法中： if (Settings.canDrawOverlays(this)) { Logger.i("=====", "onActivityResult granted"); } 注意，申请成功了是可以有交互权限的！ 而魅族手机就更特殊了，这个设置页面根本打不开，也就是说上面那个设置是被禁止了的，只能通过给予悬浮窗权限一条路。 三星 Note 5（6.0.1）测试，同原生手机（即类似于TYPE_TOAST只有显示而没有交互的权限（在6.0的手机上TYPE_TOAST的WindowManager是不需要申请权限的）） 华为荣耀8（6.0）测试，同原生手机（即类似于TYPE_TOAST只有显示而没有交互的权限（在6.0的手机上TYPE_TOAST的WindowManager是不需要申请权限的）） 华为 Nexus 6P（6.0.1）测试，同原生手机（即类似于TYPE_TOAST只有显示而没有交互的权限（在6.0的手机上TYPE_TOAST的WindowManager是不需要申请权限的））

第二个疑问： Manifest.permission.SYSTEM_ALERT_WINDOW 到底是个啥玩意？ 注意看重点

WindowManager addView的时候第二个参数WindowManager.LayoutParams 的type属性为 TYPE_SYSTEM_ALERT,时，才需要Manifest.permission.SYSTEM_ALERT_WINDOW 这个权限

总结：默认情况下Manifest.permission.SYSTEM_ALERT_WINDOW 这个权限是关闭的，需要单独申请。小米手机除外，他是默认打开，但没有毛线用，在获取权限的时候给你个true并不能让你显示悬浮窗，你还是需要去申请“允许在其他应用上层展示”或者悬浮窗的权限。但是怎么检测到小米手机上是否可以正确显示悬浮窗呢？（注意下面的方法需要在api19以上使用） //判断 悬浮窗口权限是否打开 public static boolean getAppOps(Context context) { try { Object object = context.getSystemService("appops"); if (object == null) { return false; } Class localClass = object.getClass(); Class[] arrayOfClass = new Class[3]; arrayOfClass[0] = Integer.TYPE; arrayOfClass[1] = Integer.TYPE; arrayOfClass[2] = String.class; Method method = localClass.getMethod("checkOp", arrayOfClass); if (method == null) { return false; } Object[] arrayOfObject1 = new Object[3]; arrayOfObject1[0] = Integer.valueOf(24); arrayOfObject1[1] = Integer.valueOf(Binder.getCallingUid()); arrayOfObject1[2] = context.getPackageName(); int m = ((Integer) method.invoke(object, arrayOfObject1)).intValue(); return m == AppOpsManager.MODE_ALLOWED; } catch (Exception ex) { } return false; } 参考自：http://blog.csdn.net/mzm489321926/article/details/50542065

第三个疑问：“允许在其他应用上层展示”和悬浮窗的权限这两个区别？ 我的猜测：小米手机上是一样的，原生机器上事做了区分的，前者只是显示，没有交互，后者是可以有交互的。（待验证） 同样待验证的还有魅族的这两个有什么区别，为什么不允许打开“允许在其他应用上层展示”这个设置页面？

1.9待续：（1.10已解决）

第2和第3最开始在6.0的机子上也遇到过，WindowManager是在Service中显示的，因为Service是运行在主进程中的，在app的MainActivity的onBackPressed方法中我杀死了主进程： android.os.Process.killProcess(android.os.Process.myPid()); System.exit(0); 所以Service不在了 WindowManager自然也就不在了 可是我发现将Service运行在主进程中仍然会复现，这是为什么呢？Context!!!

好，基本解决问题。继续测试。 vivo xplay5a app退出或者按home键之后不显示悬浮窗

So,

总结：老老实实检测是否给了悬浮窗权限，没给的话就去设置页面打开，这是最稳妥的方式 https://github.com/xturbofan/settingscompat 使用这个库进行悬浮窗权限检测并跳转到设置页面 但是，设置WindowManager的LayoutParams时，这样 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { floatMenuParams.type = WindowManager.LayoutParams.TYPE_TOAST; } else { floatMenuParams.type = WindowManager.LayoutParams.TYPE_PHONE; } 好，解决。

ps:设置悬浮窗的过程中还有一个比较特殊的地方，windowmanager addView之后更新View中的状态（比如说ImageView更改图片，TextView更改文字）才是有效的 drinkAnim = LayoutInflater.from(context).inflate(R.layout.layout_drink_water, null); ImageView drinkWater = (ImageView) drinkAnim.findViewById(R.id.drink_water); drinkAnim.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { hideDrinkAnim(); } }); //这一句是不起作用的 Glide.with(context).load(R.mipmap.drinkwater).asGif().into(drinkWater); windowManager.addView(drinkAnim, drinkAnimParams); Glide.with(context).load(R.mipmap.drinkwater).asGif().into(drinkWater); ps:这个与悬浮窗有点点关心，但更具体的是本身app的业务逻辑相关，我只是做个记录。 因为悬浮窗显示后是需要有点击处理操作的使用RxBus给Fragment发送消息，然后在接收消息的方法中进行数据库保存，但这时候app都退了，肯定没有接收消息一说了。

Demo地址：https://github.com/xturbofan/LockMyPhone

参考： http://blog.csdn.net/self_study/article/details/52859790 https://www.liaohuqiu.net/cn/posts/android-windows-manager/ http://www.jianshu.com/p/634cd056b90c https://github.com/czy1121/settingscompat