targetSdkVersion 업데이트 Android10 Q API29 업데이트 강제사항

2020년 8월부터는 구글로부터 아래와 같은 이메일을 보신 분들이 있으실 텐데요.
추가로 해야할 테스트나 코드수정은 부담이지만,

정확히 2020년 11월 2일부터는 API29 이상을 타게팅하지 않으면 업데이트가 되지 않으므로 반드시 해 주어야 합니다.

따라서 미리부터 준비하고 테스트를 해서 유저에게 문제가 되지 않도록 해 주어야 할 텐데요.

오늘은 이것을 할 때 주의해야 할 점들에 대해서 정리해 보도록 하겠습니다.

 

 

1. targetSDKVersion수정

targetSdkVersion자체는 쉽게 수정할 수 있습니다.

app레벨의 build.gradle을 아래와 같이 수정해 주기만 하면 되는데요.

먼저 targetSdkVersion을 29로 수정해 줍니다.

compile시에 사용하는 SDK버전을 설정하는,

compieSdkVersion도 아래와 같이 29로 수정해 주어야 겠지요.

 

 

 

이렇게 함으로서 version을 29로 올리는 작업은 끝났습니다.

기존에 SDKVersion이 28이라면, 29기기에서는 28을 타겟으로 하는 앱에서 필요로 하는 작업들이

하지만, SDK Version29에서 요구하는 작업들에 대한 확인이 필요한데요.

어떤 점들이 있는지 알아보도록 하겠습니다.

 

참고로 저는 기존에 targetSdkVersion이 28이었는데요.

28이하의 버전들에서 지켜야 할 사항들에 대해서 테스트가 되어있는 상황이었던 것 이지요.

28버전에서는 백그라운드 서비스 생성이 허용되지 않는 상황(앱이 포그라운드에서 실행되지 않고 쉬고 있는 상황)에서는

startService() 메서드를 사용 할 경우 IllegalStateException을 발생시켰기 때문에,

ContextCompat.startForegroundService()를 실행해 주어야 했었습니다.

게다가 FOREGROUND_SERVICE에 대한 permission을 얻어야 해서 manifest에 선언을 해주는 작업들조 필요했었지요.

 

이번에 28에서 29로 올리면서는 API레벨 29(Android10) SDK가 필요로 하는 점들을 확인하고 수정해 주면 되겠습니다.

 

2. full-screen intent를 이용한 Notifications

알람앱이나 전화앱등에서는 유저가 즉시 노티가 왔을 때 알아채고 반응할 수 있도록,

Full Screen으로 Intent를 띄어줍니다.

Andoroid Q(Api10)에서 부터는 full-screeen Intent를 이용하는 Notification을 사용하는 경우는 아래와 같이 Permission을 Manifes에서 요청해 주어야 합니다.

 

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

 

 

다행히 동적으로 Permission을 요청할 필요는 없어서 다행이네요.

 

혹시 full screen intent를 구현했었는지 기억이 나지 않으신다면,

setFullScreenIntent 함수를검색해서 코드에서 사용하고 있는지 확인을 해 보아야 합니다.

알람앱이라면 100%구현되어있을 테니까요.

 

full screen intent가 무엇인지 궁금해하시는 분들은 아래 글을 참조해 주세요.

>> Full Screen Intent Notificaiton 에 관한 정리 # 풀스크린 인텐트

 

3. ACCESS_BACKGROUND_LOCATION permission

Android10에서는 ACCESS_BACKGROUND_LOCATION 권한에 대해서 알고 있어야 할 것 같습니다.
이를 이해하기 위해서 아래 UI를 보면 좋을 것 같습니다.

영어로 적혀져 있지만, 위치정보를 항상 허가할 것인지, 앱을 사용할 때만 허가할 것인지,
아니면 아에 허가하지 않을 것 인지를 결정하라고 유저에게 선택하는 화면인데요.

유저입장에서는 위치권한 하나만 선택할때도 생각할게 많아지므로, 좋지 않은 UX라고 개인적으로는 생각하지만,

구글입장에서는 배터리나 privacy관련한 부분을 유저에게 맞기려고 하는 것 같습니다.

 

 

 

Background와 반대인 Foreground에서 앱을 사용하고 있다고 Android System이 생각하는 경우는 다음과 같습니다.

이에 해당하지 않는다면 Background Permission이 필요한 것 이지요.

 

• 유저에게 보이는 Activity에서 위치를 사용하고 있는 앱
• foreground service를 이용해서 위치를 사용하고 있는 앱

 

기존에는 위치권한을 이용할 때, manifest에서 아래와 같은 권한을 선언하고, 동적으로 유저에게 물어서 권한을 얻었었는데요.

(동적인 권한은 예전에 정말 고통스러웠었지요.)

 

 

그리고 한가지 더 명시적으로 나타낼 것은 manifest에서 service를 선언할 때, 타입을 명시하라고 나와있습니다.

foregroundServiceType을 명시하라고 나와있습니다.

원래는 권장사항이었는데, Android10 부터는 명시하라고 나와있네요.

하지만, 얼마만큼 크리티컬한 것인지는 잘 모르겠습니다.

service를 위의 6가지로 모두 구분할 수 있는 것은 아니기도 하구요.

공식문서에도 이 부분에 대해서는 자세하게 나와있지는 않네요.

 

 

사용할 수 있는 타입에는 아래와 같이 6가지 타입이 있습니다.

위치를 사용하는 서비스타입이니 아래와 같이 "location"이라고 명시해주면 좋겠지요.

 

 

 

3-1. Permission추가

이 권한은 Settings-> Location-> App permission 에서 수정할 수 있는 권한인데요.

만약, 앱이 항상 권한을 허가하도록 해주어야 하는 앱이라면,
ACCESS_BACKGROUND_LOCATION 권한을 Manifest파일에 명시해 주어야 합니다.

 

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

 

