1. 程式人生 > >【筆記】AppOpsService 相關

【筆記】AppOpsService 相關

AppOpsService 相關:

1.建構函式:
讀取/data/system/appops.xml 下 許可權相關設定資訊;

2.許可權檢測:
SDK >23 時,呼叫ContextCompat::checkSelfPermission() 就可以檢測是否有許可權。
SDK <23 時,6.0 一下的系統,主要許可權在許可權清單中,都是返回true

3.許可權的讀取/修改:
  1.系統最開始的許可權配置解除安裝AppOpsManager.sOpDefaultMode[] 數組裡;
  2.開機後,PKMS 會生成/data/system/appops.xml ,此檔案儲存 appops 中各個pkg 的許可權配置(注:appops.xml記錄的不是實時的許可權配置,許可權的修改是有延時的)
  3.修改許可權呼叫AppOpsManag.setMode,主要修改的是AppOpsService 維護的一個包含 op 這個單位變數的陣列,各個許可權對應的 op  是實時變化的,但是同步到 appops.xml 上是有時間延時的!!!同步到appops.xml 上是直接將AppOpsService 上所有的op 一次性全部同步到appops.xml 上。
  4.獲取的pkg 對應許可權的狀態是獲取此pkg 對應是op 的狀態,並沒有直接讀取 appops.xml 這個檔案!!!!
  5.AppOpsService 裡的op類 初始化時,op.mode 就是直接獲取AppOpsManager.sOpDefaultMode[]這個數組裡配置的資訊,所以建立了op 後,最後同步到appops.xml 上時就是把sOpDefaultMode[] 陣列的配置資訊寫到appops.xml 裡了。
  6. op類的成員變數uid , packageName ,mode

AppOpsManager 相關:
1.  public int checkOpNoThrow(String op, int uid, String packageName)


2. 陣列:
   0.sOpToSwitch : 【一個int陣列,包含當前AppOps控制的所有許可權對應的 permission number】
   1.sOpToString : 【一個string陣列,包含當前AppOps控制的所有許可權對應的正式string 型別名稱,類似“android:read_contacts”,用於在AndroidManifest中做對應】
   2.sOpNames :    【一個string陣列,包含當前AppOps控制的所有許可權對應的程式碼裡代稱的string型別名稱,類似“READ_EXTERNAL_STORAGE”】
   3.sOpPerms :    【一個string陣列,包含當前AppOps控制的所有許可權對應的AndroidManifest.xml中標記的名稱,類似Manifest.permission.READ_EXTERNAL_STORAGE】
   4.sOpRestrictions : 【一個string陣列,記錄當前各個許可權對應的UserRestriction配置:UserManager 的多使用者功能中,會有一個User 建立時預設的各種操作對應的允許/不允許 配置,某一種操作是在UserManager 上定義的,但是UserManager上定義的一種操作實際上包含AppOpsManager上多個許可權,這個陣列就是把UserManager 上定義的操作 和 AppOpsManager 上定義的許可權對應起來】
   4.sOpDefaultMode :【一個int陣列,包含當前AppOps控制的所有許可權預設的MODE_ALLOWED "0"/MODE_IGNORED "1"/MODE_ERRORED "2"/MODE_DEFAULT "3"/ MODE_NOTED "4"】

3.AppOpsManager.opToDefaultMode(op.getOp()) 獲取此許可權default 的allow/disallow 狀態
  
  
  
4.在6.0引入動態許可權之後,許可權被分為了一般許可權和危險許可權。一般許可權只要在清單檔案中註冊可使用,危險許可權可以通過動態獲取來獲得(比如獲取聯絡人)

5.Android 8 之前都是安裝未知來源應用的時候一般會彈出一個彈窗讓使用者去設定允許還是拒絕,並且設定為允許之後,所有的未知來源的應用都可以被安裝。Android8.0的變化是,未知應用安裝許可權的開關被除掉,取而代之的是未知來源應用的管理列表,需要在裡面開啟每個應用的未知來源的安裝許可權。Google這麼做是為了防止一開始正經的應用後來開始通過升級來做一些不合法的事情,侵犯使用者權益。

修改許可權:

1.AppOpsManage.setMode(int code, int uid, String packageName, int mode)
  --> AppOpsService.setMode(int code, int uid, String packageName, int mode)
      ... code = AppOpsManager.opToSwitch(code); 【獲取程式碼裡寫的許可權對應的op_num】
      ... Op op = getOpLocked(code, uid, packageName, true); 【獲取/生成 許可權對應的 op 成員變數,FW層裡許可權的處理單位】
      ... cbs = mPackageModeWatchers.get(packageName); 【註冊此pkg 許可權的監聽回撥】
          -->scheduleFastWriteLocked()
             ... mHandler.postDelayed(mWriteRunner, 10*1000); 【延時10s 後開始向 /data/system/appops.xml 中修改許可權配置】
         (或者)*** scheduleWriteLocked()
             ... mHandler.postDelayed(mWriteRunner, WRITE_DELAY);【WRITE_DELAY= DEBUG ? 1000 : 30*60*1000 ,正常情況是30min 才會修改/data/system/appops.xml 中的許可權配置資訊】
        

*************************************************************************************************
問題1:/data/system/appops.xml 檔案中的資訊具體是什麼含義? 和 AppOpsManager 上定義的資料有什麼聯絡?
問題2:UserManager 和AppOps 的關係: UserManager 是使用者操作控制的manager, AppOps是系統許可權的manager,一個使用者的一種操作可能包含多種系統的許可權。
問題3:如何攔截未知來源的APP 的安裝需求?