最近在做權(quán)限優(yōu)化的工作內(nèi)容怀樟，所以來做一下記錄和總結(jié)
安卓有三種權(quán)限分組：普通權(quán)限、危險權(quán)限和特殊權(quán)限
普通權(quán)限在安裝后就賦予的不用申請拾因，危險權(quán)限則需要進行動態(tài)申請罢维，特殊權(quán)限需要跳轉(zhuǎn)到設(shè)置頁讓用戶自己勾選
普通權(quán)限：
ACCESS_LOCATION_EXTRA_COMMANDS
ACCESS_NETWORK_STATE
ACCESS_NOTIFICATION_POLICY
ACCESS_WIFI_STATE
BLUETOOTH
BLUETOOTH_ADMIN
BROADCAST_STICKY
CHANGE_NETWORK_STATE
CHANGE_WIFI_MULTICAST_STATE
CHANGE_WIFI_STATE
DISABLE_KEYGUARD
EXPAND_STATUS_BAR
GET_PACKAGE_SIZE
INTERNET
KILL_BACKGROUND_PROCESSES
MODIFY_AUDIO_SETTINGS
NFC
READ_SYNC_SETTINGS
READ_SYNC_STATS
RECEIVE_BOOT_COMPLETED
REORDER_TASKS
REQUEST_INSTALL_PACKAGES
SET_TIME_ZONE
SET_WALLPAPER
SET_WALLPAPER_HINTS
TRANSMIT_IR
USE_FINGERPRINT
VIBRATE
WAKE_LOCK
WRITE_SYNC_SETTINGS
SET_ALARM
INSTALL_SHORTCUT
UNINSTALL_SHORTCUT
危險權(quán)限：
特殊權(quán)限：
特殊權(quán)限主要兩個：懸浮窗和修改系統(tǒng)設(shè)置
SYSTEM_ALERT_WINDOW和WRITE_SETTINGS
使用相關(guān)的API：
checkSelfPermission(...)和requestPermissions(...)。
這兩個函數(shù)被添加在sdk23空闲，所以我們要使用兼容包的令杈，如下：
ContextCompat.checkSelfPermission(...)和ActivityCompat.requestPermissions(...)。
棄用：其中有一個shouldShowRequestPermissionRationale(...)用于判斷是否被勾選了彈窗的不再提醒用的碴倾，但后來測試發(fā)現(xiàn)這個api有點問題逗噩，在華為測試機中并未勾選不再提醒，但是卻被判斷勾選不再提醒了跌榔，所以就直接棄用了异雁，如果有知道原因的可以告訴我一聲。
在fragment中使用
在fragment中使用要注意使用fragment中的requestPermissions(...)僧须，否則不能回調(diào)onRequestPermissionsResult(...)
危險權(quán)限申請(例子)：
int hasPermission = ContextCompat.checkSelfPermission(context, Manifest.permission.READ_CONTACTS);
if (hasPermission != PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(context, new String[]
{Manifest.permission.READ_CONTACTS},
REQUEST_CODE_READ_CONTACTS_PERMISSIONS);
然后在回調(diào)：
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
switch (requestCode) {
case PermissionUtil.REQUEST_CODE_READ_CONTACTS_PERMISSIONS:
if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
clickAddMobileContacts();
} else {
showToast(getResources().getString(R.string.permission_contact));
}
break;
default:
super.onRequestPermissionsResult(requestCode, permissions, grantResults);
}
}
其中遇到了WRITE_SETTINGS的特殊權(quán)限纲刀，這是修改系統(tǒng)設(shè)置的權(quán)限，一般應(yīng)用很少用到担平，對于這種特殊權(quán)限不能動態(tài)分配權(quán)限示绊，也不能默認授予權(quán)限锭部，只能intent界面讓用戶自己勾選。
private static final int REQUEST_CODE_WRITE_SETTINGS = 1;
private void requestWriteSettings() {
Intent intent = new Intent(Settings.ACTION_MANAGE_WRITE_SETTINGS);
intent.setData(Uri.parse("package:" + getPackageName()));
startActivityForResult(intent, REQUEST_CODE_WRITE_SETTINGS );
}
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
if (requestCode == REQUEST_CODE_WRITE_SETTINGS) {
if (Settings.System.canWrite(this)) {
Log.i(LOGTAG, "onActivityResult write settings granted" );
}
}
}
對于國內(nèi)廠商的一些適配問題
以上也只是原生系統(tǒng)的做法面褐，而國內(nèi)的某些廠商在6.0以前就已經(jīng)做了自己的權(quán)限機制處理了拌禾，我們需要對此進行適配。比如國內(nèi)的小米和魅族都有自己的權(quán)限機制處理盆耽，在使用上面的處理判斷時無論是否允許或禁止都是返回允許狀態(tài)的蹋砚，所以這種機制是無效的扼菠，而他們的權(quán)限獲取則是在調(diào)用服務(wù)時才彈窗要求獲取權(quán)限摄杂，當禁止后代碼繼續(xù)執(zhí)行就有可能閃退報錯，而之后就不會再彈窗了循榆，網(wǎng)上有方案說進行try{}catch{}的處理析恢。