예전에 targetSdkVersion이 28이었을때는,
ACCESS_FINE_LOCATION 또는 ACCESS_COARSE_LOCATION을 기존에 요청하였다면,
자동으로 ACCESS_BACKGROUND_LOCATION permission을 시스템에서 붙여주었는데요.
이제 targetSdkVersion이 29로 변경하면서는 그 책임은 개발자인 저희한테 오게 됩니다.

background에서 location 정보가 있어야 하는 앱의 경우, 해당 권한을 얻지 못하였을 경우는 문제가 생길 수 있는데요.
이런 경우 권한이 없어서 앱이 제대로 동작할 수 없다는 사실을 유저에게 알려야 하겠지요.

 

foreground Service만 사용하는 경우는 문제가 없을 것으로 생각합니다.
위치와 관련된 유저 시나리오를 테스팅해서 문제가 발생하지 않도록 해야겠지요.

 

아직 제가 만든 앱들은 foreground에 있거나 foreground Service를 이용해서만 위치정보를 받아오고 있으므로 해당사항은 없는데요.
혹시 Backgound에서 위치정보를 받아오고 있다면 해당 사항에 대해서 고려를 해 주어야 겠지요.

 

3-2. Android11에서의 변화

여기서 다룰 주제는 아니지만, 추가적으로 안드로이드11버전에서는 이 부분이 또 바뀌는데요.

이제 Allow all the time은 위에서 본것같은 다이얼로그에 더이상 나오지 않구요.

유저가 직접 설정화면에 가서 변경할 때만 사용하도록 바뀝니다.

언젠가는 minimum target sdk version이 바뀔 것이기 때문에,

background에서 위치권한을 사용하시는 앱이 있다면 이 부분에 대해서 미리 공부해두고 대응할 필요가 있을 것 같습니다.

 

 

 

4. Scoped Storage

Android10(Q)에서는 앱을 위한 Private한 내부 디렉토리가 있고, 나머지 공간은 SharedStorage의 개념으로 모두 접근할 수 있었는데요.

Android10부터는 앱만의 Private한 영역은 내부와 외부 디스크저장소까지 모두 Private하게 하구요.

앱이 접근할 수 있는 범위를 Media 와 Download Collections로 좁히고, 파일관리와 Privacy를 향상시키고자 하였습니다.

Scoped Storage의 자세한 내용은 아래 글을 참조해 주세요.

>> ScopedStorage에 관한 총정리

 

다만, 다행인것은 manifest의 flag를 통해서 Android10에서는 적용을 유예받을 수 있구요.

다음버전부터는 유예없이 적용해야 하는 것 같습니다.

ScopedStorage를 적용하고자 하는 분들은,

Manifest의 application에 requestLegacyExternalStorage 속성을 true로 해 주어야 합니다.

 

 

5. Telephony, Bluetooth, Wi-Fi API 중 일부 사용시 Permission

Manifest에서의 권한선언과 동적으로 유저에게 요청해야하는,

ACCESS_COARSE_LOCATION 또는 ACCESS_FINE_LOCATION Permission을 얻어야 합니다.

Permission을 얻어야 하는 API는 다음과 같습니다.

혹시 아래의 API를 앱에서 사용중이라면 Permission을 앱에서 얻어놓았는지 확인해보고,

없다면 코드를 추가해 주어야겠습니다.

타입	Class 와  함수	비고
Telephony	TelephonyManager - getCellLocation() - getAllCellInfo() - requestNetworkScan() - requestCellInfoUpdate() - getAvailableNetworks() - getServiceState()      TelephonyScanManager - requestNetworkScan() TelephonyScanManager.NetworkScanCallback - onResults() PhoneStateListener - onCellLocationChanged() - onCellInfoChanged() - onServiceStateChanged()
Wifi	WifiManager - startScan() - getScanResults() - getConnectionInfo() - getConfiguredNetworks()      WifiAwareManager      WifiP2pManager      WifiRttManager
Bluetooth	BluetoothAdapter - startDiscovery() - startLeScan()      BluetoothAdapter.LeScanCallback      BluetoothLeScanner - startScan()

 

 

6. Foldable과 큰화면 기기들지원

Foldable과 대화면 기기들에 대한 지원이 되면서,

한번에 여러 Activity들이 resumed상태에 있을 수 있습니다.

대신 focus는 하나의 Activity만 같을 수 있겠지요.

이것은 onResume과 onPause에 변화를 가져올 수 있는데요.

topmost resumed라고하는 개념이 생기는것입니다.

다 resumed이지만 그중 focus를 가지는 Activity가 가지는 상태인데요.

이것은 onTopResumedActivityChanged()에서 구현할수있습니다.

 

 

 

6. 공식문서

위에서는 다룬 부분들은, 주요 앱들에서 짚고 넘어가야 한다는 부분들에 대해서 다루었는데요.

확인해봐야 할 부분은 사실 이보다 더 많이 있습니다.

 

이것은 공식문서에서 확인을 해 보아야 하는데요.

Android개발이 아닌, Google Play의 '전략 > 개발'에서 Target API Level섹션에서 확인할 수 있다는 점이 특징이네요.

>> developer.android.com/distribute/best-practices/develop/target-sdk

 

7. 정리

Android System버전이 올라갈때마다 UX가 획기적으로 좋아지기보다는,

개발하는데 신경쓰고 테스트해야하는 부분들이 늘어서 피로도가 조금 느껴지네요.

아무래도 Privacy나 효율성이 강조되기 때문이지요.

구글이 말했던 것처럼, 비즈니스로직에만 집중할 수 있도록 해 주었으면 좋겠다는 생각이 살짝 들었습니다.