[Android][Android 13][API Level 33] 런타임 알림 권한, 그리고 기획 변경

시작. 이슈 발견

Android 13 단말에서 푸시를 받고 시스템 알림을 띄우지 못하는 이슈가 있음을 알게 됐다.

 

원인 파악

Android 13부터 새로 설치되는 앱들은 알림 생성 권한이 없다는 것을 알았다. 해당 이슈는 테스트 단말이 Android 13 단말에, 테스트 앱이 신규로 설치되었기 때문이었다.

Android 12는 기본으로 알림 생성 권한이 있어서 이런 이슈를 만날 일이 없었다. 

 

정말 잘 설명해주신 글

https://codechacha.com/ko/android-13-notification-permission/

Android 13에서 Notification 권한 요청, 알림 띄우기

공식문서

https://developer.android.com/about/versions/13/changes/notification-permission?hl=ko 

알림 런타임 권한  |  Android 개발자  |  Android Developers

앱은 target api version이 33이라 런타임 권한 요청을 개발자가 코드로 삽입해야 했다.

Android 12, Android 13 단말을 대상으로 테스트를 해봤는데, POST_NOTIFICATION 권한 체크는 두 단말 다 가능하나 런타임 알림 권한 요청은 Android 13만 가능해서 분기처리가 필요했다.

 

문제 해결을 하자

Android 13 이상 단말은 런타임 권한 요청을 진행하고, Android 12 이하 단말은 이전부터 기능을 제공해오지 않았기에 현상태를 유지하거나 앱 설정 화면으로 사용자를 유도해 권한을 얻는 방식으로 진행하면 된다는 큰 방향이 결정됐다.

이제 기획자와 이야기해서 구체적으로 정하면 된다. 

 

사실 우리 앱 기획은, 푸시를 받았을 때 앱이 포그라운드 상태면 커스텀 토스트를 띄워주고, 앱이 백그라운드에 있거나 실행 중이지 않을 경우에는 시스템 알림으로 푸시 내용을 사용자에게 전달한다. 알림 권한이 OFF된 상태라면 푸시가 정상적으로 와도 백그라운드 상태이거나 실행 중이지 않은 상태에서는 알림 내용을 사용자가 알 수 없게 된다. 이 이슈는 원래 기획을 틀어버리는 큰 변경사항이기는 하다. 그러나 앱의 다른 사용성에는 영향을 주지 않는다.

 

* 이 문제 해결에는 정답이 있는 것이 아니라서 문제 해결 방식이 번복되었다. 왜 이런 방식을 선택했는지, 그런데 왜 번복되었는지에 대한 과정도 고민의 여정이기에 기록으로 남긴다.

 

1) 일단 기획자를 만나기 전에 제안할 수 있는 것들을 정리한다.

 

1. 팀장님과 논의해서, 앱 진입 플로우에서 알림 권한을 체크하는 것이 적합하다는 결론이 나왔다. > ①

- 알림 권한이 없는 Android 13 이상 단말은 런타임 알림 권한 요청을 진행한다. > ②

- 알림 권한이 없는 Android 12 이상 단말은 사용자에게 이 권한이 필요하다는 것을 알리는 문구의 팝업을 띄우고, 팝업의 positive 버튼을 통해 앱의 설정 화면에 진입해 알림 권한을 On 하도록 유도한다. > ③

2. Android 13 이상 단말 사용자가 권한을 거부할 경우, 사용자에게 이 권한이 필요하다는 것을 알리는 문구의 팝업을 띄우고, 팝업의 positive 버튼을 통해 앱의 설정 화면에 진입해 알림 권한을 On 하도록 유도한다. > ④

 

팀장님은 알림 권한을 받는 것이 필수적이라고 생각하셨다. 기존 기획이 망가지지 않기 위해서는 괜찮은 방법이라고 생각해서 넵.

 

① 작업

앱 진입 플로우에서 알림 권한 체크 프로세스 차례가 오면

1) Manifest.permission.POST_NOTIFICATIONS 권한이 있는지 확인한다.

    ContextCompat.checkSelfPermission(context, permssion)을 사용한다.

1-1) 권한이 있다. > 앱 진입 플로우의 다음으로 넘어가기

② 작업

1-2) Android 13 단말에 권한이 없다. > 권한 요청하기

    권한 요청을 위해 registerForActivityResult(ActivityResultContracts.RequestPermission())을 사용했다.

1-2-1) registerForActivityResult(ActivityResultContracts.RequestPermission()) 의 콜백에서,

1-2-1) 사용자가 권한을 허용하면 > 앱 진입 플로우의 다음으로 넘어가기

③ 작업

1-2-2) 사용자가 권한을 허용하지 않으면 > 사용자에게 권한이 필요하다는 팝업 노출하기

    팝업이 dismiss 될 경우, 앱 진입 플로우의 다음으로 넘어가기

1-2-2-1) 팝업의 Positive 버튼 탭 시 > 앱의 설정 화면에 진입하고, 팝업 dismiss

1-2-2-2) 팝업의 Negative 버튼 탭 시 > 팝업 dismiss

④ 작업

1-3) Android 12 단말에 권한이 없다. > 사용자에게 권한이 필요하다는 팝업 노출하기

