在執(zhí)行自動化服務(wù)的流程中，我們其實并不希望被用戶的操作中斷流程，所以有什么方法在用戶點擊自動化操作的過程中，避免用戶再次操作呢？那就是開啟一個全局透明的懸浮窗，進行屏蔽觸摸事件。
一、懸浮窗
其實一開始，我是想當(dāng)然的跟以前一樣，開啟一個全屏的透明的懸浮窗，進行遮罩的作用，但是發(fā)現(xiàn)，設(shè)置 Type 為 TYPE_TOAST 或者 TYPE_SYSTEM_ALERT 這樣的懸浮窗某些類型的不同，會導(dǎo)致不單單把用戶的操作屏蔽了，甚至窗口的一些狀態(tài)改變也屏蔽的，導(dǎo)致輔助權(quán)限的 onAccessibilityEvent() 方法不回調(diào)，于是去找官方文檔，查找相關(guān)懸浮窗的 Type 類型設(shè)置。然后被我找到這個屬性值的 Type ：
LayoutParams.TYPE_ACCESSIBILITY_OVERLAY
我們再來看官方解釋：
Windows that are overlaid only by a connected AccessibilityService for interception of user interactions without changing the windows an accessibility service can introspect. In particular, an accessibility service can introspect only windows that a sighted user can interact with which is they can touch these windows or can type into these windows. For example, if there is a full screen accessibility overlay that is touchable, the windows below it will be introspectable by an accessibility service even though they are covered by a touchable window.
雖然官方寫的一大堆，但是我們大概能 get 到里面的意思，其實就是設(shè)置為這個類型的懸浮窗，能夠使輔助功能繼續(xù)響應(yīng)相關(guān)窗口與內(nèi)容的變化。經(jīng)測試，果然設(shè)置這個類型的懸浮窗，可以一方面屏蔽用戶的觸摸事件，另一方繼續(xù)響應(yīng)自動點擊的相關(guān)操作。
public void createFullScreenView(Context context) {
WindowManager windowManager = getWindowManager(context);
if (fullScreenView == null) {
fullScreenView = new FloatWindowFullScreenView(context);
LayoutParams fullScreenParams = new LayoutParams();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
fullScreenParams.type = LayoutParams.TYPE_ACCESSIBILITY_OVERLAY;
} else {
fullScreenParams.type = LayoutParams.TYPE_TOAST;
}
fullScreenParams.format = PixelFormat.TRANSLUCENT;
fullScreenParams.flags |= WindowManager.LayoutParams.FLAG_FULLSCREEN
| WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
| LayoutParams.FLAG_KEEP_SCREEN_ON
| WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL;
fullScreenParams.gravity = Gravity.CENTER;
windowManager.addView(fullScreenView, fullScreenParams);
}
}
值得注意的是，這個屬性是在 android 5.1 之后加入進來，對于之前的版本，經(jīng)測試，使用 Toast 類型，也能執(zhí)行相關(guān)操作，至于為什么 5.1 之后不繼續(xù)使用Toast類型呢，這里面涉及到懸浮窗的開啟問題了，可自行百度懸浮窗的開啟相關(guān)文章。
二、懸浮窗的 Context
我們一般開啟懸浮窗的過程中，Context 的傳遞我們使用的 Service 或者 Activity，不過如果設(shè)置為 TYPE_ACCESSIBILITY_OVERLAY 的懸浮窗，是只能傳入你繼承自 AccessibilityService 的服務(wù)（Context，否則會報 Is Activity Running 這個異常，那如何在這個服務(wù)里面開啟懸浮窗呢？我是使用廣播的形式去開啟的：
// 注冊廣播接聽者
IntentFilter filter = new IntentFilter();
filter.addAction(Const.ACTION_SHOW_COVER_VIEW);
filter.addAction(Const.ACTION_SHOW_SMALL_VIEW);
filter.addAction(Const.ACTION_SET_COVER_VIEW_TIPS);
registerReceiver(mReceiver, filter);
....省略其他代碼
private BroadcastReceiver mReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (action.equals(Const.ACTION_SHOW_COVER_VIEW)) {
if (!FloatWindowManager.getInstance().isFullWindowShowing()) {
FloatWindowManager.getInstance().createFullScreenView(TaskService.this);
}
String toast = intent.getStringExtra(Const.EXTRA_WINDOW_TOAST);
if (!StringUtils.isEmpty(toast)) {
FloatWindowManager.getInstance().showToast(toast);
}
} else if (action.equals(Const.ACTION_SHOW_SMALL_VIEW)) {
if (!FloatWindowManager.getInstance().isSmallWindowShowing()) {
FloatWindowManager.getInstance().createSmallWindow(TaskService.this);
}
}else if (action.equals(Const.ACTION_SET_COVER_VIEW_TIPS)) {
if (FloatWindowManager.getInstance().isFullWindowShowing()) {
FloatWindowManager.getInstance().showTipst(intent.getStringExtra("tips"));
}
}
}
};
三、懸浮窗的實現(xiàn)
在懸浮窗的UI設(shè)計上，我們需要將其設(shè)置為透明背景，這樣對用戶是無感的，整個自動化流程中，其實是相當(dāng)于屏幕有個用戶看不到的“保護罩”在確保著你的自動化業(yè)務(wù)不被“打擾”。在布局上，我們需要實現(xiàn)最外層的根布局的點擊事件，這樣在用戶點擊屏幕的時候，彈窗 Toast 友好提示用戶：自動化業(yè)務(wù)正在執(zhí)行，請停止業(yè)務(wù)才能操作。
同時懸浮窗提供“停止”按鈕，可以終止業(yè)務(wù)并關(guān)閉全屏透明懸浮窗。
四、使用場景
部分軟件需要開啟許多權(quán)限才能保證軟件的正常使用，例如市面上的某鎖屏軟件，他們需要涉及相當(dāng)多的權(quán)限，如果一個個讓用戶去開啟，可能找不到對應(yīng)的權(quán)限怎么開啟，于是他們把這個流程簡化成腳本，只要用戶開啟輔助權(quán)限，則跳轉(zhuǎn)到權(quán)限開啟流程，自動到權(quán)限頁面，把例如：開機自啟動權(quán)限，讀取通知，獲取位置等權(quán)限開啟。當(dāng)然這個過程是被一個界面遮蓋了的，用戶是看不到執(zhí)行了什么操作的（這也暴露android的安全性問題）。
