본 포스팅은 パーミッションモデルの過渡期への対応 을 기본으로 번역하여 작성했습니다
제 일본어 실력으로 인하여 오역이나 오타가 발생할 수 있습니다.
실제 슬라이드의 일본어 부분을 번역했다는 점 양해바랍니다.
Permission 모델의 과도기에 대응
DroidKaigi 2016-03
2016/2/18
aki_sh_7
자기소개
목차
Android6.0의 큰 변경점
새로운 Permission 모델인 Runtime Permission 도입
이전의 Permission 모델
Runtime Permission
각 Model의 특징
| ~Android5.1 | Android6.0~ (targetSdkVersion<23) | Android6.0~ (targetSdkVersion>=23) | |
|---|---|---|---|
| Install | 허가 | 허가 | Dangerous이외 허가(확인없음) |
| Rumtime | - | - | 요구에 따라 허가 |
| Setting | - | Dangerous는 제한 가능 | Dangerous은 취소 가능 |
Permission이 필요한 API의 대응
API 사용전에 간단한 FlowChart
차트를 수정하기 힘드므로 일률적으로 적어봅니다
Step1. 체크 처리
public void showContacts(View v){
if (checkSelfPermission(Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
if(shouldShowRequestRermissionRationale(Manifest.permission.READ_CONTACTS)) {
// Explain to the user why we need to read the contacts
}
//Popup등으로 요구에 대한 설명을 적는다
requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
}else{
showContactsDetails(); // 이미 허가되어있는 경우의 처리
}
}
복수 Permission을 체크하는 경우는 문자열 배열을 받아 for문 등으로 체크하는 Class를 만들어도 됩니다.
Step.2 Request 처리
public void showContacts(View v){
if (checkSelfPermission(Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
if(shouldShowRequestRermissionRationale(Manifest.permission.READ_CONTACTS)) {
// Permission 필요성을 설명하기 위한 처리를 적는다
}
//Popup등으로 요구에 대한 설명을 적는다
requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
}else{
showContactsDetails(); // 이미 허가되어있는 경우의 처리
}
}
shouldShowRequestRermissionRationale(String permission)은 Permission이 과거에 Request를 거부하고 또한 “다시 묻지 않기”를 체크했는지를 확인할 수 있다
Step.3 Handling 처리
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
switch(requestCode) {
casae MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
showContactsDetails(); // 요청이 허가된 경우의 처리
} else {
if(shouldShowRequestRermissionRationale(Manifest.permission.READ_CONTACTS)) {
// Permission이 허가되지 않은 경우의 처리를 적는다
}else{
// "다시 묻지 않기"를 설정했다면 그 부분의 처리로 온다
// 어플 상세설정화면으로 Intent하는 버튼 표시등을 만들면 좋다
}
}
return;
}
// 그 외의 RequestCode시의 동작
}
}
Request에 대해서 허가되어있으면, PERMISSION_GRANTED(=0)가 포함되어 있다
언제 요청하면 좋은가
설명은 어디까지 할 것인가
대응의 효율성
몇 명의 사람이 은혜를 받았는가?
Platform Versions(2016/1)
Dashboards, http://developer.android.com/intl/ko/about/dashboards/index.html
Android6.0.x Devices(NTT 도코모)
3월 초순부터 순차적으로 업데이트 예정
www.nttdocomo.co.jp/info/notice/page/160210_00_m.html
2 Android 5.1 이전 단말로 대응한 targetSDKversion=23의 어플 작성방법
Android 5.1 이전 단말 대응
| 체크 | context#checkSelfPermission | ContextCompat#checkSelfPermission, PermissionChecker#checkSelfPermission 조금 동작이 다르다 (추후 설명합니다) |
| 요청 | Activity#requestPermissions, Fragment#requestPermissions | Android 6.0 미만이면 콜백 API로 허가 완료(선언한 것)라면 Granted, 이외는 Denied로 전달된다. ActivityCompat#requestPermissions, FragmentCompat#requestPermissions |
| 이외 | Activity#shouldShowRequestRermissionRationale, Fragment#shouldShowRequestRermissionRationale | Activity 6.0 미만에서 동작하면 항상 false. ActivityCompat#shouldShowRequestRermissionRationale, FragmentCompat#shouldShowRequestRermissionRationale |
3 targetSDKversion=23로 적용 불가능한 어플이 Android 6.0 미만에서 문제를 일으키지 않는 방법
targetSdkVersion=23에서 불가능한 케이스(예)
재게, 새로운 Permission 모델 특징
| ~Android5.1 | Android6.0~ (targetSdkVersion<23) | Android6.0~ (targetSdkVersion>=23) | |
|---|---|---|---|
| Install | 허가 | 허가 | Dangerous 이외 허가 (확인 없음) |
| Rumtime | - | - | 요구에 따라 허가 |
| Setting | - | Dangerous는 제한 가능 | Dangerous은 취소 가능 |
제한 ≠ 취소
제한 ≠ 취소
/data/system/user/{user_id}/runtime-permissions.xml/data/system/packages.xml
true“와 flags=”8”패키지 혹은 sharedUserId 마다 아래 형식으로 작성된다.
<item name="Permission 명칭" granted="true" flag="0">
제한 ≠ 취소
어떤 대체 처리가 이루어져 실제로 API 사용 불가.
하지만, Expcetion이 발생해서 종료되는 것은 없다 (예외 : 카메라는 Expcetion이 발생)
대응예
| 실행 허용 | 별도 처리 실행 | 실행 거부 | |
|---|---|---|---|
| 개요 | 제한 상태의 응답에 맞춘 핸들링 | 제한상태에서는 API를 사용하지 않고, 대체처리를 실행 | 제한상태에서는 동작하지 않는다(해제를 요구) |
| 체크 | API 사용 후 | API 사용 전 | Activity 시작 · 재시작 |
| 가동 | 大 | 中 | 小 |
제한상태에서 실행을 허용하여 개선
PermissionChecker#checkSelfPermission를 사용해서 판단· ContextCompat#checkSelfPermission(Context context, String permission)
허가한 경우는 "PERMISSION_GRANTED" 를 반환.
허가하지 않은 경우는 "PERMISSION_DENIED"를 반환.
(context#checkSelfPermission을 호출하는 것뿐. context#checkSelfPermission도 동일)
· PermissionChecker#checkSelfPermission(Context context, String permission)
허가한 경우는 "PERMISSION_GRANTED" 를 반환.
허가하지 않은 경우는 "PERMISSION_DENIED"를 반환.
허가는 했지만 제한된 경우는 "PERMISSION_DENIED_APP_OP"를 반환.
제한상태에서는 별도 처리하여 개선
제한상태에서 실행을 거부하여 개선
| Android 6.0 이후의 Runtime Permission 사고방식과 정반대! 어디까지나 어쩔 수 없는 경우에 대한 일시적인 조치이며 빠른 단계에 targetSdkVersion=23으로 대응을 |
4 정리
정리
추가
그룹 단위로 설정 변경의 영향
sharedUserId에 의한 설정 공유
선언한 Permission
어플 버전업시의 주의점
comments powered by Disqus
Subscribe to this blog via RSS.
LazyColumn/Row에서 동일한 Key를 사용하면 크래시가 발생하는 이유
Posted on 30 Nov 2024