[Android] Android 14 (SDK 34) 버전을 targetSDK로 사용할 때 주의할 점 몇가지

필자가 회사에서 앱을 업데이트하는데, target SDK version을 34로 올렸을 때 발생했던 문제에 대해 간략하게 작성해두고자 한다.

런타임시에만 에러가 발생하는 케이스도 존재하기 때문에, 코드로 수정한 후에 직접 실행하여 모든 경우를 체크해 보는 것이 좋다는 것을 미리 언급하고 글을 작성하도록 하겠다.

 

해당 버전을 targetSDK로 사용하게 되었을 때 변경이 이루어지는 부분은 공식 문서를 보면 알겠지만 상당히 많다.

하지만 이러한 문제들은 고려하면서 작업하면 되지만, 필자가 아래에 작성할 몇 가지는 심사 제출을 시도하지 않으면 알 수 없는 부분이 존재하므로 간략하게나마 작성하고자 한다.

 

부디 이 글을 보는 개발자분들은 앱이 죽는 문제가 있는데 심사가 딜레이되어 똥줄 타는 일이 없길 바란다.

---

우선 첫 번째로는 registerReceiver의 Flag 값이다.

registerReceiver(broadcastReceiver, intentfilter, RECEIVER_EXPORTED)

필수로 들어가는 Flag 값은 맨 마지막 파라미터는 RECEIVER_EXPORTED와 같이 사용되는 것으로, 해당 값 혹은 RECEIVER_NOT_EXPORTED 값이 targetSDK 34부터 해당 값이 필수로 들어가는 것으로 바뀌었다.

 

flag 값만 바꾸면 되는거 아닌가? 그게 뭔 주의할 점까지인가?라고 생각할 수 있다.
하지만, version에 따른 flag 값 설정이기 때문에 해당 부분은 빌드 시에는 에러로 체크되지 않고,  RUNTIME시에만 에러로 처리되어 앱이 죽게 된다.

java.lang.SecurityException: package: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn’t being registered exclusively for system broadcasts

 

위와 같은 에러를 발생하면서 말이다.

그렇기 때문에 registerReceiver가 사용되는 모든 부분을 검색하여 버전에 따른 flag 값을 추가해주어야 한다.

여기서 끝나면 그렇게 주의하지 않아도 된다.
중요한 부분은 사용 중인 라이브러리에서 registerReceiver를 사용하는 케이스가 있다면, 그 부분에도 flag 값이 추가되어있어야 한다.

필자는 registerReceiver를 사용하는 라이브러리를 사용하고 있었고, 해당 부분은 체크하지 못하고 배포를 올렸다가 앱의 비정상 종료가 만의 자릿수가 되는 경험을 하게 되었다.

Firebase에서 Crashlytics 메일이 계속 오고, 들어가보면 저런 수치가 발생하면 정말 정신이 아찔해진다.

 

따라서, 외부 라이브러리를 이것저것 사용하는 경우 registerReceiver를 사용할만한 부분을 테스트해 보거나 전체적으로 테스트를 하여 앱이 안전한지 확인해 보는 것을 추천한다.

 

이번 버전에 추가된 flag 값인데 바로 강제하는 것은 너무한 것 아닌가?라고 생각한다면,

그렇지는 않다.

해당 flag 값은 sdk 33에 추가된 값으로 해당 버전에서는 권고사항이었으나 sdk 34부터는 필수 사항이 된 것일 뿐이다.

 

flag값에 따라서 변경되는 부분은 간단하게 말하자면 broadcast receiver로 수신할 수 있는 범위를 조절하는 것으로,

해당 broadcast를 다른 앱에서 수신할 수 있도록 하려면 RECEIVER_EXPORTED를, 수신하지 못하게 막으려면 RECEIVER_NOT_EXPORTED로 설정해 주면 된다.

다음으로는 앱 배포 시에 알 수 있는 부분이다.
포그라운드 서비스 권한 부분이 변경되었는데,

<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_DATA_SYNC" />

해당 permission을 사용하고 있으면서 targetSDK가 34가 된다면 어떤 경우에 사용하고 있는지 파일을 첨부해야 한다.

 

위에서 체크박스를 클릭하면, 어떤 작업을 하는지 표현이 되어있는 파일을 확인할 수 있는 URL을 입력하라고 한다.

정확히 어떤 부분에 사용되고, 앱 내에서 어떻게 보이고 사용되고 있는지 촬영해서 첨부하면 베스트겠지만 UI에서 확인할 수 없는 경우도 있다. 이 경우 UI에서는 확인되지 않더라도 사용하는 부분의 영상을 찍어서 제출하면 된다.

