對客戶端而言，權限隱私可分為權限和隱私兩個大的方面。權限為用戶通過app內彈窗設置或者手機設置內對應app的權限設置方式給予對應app相應的權限，如電話權限，定位權限，相機權限等，本文主要集中介紹隱私相關的權限部分。隱私為app使用過程中與用戶個人相關的個人信息，如所在位置，Mac地址，設備id等。就Android端而言，多數隱私信息需要對應授權後才能獲取，但目前仍存在部分隱私信息無需授權就可以拿到的。為什麼大眾隱私意識覺醒，權限隱私安全性差會直接導致用戶不願使用；日趨嚴格的權限治理和隱私安全治理，工信部和市場的嚴格管控；客戶端作為與用戶最直接的交互信息收集入口，有義務合規化的收集和使用用戶信息。具體實踐一.Android各版本對權限的適配處理1.1 早期的註冊權限Android6.0(SDK版本為23)之前的版本，安裝App頁面會列出當前app所註冊的所有權限，無同意與否按鈕，只有安裝和取消，開發App時只需要在清單文件中註冊所需的對應權限即可：
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.CAMERA" />
1.2 動態權限授予Android自6.0(SDK版本為23)開始，將權限分為普通權限，危險權限，特殊權限。而其中的
危險權限需要在調用某些系統方法之前需要用戶手動授予對應權限，包括PHONE,LOCATION,STORAGE等多個權限組。如果在沒授權的情況下直接調用相關方法，就會拋出，應用也隨之崩潰。報錯信息類似下方這種：
java.lang.SecurityException: getDeviceId: has android.permission.READ_PHONE_STATE.
而要解決以上的報錯問題，可以自行封裝權限處理類工具，也可使用一些開源的權限工具進行處理。核心代碼都逃不過：
//判斷某個權限是否已經被同意
ContextCompat.checkSelfPermission(context, perm) == PackageManager.PERMISSION_GRANTED)
//請求某個權限，調用後會彈出權限系統彈窗
ActivityCompat.requestPermissions((Activity) object, perms, requestCode);
註：如果用戶拒絕權限且不讓再次顯示系統權限授權彈窗的話，最好是提供端內可點擊進入手機系統的權限設置頁面以讓用戶可以選擇開啟對應權限。
1.3 READ_PHONE_STATE權限的變化1.3.1 演變
1.3.2 適配處理1.4 存儲分區的處理自Android10.0之後，Google開始採用存儲分區，主要目的是改變現有App胡亂使用手機存儲導致垃圾和其他安全問題。適配 Android11 後強制使用存儲分區。具體分區如下，擴展的外部存儲是無權限進行讀取的。而其他私有存儲會在App卸載後清理掉：1.拍照存儲路徑：
Environment.getExternalStorageDirectory().getAbsolutePath()修改為getExternalFilesDir(Environment.DIRECTORY_DCIM)；2.原本的存儲路徑 /storage/emulated/0 改為 /storage/emulated/0/Android/data
具體調用的修改為:
Environment.getExternalStorageDirectory()改為context.getExternalFilesDir();3.如果App在sdcard中有重要存儲，可以在適配android10.0的過渡階段將之前的數據複製出來到新的存儲分區中。二.隱私信息合規化處理上半部分較為粗略的過了一下權限相關的部分改動和對應修改，接下來說一說隱私信息的合規化處理。當然，權限作為隱私處理的前提，如果權限都沒有合理的修改完畢，那隱私處理合規化更談不上了，畢竟很多隱私是依賴於權限的。
2.1 隱私信息獲取告知的直接化和透明化在首次打開App時，需要在進行初始化之前就向用戶展示用戶協議與隱私保護彈窗或頁面，只有用戶在同意之後才能進入App進行使用。而對於
手機號、MAC地址、IMEI、所在位置信息、手機存儲權限、相冊訪問權限，
手機流量使用等敏感信息需要讓用戶在第一屏就能夠看到。並且提供用戶協議和隱私政策連結，能讓用戶點擊後查看具體詳細的條款。設計完成後要讓法務進行確認，是否符合。在處理1.2中的動態權限時，需要在系統彈窗中或者之前說明需要用戶授予該權限的原因。如：獲取定位權限之前需要告知用戶該權限是為了獲取定位信息，然後精準推送相關內容。獲取相機權限是為了要使用攝像頭進行拍照。在進入App操作三步以內能看到法律條款和隱私政策入口，正常處理方式會在App的
設置頁內加上對應入口。同時在註冊登錄頁面，需要明顯展示出法律條款和隱私條款入口，且需要默認不勾選，需要用戶主動同意後才能進行帳號註冊和登錄。如下圖：
分發廣告的App需要注意處理廣告下載邏輯，在用戶點擊後需要展示所下載App的信息，所需的權限和隱私條款，讓用戶清楚的知道下載的App是否是自己想要的，且不允許自動下載。這樣能很好的解決用戶無意識的在手機上下載了很多無用App，這對很多老年人使用手機很有幫助。
2.2 隱私信息獲取和傳輸的安全化避免頻繁的調用系統方法獲取隱私信息，可以在單次啟動App調用該獲取數據後使用全局變量進行緩存，之後每次使用時直接調用全局變量使用就行，不必每次都調用系統方法。包括getDeviceId,getMacAddress等。諸如imei，mac，定位的經緯度等敏感信息，需要避免多次在網絡中傳輸，可以處理為單獨接口收集相關信息一次後保存在服務端即可，無需每次傳輸；另外需要避免以明文的方式在數據接口中傳輸。像imei可以通過MD5加密算法進行加密處理，並不會影響用戶的區分；由於READ_PHONE_STATE權限升級為了系統權限
READ_PRIVILEGED_PHONE_STATE，部分通過native方式(C代碼)直接調用imei等信息時也會報錯或者為空。建議這部分儘量使用java方式調用，如果有變動可以明顯的感知到錯誤並修改，不至於需要重新修改C代碼，然後又進行jni編譯。
2.3 部分隱私Api調用的嚴格化在未授權的情況下，需要保證App中與該權限無關聯的功能可以正常使用。所以就不能簡單的處理為1.3.1中提到的不給權限就不讓使用App的方案了。Android端目前尚存在部分無需動態授權就可以獲取的隱私，如用戶手機上的應用安裝列表。此信息可用於分析用戶喜好，如小說類產品還是視頻類產品；也可以用於分析用戶某些App還未安裝，便於推送廣告的拉新。但目前國內市場已經開始治理，如果存在獲取手機內應用列表的情況，會進行下架處理或者不予上架。目前工信部和各應用市場對App上架要求嚴格，使用第三方檢測工具可以很細緻的檢測出App中存在哪些不合理的系統方法調用，比如：在未同意協議與隱私之前就進行了網絡請求；在未同意協議與隱私之前獲取了Mac地址；在未獲取定位權限的情況下就獲取了手機的基站信息。三.遇到的一些問題和坑這裡總結部分在開發過程中遇到的一些隱蔽小點，希望能幫助到大家。早期的騰訊X5內核會在隱私協議展示時就會獲取mac地址，如下圖。可嘗試更新到新的版本繼續查看。由於我方對X5內核需求不高，所以直接進行了刪除清理。
集成開源庫或者第三方sdk的初始化均需要處理為同意隱私之後再進行，大多數sdk在初始化時都會調用相關無需授權的api方法。如語音相關的訊飛sdk會在初始化的時候調用MAC地址信息。部分統計庫如umeng，talkingdata sdk需要升級到新版本的接入方式。老版本的talkingdata sdk在尚未授定位權限時進行初始化仍會調用手機基站信息api(屬於定位)。自有代碼邏輯中相關隱私信息的獲取和賦值，也都要放到隱私同意之後去進行，故在用戶協議和隱私同意之前儘量少的進行代碼邏輯處理。總結
權限隱私的發展趨勢只會越來越嚴格和規範。在日常的客戶端開發當中，我們就需要時刻持有隱私安全的意識，讓自己站在用戶的角度上合理的保證隱私安全。並緊跟隱私安全的發展，提前布局。這樣才能不至於臨時出問題後手忙腳亂的去處理。
本文僅粗略的記錄了一些權限隱私相關的一些情況和做法，如有不當，歡迎指正。