最近項目里要做一個桌面小工具，類似360懸浮球清理內(nèi)存的那個效果。
寫下來發(fā)現(xiàn)坑好多，所以做個記錄。
6.0權(quán)限相關(guān)知識：https://blog.coding.net/blog/understanding-marshmallow-runtime-permission

注意：以下小米手機系統(tǒng)都是（MUI8，基于6.0.1）??！不同版本的MUI懸浮窗是不一樣的
進入設(shè)置頁面設(shè)置這個：

截圖.png

第一個疑問：設(shè)置了這個“允許在其他應(yīng)用上層展示”之后，懸浮窗權(quán)限設(shè)置并沒有給（在權(quán)限列表里可以看到）！但是懸浮窗可以顯示了！
上面的這張圖里的權(quán)限類似于TYPE_TOAST只有顯示而沒有交互的權(quán)限（在6.0的手機上TYPE_TOAST的WindowManager是不需要申請權(quán)限的）
而小米手機比較特殊（其他手機待驗證），即使是TYPE_TOAST也是需要申請的，申請的方式如下：
//參考<pre>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);</pre>
驗證是否申請成功：
onActivityResult方法中：
<pre>if (Settings.canDrawOverlays(this)) {
Logger.i("=====", "onActivityResult granted");
}</pre>
注意，申請成功了是可以有交互權(quán)限的！
而魅族手機就更特殊了，這個設(shè)置頁面根本打不開，也就是說上面那個設(shè)置是被禁止了的，只能通過給予懸浮窗權(quán)限一條路。
三星 Note 5（6.0.1）測試，同原生手機（即類似于TYPE_TOAST只有顯示而沒有交互的權(quán)限（在6.0的手機上TYPE_TOAST的WindowManager是不需要申請權(quán)限的））
華為榮耀8（6.0）測試，同原生手機（即類似于TYPE_TOAST只有顯示而沒有交互的權(quán)限（在6.0的手機上TYPE_TOAST的WindowManager是不需要申請權(quán)限的））
華為 Nexus 6P（6.0.1）測試，同原生手機（即類似于TYPE_TOAST只有顯示而沒有交互的權(quán)限（在6.0的手機上TYPE_TOAST的WindowManager是不需要申請權(quán)限的））

第二個疑問：
Manifest.permission.SYSTEM_ALERT_WINDOW 到底是個啥玩意？
注意看重點

WindowManager addView的時候第二個參數(shù)WindowManager.LayoutParams 的type屬性為 TYPE_SYSTEM_ALERT,時，才需要Manifest.permission.SYSTEM_ALERT_WINDOW 這個權(quán)限

總結(jié)：默認情況下Manifest.permission.SYSTEM_ALERT_WINDOW 這個權(quán)限是關(guān)閉的，需要單獨申請。小米手機除外，他是默認打開，但沒有毛線用，在獲取權(quán)限的時候給你個true并不能讓你顯示懸浮窗，你還是需要去申請“允許在其他應(yīng)用上層展示”或者懸浮窗的權(quán)限。但是怎么檢測到小米手機上是否可以正確顯示懸浮窗呢？（注意下面的方法需要在api19以上使用）
<pre>
//判斷 懸浮窗口權(quán)限是否打開
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;
}</pre>
參考自：http://blog.csdn.net/mzm489321926/article/details/50542065

第三個疑問：“允許在其他應(yīng)用上層展示”和懸浮窗的權(quán)限這兩個區(qū)別？
我的猜測：小米手機上是一樣的，原生機器上事做了區(qū)分的，前者只是顯示，沒有交互，后者是可以有交互的。（待驗證）
同樣待驗證的還有魅族的這兩個有什么區(qū)別，為什么不允許打開“允許在其他應(yīng)用上層展示”這個設(shè)置頁面？

1.9待續(xù)：（1.10已解決）

1. 但是現(xiàn)在狀況來了，華為榮耀8 app不在前臺后，小工具點擊事件沒有反應(yīng)了！ 同2，同樣是Context的原因！
   同樣的手機還有魅族U20，原生的6.0系統(tǒng)也是這樣
2. 魅族MX4 home鍵之后 加號就消失了 (4.4的系統(tǒng)，包括小米）
   1.10:今天早上我在測oppo的時候（機型n5117 4.3的系統(tǒng)） 一會可以，一會不可以，每次先crash一次，然后后面就可以了。我真是醉了。然后我覺得思路好像不太對，應(yīng)該不是系統(tǒng)的原因，重新檢查了代碼發(fā)現(xiàn)是Context的原因！要使用applicationContext，不要使用Activity。
3. 5.0和5.1的系統(tǒng)app退出之后加號消失并且再進入會crash 按home鍵不消失同2，同樣是Context的原因！

第2和第3最開始在6.0的機子上也遇到過，WindowManager是在Service中顯示的，因為Service是運行在主進程中的，在app的MainActivity的onBackPressed方法中我殺死了主進程：
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
所以Service不在了 WindowManager自然也就不在了
可是我發(fā)現(xiàn)將Service運行在主進程中仍然會復(fù)現(xiàn)，這是為什么呢？Context!!!

好，基本解決問題。繼續(xù)測試。
vivo xplay5a app退出或者按home鍵之后不顯示懸浮窗

So,

總結(jié)：老老實實檢測是否給了懸浮窗權(quán)限，沒給的話就去設(shè)置頁面打開，這是最穩(wěn)妥的方式
https://github.com/xturbofan/settingscompat 使用這個庫進行懸浮窗權(quán)限檢測并跳轉(zhuǎn)到設(shè)置頁面
但是，設(shè)置WindowManager的LayoutParams時，這樣
<pre>if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
floatMenuParams.type = WindowManager.LayoutParams.TYPE_TOAST;
} else {
floatMenuParams.type = WindowManager.LayoutParams.TYPE_PHONE;
}</pre>
好，解決。

ps:設(shè)置懸浮窗的過程中還有一個比較特殊的地方，windowmanager addView之后更新View中的狀態(tài)（比如說ImageView更改圖片，TextView更改文字）才是有效的
<pre>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);</pre>
ps:這個與懸浮窗有點點關(guān)心，但更具體的是本身app的業(yè)務(wù)邏輯相關(guān)，我只是做個記錄。
因為懸浮窗顯示后是需要有點擊處理操作的使用RxBus給Fragment發(fā)送消息，然后在接收消息的方法中進行數(shù)據(jù)庫保存，但這時候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.itdecent.cn/p/634cd056b90c
https://github.com/czy1121/settingscompat