여기서 간단하게 전달할 수 있는 방법으로는 구글 드라이브를 사용하면 된다.
파일을 제출해야 하는데 파일을 업로드 하는 헝태가 아니라 url 형태로 영상이 있는 위치를 전달해 달라고 한다. 그렇기 때문에 파일을 어디에 업로드 하고 전달해야 하는데, 마땅히 올려둘 곳이 없을 수 있다.
이 때는 깊게 생각하지 말고 개인 구글 드라이브에서 전체 공유 옵션을 킨 다음, 해당 파일을 올리고 파일이 올라간 폴더의 URL을 첨부하면 된다.

 

해야하는 작업은 별 것이 없기는 하지만,

정확히 어떤 부분에서 해당 퍼미션이 사용되는지 인지하고 있지 않다면 어떤 부분인지 찾아서 영상을 찍어야 하기 때문에 물리적인 시간이 소요되는 작업이다.

마지막으로 설명하고자 하는 부분은 케이스마다 다르기 때문에 이런 것이 있다. 하고 인지만 하고 있어도 되는 부분이다.

해당 글을 작성하기 시작한 24년 4월 3일 기준으로, targetSDK가 34로 된 앱의 경우 앱의 심사 시간이 최소 일 단위가 넘어간다.

필자는 3월 중순~말부터 targetSDK 34 버전으로 배포를 3차례 진행하였는데 모두 48시간이 넘어서 심사가 통과되었다.

가장 마지막에 targetSDK 34 버전으로 배포를 했을 때는 다음과 같았다.

배포를 위해 aab를 업로드 한 시간

심사가 통과 된 시간

물론 앱의 심사 시간은 케바케라고 말은 하지만, 같은 시기에 배포한 다른 안드로이드 개발자 분들의 말을 들어보았을 때 4일이 걸린 케이스도 존재하였고, 24시간 이전에 배포된 사람이 없었다.
필자와 주변 사람들 모두 운이 안 좋았다.라고 생각할 수 있다면 좋겠지만 적어도 6개의 앱 심사에 최소 하루 이상의 시간이 걸렸다.

마지막 배포에 앱이 죽는 크리티컬 한 이슈가 발생되어 긴급하게 배포를 진행해야 했고,
필자는 targetSDK 34인 경우 앱 배포가 늦는 것이 맞다고 생각하여 33 버전으로 낮추고 코드를 수정하여 배포를 진행하였는데 1시간 후에 바로 배포가 되었었다.
그 후에도 2차례 더 배포하였으나 2시간 이내로 심사가 통과하는 것으로 보아 targetSDK를 34로 했을 때 모종의 이유로 심사 시간이 오래 걸리는 것이 거의 맞는 것이라고 생각한다.

하지만, 당연하다시피 심사의 프로세스를 전혀 알지 못하는 상황이기 때문에 이것이 사실이 아닐 수 있다.
그렇지만 체감상, 경험상 평소 생각하던 것보다 심사 시간이 많이 걸리니 다른 개발자 분들이 서비스를 배포할 때 고려하고 배포하지 않으면 필자처럼 다급한 일이 있을 수 있으므로 참고차, 그럴 수 있음을 인지하고만 있으면 좋을 것 같아서 작성해 둔다.

---

 

해당 내용은 당연히 개발을 하면서 대응을 해야 하는 os version 문제이다.

하지만 필자처럼 수정했다고 생각했는데 외부 라이브러리에서 대응하지 않아 앱이 죽는 문제가 발생할 수 있고, 운이 안 좋게도 그 케이스를 확인하지 못한다면 정말 끔찍한 일을 경험할 수 있을 것이다.

 

위에 사진으로 남겨두었지만, 저 수치를 보았을 때 정말 정신이 아찔하였고, targetSDK 34 버전은 배포에도 시간이 오래 걸려 어떻게 해야 하나 정말 많은 고민을 했던 것 같다.

 

필자와 같이 멍청하게 앱을 죽이는 개발자가 없길 바라지만, 혹여 같은 문제로 머리 아파하고 있는 개발자를 위해 짧게나마 글을 작성해 둔다.

위의 3가지 경우를 제외하면, android 14 (TargetSDK 34) 버전으로 개발을 할 때가 아닌, 배포를 하는 타이밍에서 물리적인 시간이 오래 걸리는 작업은 없을 것이다.