1-3-1) 1-2-2, 1-2-2-1, 1-2-2-2의 반복

 

 2) 기획자를 만나서 제안하고, 구체적인 기획 사항 논의하기

기획자를 만나서 이슈와 이슈 발생 원인을 설명했다. 안드로이드 프레임워크의 권한에 대한 규칙들도 설명해주고. 최근에 자주 느끼는 거지만, 개발자가 다른 부서 사람들과 협업하는 과정에서 기술에 대해 쉽게 설명할 수 있는 것도 소통 능력 중에 하나인 듯 하다. 기획자는 고맙게도 내가 전달하는 사항들을 정말 제대로 이해했다. (내가 아무리 열심히 설명해도 이해하지 못하는 분도 있다는 것도 경험해봤다🥺 제가 역량을 좀 더 길러 보겠습니다...)

 

안드로이드 시스템은 사용자가 런타임 권한 요청을 여러 번(두 번 정도) 거절하면 더 이상 권한 요청을 진행하지 않는다고 기획자에게 알려줬다. 기획자는 사용자가 그 정도로 거절했으면 된 것 같다고, 더 이상 사용자를 귀찮게 하지 않는 쪽으로 진행하자고 했다. 기획자가 그렇게 이야기한다면... 넵. (팀장님과는 알림 권한을 받아오는 것을 강제하는 쪽으로 이야기하기는 했었는데, 기존 기획이 망가질 수도 있다는 것을 기획자가 알고도 그렇게 진행한다니 딱히 강하게 반대할 이유가 없었다. 기획자의 영역을 침범하고 싶지도 않았다.)

 

안드로이드 디벨로퍼스에서 공식적으로 어떤 입장인지를 좀 더 살펴보았다.

https://developer.android.com/training/permissions/requesting?hl=ko 

앱 권한 요청  |  Android 개발자  |  Android Developers

 

그림 1.  Android에서 런타임 권한을 선언하고 요청하는 워크플로를 보여 주는 다이어그램

공식문서에서 제공하는 권한 요청 워크플로를 찾아봤다.

그림1의 8b번 순서를 보고, 구글의 권장사항이 사용자의 선택을 받아들이고 앱의 퀄리티를 저하시키는 쪽이면 이렇게 가는 것도 나쁘지 않겠다고 생각했다. 대신 5b의 과정은 추가해야 할 듯 했다.

5b의 과정을 위해 ActivityCompat.shouldShowRequestPermissionRationale() 메서드를 만들어 놓았음을 알았다. 기획자에게 말해 사용자에게 알림 권한이 필요한 이유를 설명하는 팝업을 추가하는 것을 슬랙으로 제안했다. 그리고 바로 주간회의를 들어갔다.

 

3) 원복

주간 회의에게 해당 건에 대해서 공유했고, 해당 알림 권한은 사용자에게 강제로 받아야 한다는 의견이 나왔다. (의견에 화가 담겨 있었다. 본인이 생각하는 대로 이뤄지지 않아서 내는 화. 설득에 실패해서 화를 내는 걸 받는 입장은 피곤하다.) 해당 권한을 강제로 받지 않으면 앱 특성 상 CS가 많이 들어올 거란 예측에 그 의견을 수렴하기로 했다. (화가 아니라 CS가 문제다. CS는 나만 피곤한게 아니라서 회사 사람들을 위해서라도 발생 가능한 CS는 예방해야 한다.) 경험 상, 사용자들은 단말의 기술에 대한 지식이 거의 없다. 개발자 입장에서는 사용자의 환경이나 사용자의 설정 사항 변경에 따른 정상동작인데, 사용자는 개발자 탓을 한다. 그래서 기획자가 정말 친절하게 문구를 추가해 사용자에게 보여주지만, 사용자들은 글을 잘 안 읽는다.(사실 나도 잘 안 읽게 되어서 이해한다.) 분명 다수의 사용자들은 시스템 알림과 푸시를 구분하지 못할 것이고, 앱 내 설정 사항에서 서버에서 받는 푸시 기능은 ON하고, 단말의 알림 권한은 OFF 한 채 CS 문의가 들어올 것이 뻔하다. 

 

기획자를 만나 내가 CS 문제를 놓쳤음을 이야기하고, 결국엔 1)의 ①②③④와 비슷하게 기획이 만들어져 반영되었다. 사용자가 단말의 알림 권한을 ON할 때까지, 앱은 실행하면서 계속 사용자를 귀찮게 굴 것이다. 이제 검증 단계가 남았다. 잘 돌아가길!

 

이 글을 쓰면서 다시 생각해보니, 고객이 원하는 서비스는 알림 권한이 ON 상태일 때 온전히 제공되는 서비스다. 그래, 이렇게 가는 게 나쁘지 않다.

---

안드로이드 디벨로퍼스 공식 문서 내용은 똑똑한 구글 개발자들이 여러 데이터 수집, 조사, 검증을 통해 권장사항을 알려줄텐데, 실제 문제 해결 중 반영하는 것기 쉽지는 않다는 걸 경험했다. '정답은 없다'가 맞다. 상황에 맞춰 문제 해결에 최선을 다했을 뿐이다.