編輯:關於android開發
原文:
http://www.2cto.com/kf/201512/455888.html
http://blog.csdn.net/yangqingqo/article/details/48371123
http://inthecheesefactory.com/blog/things-you-need-to-know-about-Android-m-permission-developer-edition/en
一、Marshmallow版本權限簡介
android的權限系統一直是首要的安全概念,因為這些權限只在安裝的時候被詢問一次。一旦安裝了,app可以在用戶毫不知曉的情況下訪問權限內的所有東西,而且一般用戶安裝的時候很少會去仔細看權限列表,更不會去深入了解這些權限可能帶來的相關危害。所以在android 6.0 Marshmallow版本之後,系統不會在軟件安裝的時候就賦予該app所有其申請的權限,對於一些危險級別的權限,app需要在運行時一個一個詢問用戶授予權限。
二、舊版本app兼容問題
那麼問題來了,是不是所有以前發布的app都會出現問題呢?答案是不會,只有那些targetSdkVersion 設置為23和23以上的應用才會出現異常,在使用危險權限的時候系統必須要獲得用戶的同意才能使用,要不然應用就會崩潰,出現類似
java.lang.SecurityException: Permission Denial: reading com.android.providers.media.MediaProvider
的崩潰日志。所以targetSdkVersion如果沒有設置為23版本或者以上,系統還是會使用舊規則:在安裝的時候賦予該app所申請的所有權限。所以app當然可以和以前一樣正常使用了,但是還有一點需要注意的是6.0的系統裡面,用戶可以手動將該app的權限關閉,如下圖
那麼問題又來了,如果以前的老應用申請的權限被用戶手動關閉了怎麼辦,應用會崩潰麼?我們來試一試
這裡寫圖片描述
好吧,可以慶幸了一下了,不會拋出異常,不會崩潰,只不過調用那些被用戶禁止權限的api接口返回值都為null或者0,所以我們只需要做一下判空操作就可以了,不判空當然還是會崩潰的喽。
三、普通權限和危險權限列表
現在對於新版本的權限變更應該有了基本的認識,那麼,是不是所有權限都需要去進行特殊處理呢?當然不是,只有那些危險級別的權限才需要。
當用戶安裝或更新應用時,系統將授予應用所請求的屬於 PROTECTION_NORMAL 的所有權限(安裝時授權的一類基本權限)。這類權限包括:
android.permission.ACCESS LOCATIONEXTRA_COMMANDS
android.permission.ACCESS NETWORKSTATE
android.permission.ACCESS NOTIFICATIONPOLICY
android.permission.ACCESS WIFISTATE
android.permission.ACCESS WIMAXSTATE
android.permission.BLUETOOTH
android.permission.BLUETOOTH_ADMIN
android.permission.BROADCAST_STICKY
android.permission.CHANGE NETWORKSTATE
android.permission.CHANGE WIFIMULTICAST_STATE
android.permission.CHANGE WIFISTATE
android.permission.CHANGE WIMAXSTATE
android.permission.DISABLE_KEYGUARD
android.permission.EXPAND STATUSBAR
android.permission.FLASHLIGHT
android.permission.GET_ACCOUNTS
android.permission.GET PACKAGESIZE
android.permission.INTERNET
android.permission.KILL BACKGROUNDPROCESSES
android.permission.MODIFY AUDIOSETTINGS
android.permission.NFC
android.permission.READ SYNCSETTINGS
android.permission.READ SYNCSTATS
android.permission.RECEIVE BOOTCOMPLETED
android.permission.REORDER_TASKS
android.permission.REQUEST INSTALLPACKAGES
android.permission.SET TIMEZONE
android.permission.SET_WALLPAPER
android.permission.SET WALLPAPERHINTS
android.permission.SUBSCRIBED FEEDSREAD
android.permission.TRANSMIT_IR
android.permission.USE_FINGERPRINT
android.permission.VIBRATE
android.permission.WAKE_LOCK
android.permission.WRITE SYNCSETTINGS
com.android.alarm.permission.SET_ALARM
com.android.launcher.permission.INSTALL_SHORTCUT
com.android.launcher.permission.UNINSTALL_SHORTCUT
這類權限只需要在AndroidManifest.xml中簡單聲明這些權限就好,安裝時就授權。不需要每次使用時都檢查權限,而且用戶不能取消以上授權。
危險權限
android.permission-group.CALENDAR
android.permission.READ_CALENDAR
android.permission.WRITE_CALENDAR
android.permission-group.CAMERA
android.permission.CAMERA
android.permission-group.CONTACTS
android.permission.READ_CONTACTS
android.permission.WRITE_CONTACTS
android.permission.GET_ACCOUNTS
android.permission-group.LOCATION
android.permission.ACCESS_FINE_LOCATION
android.permission.ACCESS_COARSE_LOCATION
android.permission-group.MICROPHONE
android.permission.RECORD_AUDIO
android.permission-group.PHONE
android.permission.READ_PHONE_STATE
android.permission.CALL_PHONE
android.permission.READ_CALL_LOG
android.permission.WRITE_CALL_LOG
com.android.voicemail.permission.ADD_VOICEMAIL
android.permission.USE_SIP
android.permission.PROCESS_OUTGOING_CALLS
android.permission-group.SENSORS
android.permission.BODY_SENSORS
android.permission-group.SMS
android.permission.SEND_SMS
android.permission.RECEIVE_SMS
android.permission.READ_SMS
android.permission.RECEIVE_WAP_PUSH
android.permission.RECEIVE_MMS
android.permission.READ_CELL_BROADCASTS
android.permission-group.STORAGE
android.permission.READ_EXTERNAL_STORAGE
android.permission.WRITE_EXTERNAL_STORAGE
android開發者官網也有相關描述:
http://developer.android.com/training/permissions/requesting.html
http://developer.android.com/guide/topics/security/permissions.html
所以仔細去看看自己的app,對照列表,如果有需要申請其中的一個權限,就需要進行特殊操作。還有一個比較人性的地方就是如果同一組的任何一個權限被授權了,其他權限也自動被授權。例如,一旦WRITE_EXTERNAL_STORAGE被授權了,app也有READ_EXTERNAL_STORAGE權限了。
四、支持Marshmallow新版本權限機制
關於權限控制主要使用到
PermissionChecker類的checkSelfPermission();
ActivityCompat類的
public static boolean shouldShowRequestPermissionRationale(@NonNull Activity activity,
@NonNull String permission)
Fragment類的
public boolean shouldShowRequestPermissionRationale(@NonNull String permission)
ActivityCompat類的
public static void requestPermissions(final @NonNull Activity activity,
final @NonNull String[] permissions, final int requestCode)
Fragment類的
public final void requestPermissions(@NonNull String[] permissions, int requestCode)
終於要開始支持android 6.0版本了,最先一步當然就是修改build.gradle文件中的tragetSdkVersion和compileSdkVersion成23版本,同時使用compile ‘com.android.support:appcompat-v7:23.1.1’最新v7包。
android {
compileSdkVersion 23
...
defaultConfig {
...
targetSdkVersion 23
...
}
}
...
dependencies {
...
compile 'com.android.support:appcompat-v7:23.1.1'
修改完後,感興趣的朋友可以直接打包在手機上測試一下,看看是不是會出現類似於上面我說的那些崩潰日志。
接著下一步當然就是要修改代碼了,最原始代碼,無任何處理:
private void startGetImageThread(){
....
Uri uri = MediaStore.Images.Media.EXTERNAL_CONTENT_URI;
ContentResolver contentResolver = getContentResolver();
//獲取jpeg和png格式的文件,並且按照時間進行倒序
Cursor cursor = contentResolver.query(uri, null, MediaStore.Images.Media.MIME_TYPE + "=\"image/jpeg\" or " +
MediaStore.Images.Media.MIME_TYPE + "=\"image/png\"", null, MediaStore.Images.Media.DATE_MODIFIED+" desc");
....
}
這段代碼需要訪問外部存儲(相冊圖片),屬於危險級別的權限,直接使用會造成應用崩潰,所以在這段代碼執行之前我們需要進行特殊處理:
int hasWriteContactsPermission = checkSelfPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE);
if (hasWriteContactsPermission != PackageManager.PERMISSION_GRANTED) {
Activity activty=this;
ActivityCompat.requestPermissions(activty,new String[] {Manifest.permission.WRITE_EXTERNAL_STORAGE},
CODE_FOR_WRITE_PERMISSION);
return;
}
寫完這段代碼之後,就會出現如下系統dialog:
緊接著就需要去處理DENY和ALLOW的回調了,重寫 Activity activity的ActivityCompat.OnRequestPermissionsResultCallback函數:
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
if (requestCode == CODE_FOR_WRITE_PERMISSION){
if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE)
&&grantResults[0] == PackageManager.PERMISSION_GRANTED){
//用戶同意使用write
startGetImageThread();
}else{
//用戶不同意,自行處理即可
finish();
}
}
}
好了,這樣就算是簡單初步適配完成了。
五、處理不再提醒
如果用戶拒絕某授權。下一次彈框,用戶會有一個“不再提醒”的選項的來防止app以後繼續請求授權。
如果這個選項在拒絕授權前被用戶勾選了。下次為這個權限請求requestPermissions時,對話框就不彈出來了,系統會直接回調onRequestPermissionsResult函數,回調結果為最後一次用戶的選擇。所以為了應對這種情況,系統提供了一個shouldShowRequestPermissionRationale()函數,這個函數的作用是幫助開發者找到需要向用戶額外解釋權限的情況,這個函數:
應用安裝後第一次訪問,直接返回false;第一次請求權限時,用戶拒絕了,下一次shouldShowRequestPermissionRationale()返回 true,這時候可以顯示一些為什麼需要這個權限的說明;第二次請求權限時,用戶拒絕了,並選擇了“不再提醒”的選項時:shouldShowRequestPermissionRationale()返回 false;設備的系統設置中禁止當前應用獲取這個權限的授權,shouldShowRequestPermissionRationale()返回false; 注意:第二次請求權限時,才會有“不再提醒”的選項,如果用戶一直拒絕,並沒有選擇“不再提醒”的選項,下次請求權限時,會繼續有“不再提醒”的選項,並且shouldShowRequestPermissionRationale()也會一直返回true。
所以利用這個函數我們可以進行相應的優化,針對shouldShowRequestPermissionRationale函數返回false的處理有兩種方案。第一種方案:如果應用是第一次請求該權限,則直接調用requestPermissions函數去請求權限;如果不是則代表用戶勾選了’不再提醒’,彈出dialog,告訴用戶為什麼你需要該權限,讓用戶自己手動開啟該權限。鏈接:http://stackoverflow.com/questions/32347532/android-m-permissions-confused-on-the-usage-of-shouldshowrequestpermissionrati 。第二種方案:在onRequestPermissionsResult函數中進行檢測,如果返回PERMISSION_DENIED,則去調用shouldShowRequestPermissionRationale函數,如果返回false代表用戶已經禁止該權限(上面的3和4兩種情況),彈出dialog告訴用戶你需要該權限的理由,讓用戶手動打開。鏈接:http://stackoverflow.com/questions/30719047/android-m-check-runtime-permission-how-to-determine-if-the-user-checked-nev 處理方法已經有了,修改一下代碼,我這裡就以第二種方案來處理了:
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
if (requestCode == CODE_FOR_WRITE_PERMISSION){
if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE)
&&grantResults[0] == PackageManager.PERMISSION_GRANTED){
//用戶同意使用write
startGetImageThread();
}else{
//用戶不同意,向用戶展示該權限作用
if (!ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.WRITE_EXTERNAL_STORAGE)) {
AlertDialog dialog = new AlertDialog.Builder(this)
.setMessage("該相冊需要賦予訪問存儲的權限,不開啟將無法正常工作!")
.setPositiveButton("確定", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
finish();
}
})
.setNegativeButton("取消", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
finish();
}
}).create();
dialog.show();
return;
}
finish();
}
}
}
當勾選不再提醒,並且拒絕之後,彈出dialog,提醒用戶該權限的重要性:
六、使用兼容庫
以上的代碼在6.0版本上使用沒有問題,但是在之前就有問題了,最簡單粗暴的解決方法可能就是利用Build.VERSION.SDK_INT >= 23這個判斷語句來判斷了,方便的是SDK 23的v4包加入了專門類進行相關的處理:
ContextCompat.checkSelfPermission()被授權函數返回PERMISSION_GRANTED,否則返回PERMISSION_DENIED ,在所有版本都是如此。ActivityCompat.requestPermissions()這個方法在6.0之前版本調用,OnRequestPermissionsResultCallback 直接被調用,帶著正確的 PERMISSION_GRANTED或者PERMISSION_DENIED。ActivityCompat.shouldShowRequestPermissionRationale()在6.0之前版本調用,永遠返回false。 用v4包的這三方法,完美兼容所有版本!下面是代碼:
//使用兼容庫就無需判斷系統版本
int hasWriteContactsPermission = ContextCompat.checkSelfPermission(getApplication(), Manifest.permission.WRITE_EXTERNAL_STORAGE);
if (hasWriteContactsPermission == PackageManager.PERMISSION_GRANTED) {
startGetImageThread();
}
//需要彈出dialog讓用戶手動賦予權限
else{
ActivityCompat.requestPermissions(PickOrTakeImageActivity.this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, CODE_FOR_WRITE_PERMISSION);
}
onRequestPermissionsResult函數不變。後兩個方法,我們也可以在Fragment中使用,用v13兼容包:FragmentCompat.requestPermissions() and FragmentCompat.shouldShowRequestPermissionRationale()和activity效果一樣。
七、一次請求多個權限
當然了有時候需要多個權限,可以用上面方法一次請求多個權限。當然最重要的是不要忘了為每個權限檢查“不再提醒”的設置。
List<string> permissionsNeeded = new ArrayList<string>();
permissionsNeeded.add(Manifest.permission.ACCESS_FINE_LOCATION);
permissionsNeeded.add(Manifest.permission.READ_CONTACTS);
permissionsNeeded.add(Manifest.permission.WRITE_CONTACTS);
requestPermissions(permissionsNeeded.toArray(new String[permissionsList.size()]), CODE_FOR_MULTIPLE_PERMISSION);</string></string>
最後在onRequestPermissionsResult函數中一個個處理返回結果即可。
八、第三方庫簡化代碼
當然早就有第三方庫來幫忙做這些事情了:
Github上的開源項目 PermissionHelper和hotchemi’s PermissionsDispatcher
九、APP處於運行狀態下,被撤銷權限
如果APP正在運行中,用戶進入設置-應用程序頁面去手動撤銷該APP權限,會出現什麼情況呢?哈哈,系統又會接著彈出權限請求對話框,挺好挺好:
這樣就沒有問題了吧O(∩_∩)O~
上面的測試環境為genymotion6.0模擬器,有朋友跟我反映在6.0nexus 6p真機上會直接退出應用,所以這個應該還和測試環境有關。
ActivityCompat.OnRequestPermissionsResultCallback
ActivityCompat.shouldShowRequestPermissionRationale()
The v4 support library also contains the PermissionChecker
class, which provides several static utility methods for apps that use IPC to provide services for other apps. For example,PermissionChecker.checkCallingPermission()
checks whether an IPC made by a particular package has a specified permission.
FragmentCompat.requestPermissions()
FragmentCompat.shouldShowRequestPermissionRationale()
requestPermissions()
的一些說明:
Note: When your app calls the framework's requestPermissions()
method, the system shows a standard dialog box to the user.
Your app cannot configure or alter that dialog box. If you need to provide any information or explanation to the user,
you should do that before you call requestPermissions()
, as described in Explain why the app needs permissions.
當調用 requestPermissions()
時,系統會顯示一個獲取權限的提示對話框,當前應用不能配置和修改這個對話框,
如果需要提示用戶一些這個權限相關的信息或說明,需要在調用 requestPermissions()
之前處理。
shouldShowRequestPermissionRationale()
的一些說明:
To help find the situations where you need to provide extra explanation, the system provides theshouldShowRequestPermissionRationale()
method.
This method returns true
if the app has requested this permission previously and the user denied the request.
That indicates that you should probably explain to the user why you need the permission.
If the user turned down the permission request in the past and chose the Don't ask again option in the permission request system dialog, this method returns false
.
The method also returns false
if the device policy prohibits the app from having that permission.
1. 第一次請求權限時,用戶拒絕了,下一次:shouldShowRequestPermissionRationale()
返回 true,應該顯示一些為什麼需要這個權限的說明
2.第二次請求權限時,用戶拒絕了,並選擇了“不在提醒”的選項時:shouldShowRequestPermissionRationale()
返回 false
3. 設備的策略禁止當前應用獲取這個權限的授權:shouldShowRequestPermissionRationale()
返回 false
注意:上面的:第二次請求權限時,才會有“不在提醒”的選項,如果用戶一直拒絕,並沒有選擇“不在提醒”的選項,下次請求權限時,會繼續有“不在提醒”的選項
十、shouldShowRequestPermissionRationale()
的方法說明:
Gets whether you should show UI with rationale for requesting a permission.
You should do this only if you do not have the permission and the context in which the permission is requested does not clearly communicate to the user what would be the benefit from granting this permission.
For example, if you write a camera app, requesting the camera permission would be expected by the user and no rationale for why it is requested is needed. If however, the app needs location for tagging photos then a non-tech savvy user may wonder how location is related to taking photos. In this case you may choose to show UI with rationale of requesting this permission.
根據方法說明:
顯示權限說明:是根據你的應用中使用的權限分類來的:
1.用戶容易知道應用需要獲取的權限:如一個拍照應用,需要攝像頭的權限,是很正常,不用提示。
2.一些用戶感覺困惑的一些權限:如:分享圖片,還需要獲取位置的權限,這個需要提示用戶:為什麼需要這個權限。
Android之JSON解析,androidjson 做個Android網絡編程的同學一定對於JSON解析一點都不陌生,因為現在我們通過手機向服務器請求資源,服務器給我
[android] 天氣app布局練習(二),androidapp主要練習一下GridView MainActivity.java package com.examp
關於TCP MSS的內核設置下面是一個MSS交互的例子,在三次握手的過程中兩個主機捎帶了不同的MSS值,192.168.189.22接口的MTU值為1500,192.16
記第一次lua和C互相調用的例子(以下的內容參考別人的例子,特此聲明)在寫程序之前,需要安裝lua的環境在終端輸入命令:sudo apt-get install lua5