minSdkVersion와 targetSdkVersion 정확하게 사용하기

목차

1. 소개

2. minSdkVersion

3. targetSdkVersion

4. maxSdkVersion

이 포스팅은 안드로이드 SDK Guides의 내용을 기반으로 작성되었습니다.

1. 소개

이클립스가 기본 IDE 였을 때에는 minSdkVersion, targetSdkVersion는 AndroidManifest.xml에 설정했습니다. 아래가 사용법입니다.

<uses-sdk android:minSdkVersion="integer"          android:targetSdkVersion="integer"          android:maxSdkVersion="integer" />

하지만 Android Studio로 넘어오면서 build.gradle 파일에 옮겨지게 되었습니다.

defaultConfig {   applicationId "com.tistory.kkangeva.materialdesign"   minSdkVersion 21   targetSdkVersion 22   versionCode 1   versionName "1.0" }

SdkVersion이라는 이름을 가지고 있지만 실제로 기입해야 하는 것은 API Level입니다. Android Platform의 버전도 아니구요. 차이점을 볼까요? 아래는 포스팅을 쓰는 날짜 기준으로 최신의 버전을 기입한 것입니다.

• SDK Version : installer_r24.3.3-windows.exe

• API Version : 22

• Android Platform Version : Android 5.1 (수정된 롤리팝 버전입니다~)

전혀 연관성이 없습니다. 참고로 API Level은 항상 양의 정수 값입니다.

2. minSdkVersion

안드로이드 앱이 실행될 수 있는 최소한의 API 레벨을 의미합니다. 만약에 앱이 선언해 놓은 버전보다 디바이스의 버전이 낮을 경우에는 앱이 인스톨되지 않습니다.

앱 개발시 필수적으로 선언해야 하는 필드이며 만약에 선언을 하지 않았을 경우 ‘1’이 디폴트로 선정됩니다.

3. targetSdkVersion

안드로이드 앱의 타겟 API 레벨을 의미합니다. 만약 선언이 되어 있지 않다면 minSdkVersion과 동일한 값으로 간주됩니다. ‘타겟 API’의 개념은 해당 앱이 개발시에 테스트 되어진 API 레벨을 의미합니다. 당연히 targetSdkVersion은 minSdkVersion 보다 같거나 높을 수 밖에 없습니다. 하지만 targetSdkVersion이 높다고 하더라도 앱은 minSdkVersion에서도 인스톨 및 실행할 수 있습니다.

그럼 targetSdkVersion은 언제 사용이 될까요?

당연하겠지만 안드로이드 API 버전이 올라가면서 플랫폼이 조금씩 바뀌게 됩니다. 아래의 상황을 가정해봅시다.

• App API Level : miSdkVersion : 4 / targetSdkVersion : 7

• Platform API level : 10

이 상황에서는 당연히 앱을 인스톨하고 실행하는데에 전혀 무리가 없습니다. 하지만 만약 안드로이드 API가 7버전에서 10버전으로 오면서 앱 실행과 관련된 API에 변경이 생겼다면 어떻게 될까요? 이 경우 앱의 실행이 개발자의 예상과 달라질 가능성이 있습니다. 때문에 안드로이드 플랫폼에서는 하위 호환성 관련 기능을 활성화를 시키고 앱을 실행시켜야 합니다. 즉, 최초 릴리즈시의 동작성을 최대한 보장하기 위해서 안드로이드 플랫폼에게 정보를 알려주는 역할을 담당하는 필드입니다.

앱을 유지보수 하는 입장에 대해서 이야기를 해봅시다. 신규 기능을 추가하지 않는 이상 minSdkVersion이 높아질 가능성은 없습니다. 하지만 버그 수정이나 로직 수정 등의 이유로 앱을 버전업 할 때, targetSdkVersion은 항상 업데이트 하는 게 좋습니다.

4. maxSdkVersion

안드로이드 앱이 실행될 수 있는 최대한의 API Level을 의미합니다. 지금까지의 지식을 바탕으로 앱은 [minSdkVersion ~ maxSdkVersion] 사이의 디바이스에 인스톨 및 실행이 가능하다는 거죠. 조금 더 알아봅시다.

아마도 API Level이 높아지면서 기존의 API들이 사라지거나 수정되는 것을 감안한 필드였을 것으로 생각됩니다. 하지만 이 필드는 아래의 문제점 및 제약사항을 가지고 있습니다.

• 향후 API가 어떻게 바뀔지 예측할 수 없으므로 앱을 개발하는 시점에서는 maxSdkVersion을 알 수 없습니다.

• ‘하위 호환성’은 유지하지 않는다는 주장과 동일합니다.

• 플랫폼이 안정화가 되면 하위 호환성을 유지하는 형태로 발전합니다. 따라서 이 필드는 일시적으로 사용될 가능성이 높습니다.

개발자 문서에서도 더이상 이 필드를 사용하지 말라고 합니다.

기존의 안드로이드 버전들에서는 (1.5, 1.6, 2.0, 2.0.1) 이 값을 앱 인스톨시에 사용했다고 합니다. 만약 플랫폼의 API Level이 maxSdkVersion 보다 높을 경우 인스톨이 거부되었습니다. 만약 소프트웨어 업데이트로 플랫폼의 버전을 높일 경우에도 이미 인스톨되어 있던 앱들을 뒤져서 maxSdkVersion이 낮은 앱을 제거 했었습니다. (생각해보면 인스톨 된 앱을 지워버리는 정책은 어이없는 것 같네요. 소프트웨어 업데이트를 했더니 잘 쓰고 있던 SNS가 지워진 상황이라니!)

하지만 최신의 안드로이드 버전에서는 (2.0.1 이후) 더이상 maxSdkVersion을 체크하지 않는다고 합니다. 심지어 maxSdkVersion이 설정되어 있으면 컴파일도 실패한다고 하네요. 하지만 이미 포함되어서 앱스토어에 올라가 있는 앱의 경우에는 구글 플레이 앱스토어에서 필터링에 사용된다고 합니다.