Android Min SDK 버전과 대상 SDK 버전

Android 용 애플리케이션을 개발할 때 Min과 Target SDK 버전의 차이점은 무엇입니까? Min과 Target 버전이 동일하지 않으면 Eclipse에서 새 프로젝트를 만들 수 없습니다!

android : minSdkVersion

응용 프로그램을 실행하는 데 필요한 최소 API 수준을 지정하는 정수입니다. 시스템의 API 레벨이이 속성에 지정된 값보다 낮은 경우 Android 시스템은 사용자가 애플리케이션을 설치하지 못하게합니다. 항상이 속성을 선언해야합니다.

android : targetSdkVersion

애플리케이션이 대상으로하는 API 레벨을 지정하는 정수입니다.

이 속성을 설정하면 응용 프로그램에서 이전 버전 (minSdkVersion까지)에서 실행할 수 있지만 여기에 지정된 버전에서 작동하도록 명시 적으로 테스트되었습니다. 이 대상 버전을 지정하면 플랫폼에서 대상 버전에 필요하지 않은 호환성 설정을 비활성화하거나 (앞으로 호환성을 유지하기 위해 켜질 수 있음) 이전 응용 프로그램에서 사용할 수없는 새로운 기능을 활성화 할 수 있습니다. 그렇다고 플랫폼의 다른 버전에 대해 서로 다른 기능을 프로그래밍 할 수 있다는 의미는 아닙니다. 단순히 대상 버전에 대해 테스트 한 플랫폼을 플랫폼에 알리고 플랫폼은 대상 버전과의 호환성을 유지하기 위해 추가 작업을 수행해서는 안됩니다.

자세한 내용은 다음 URL을 참조하십시오.

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

OP에 의해 질문에 게시 된 의견 (기본적으로 targetSDK가 앱 컴파일에 영향을 미치지 않는다고 명시 함)은 완전히 잘못되었습니다! 무딘 죄송합니다.

간단히 말해, 다음은 minSDK와 다른 targetSDK를 선언하는 목적입니다. 즉, 최소 수준보다 높은 수준의 SDK 기능을 사용하지만 이전 버전과의 호환성 을 보장해야합니다 . 다시 말해, 최근에 소개되었지만 기능에 중요하지 않은 기능을 사용한다고 가정하십시오. 그런 다음 targetSDK를이 새로운 기능이 도입 된 버전으로 설정하고 모든 사람이 여전히 앱을 사용할 수 있도록 최소값을 낮게 설정하십시오.

예를 들어, 제스처 감지를 광범위하게 사용하는 앱을 작성한다고 가정 해 봅시다. 그러나 제스처로 인식 할 수있는 모든 명령은 버튼이나 메뉴에서 수행 할 수도 있습니다. 이 경우 제스처는 '쿨 엑스트라'이지만 필수는 아닙니다. 따라서 대상 SDK를 7 (GestureDetection 라이브러리가 도입 된 경우 "Eclair")로 설정하고 최소 SDK를 레벨 3 ( "Cupcake")으로 설정하여 전화가 오래된 사람도 앱을 사용할 수 있습니다. 필요한 경우 제스처 라이브러리를 사용하기 전에 앱에서 실행중인 Android 버전을 확인했는지 확인하십시오 (존재하지 않은 경우 사용하지 마십시오). (아직도 아직 v1.5 전화를 가지고있는 사람이 거의 없기 때문에이 예제는 날짜가 있지만 v1과의 호환성을 유지할 때가있었습니다.

다른 예를 들기 위해 Gingerbread 또는 Honeycomb의 기능을 사용하려는 경우이를 사용할 수 있습니다. 어떤 사람들은 곧 업데이트를받을 것이지만, 다른 사람들, 특히 오래된 하드웨어를 가진 사람들은 새로운 기기를 구입할 때까지 Eclair에 갇혀있을 수 있습니다. 이를 통해 시장의 일부를 배제하지 않고 멋진 새로운 기능을 사용할 수 있습니다.

안드로이드 개발자의 블로그 에서 정말 좋은 기사가 있습니다. 이 기능을 사용하는 방법에 대한, 그리고 특히, 어떻게 내가 위에서 언급 한 코드를 "기능은 사용하기 전에 존재 확인"설계.

OP에 : 나는 당신의 질문이 오래 전에 요청 된 것을 알기 때문에 미래 에이 질문에 걸려 넘어지는 사람의 이익을 위해 이것을 주로 썼습니다.

targetSdkVersion = "xx"를 설정하면 API 수준 xx에서 앱이 제대로 작동하는지 (예 : 철저하고 성공적으로 테스트 된 것)임을 인증하는 것입니다.

xx 이상의 API 수준에서 실행되는 Android 버전은 호환성 수준을 자동으로 적용하여 API 수준 xx 이전 또는 이후에 사용 가능했던 기능을 지원하지만 이제 해당 Android 버전의 상위 수준에서는 더 이상 사용되지 않습니다.

당신은 쓸모가되었다 어떤 기능을 사용하는 경우 반대로 에서 또는 이전 수준의 XX에를, 호환성 코드가됩니다 없습니다 자동으로 그 사용을 지원하기 위해 (결코 더 이상 그 기능을 포함하는 것이) 더 높은 API 수준에서 OS 버전에 적용 할 수. 그 상황에서, 자신의 코드가 테스트 API 레벨과, OS 레벨이 감지 경우가 더 이상은, 코드가 다른 기능 주어진 API 기능을 사용해야합니다 것을 더 하나라고 특별한 경우 조항이 있어야 있습니다 실행중인 운영 체제의에서 사용할 수를 API 레벨.

이를 수행하지 않으면 코드 내에서 일반적으로 이벤트를 트리거하는 일부 인터페이스 기능이 나타나지 않고 사용자가 해당 이벤트를 트리거하고 해당 기능에 액세스해야하는 중요한 인터페이스 기능이 누락 될 수 있습니다 ( 아래 예).

다른 답변에서 언급했듯이 minSdkVersion보다 높은 API 수준에서 초기에 정의 된 일부 API 기능을 사용하고 코드가 해당 기능의 부재를 감지하고 처리 할 수 ​​있도록 조치를 취한 경우 targetSdkVersion을 minSdkVersion보다 높게 설정할 수 있습니다 targetSdkVersion보다 낮은 수준입니다.

개발자가 기능을 사용하는 데 필요한 최소 API 레벨을 구체적으로 테스트하도록 경고하기 위해, 코드에 minSdkVersion 이후의 API 레벨에서 정의 된 메소드에 대한 호출이 코드에 포함 된 경우 컴파일러는 경고 만 아니라 오류를 발행합니다. targetSdkVersion이 해당 메소드를 처음 사용할 수있는 API 레벨 이상인 경우에도 마찬가지입니다. 이 오류를 제거하려면 컴파일러 지시문

@TargetApi(nn)

컴파일러에게 지시문의 범위 내 (메소드 또는 클래스 앞에 오는) 코드가 적어도 API 레벨을 갖는 것에 의존하는 메소드를 호출하기 전에 적어도 nn의 API 레벨을 테스트하도록 작성되었음을 알립니다. . 예를 들어 다음 코드는 minSdkVersion이 11 미만이고 targetSdkVersion이 11 이상인 앱 내 코드에서 호출 할 수있는 메서드를 정의합니다.

@TargetApi(11)
    public void refreshActionBarIfApi11OrHigher() {
      //If the API is 11 or higher, set up the actionBar and display it
      if(Build.VERSION.SDK_INT >= 11) {
        //ActionBar only exists at API level 11 or higher
        ActionBar actionBar = getActionBar();

        //This should cause onPrepareOptionsMenu() to be called.
        // In versions of the API prior to 11, this only occurred when the user pressed 
        // the dedicated menu button, but at level 11 and above, the action bar is 
        // typically displayed continuously and so you will need to call this
        // each time the options on your menu change.
        invalidateOptionsMenu();

        //Show the bar
        actionBar.show();
    }
}

minSdkVersion보다 높은 API 레벨의 기능을 사용 하지 않더라도 더 높은 레벨에서 테스트했으며 모든 것이 작동 한 경우 더 높은 targetSdkVersion을 선언 할 수도 있습니다 . 이는 테스트를 통해 해당 적응이 필요하지 않음을 확인했기 때문에 대상 레벨에서 최소 레벨까지 적응하려는 호환성 코드에 액세스하는 오버 헤드를 피하기위한 것입니다.

선언 된 targetSdkVersion에 의존하는 UI 기능의 예는 해당 앱이 API 11 이상에서 실행될 때 targetSdkVersion이 11 미만인 앱의 상태 표시 줄에 나타나는 3 개의 수직 점 메뉴 버튼입니다. 앱의 targetSdkVersion이 10 이하인 경우 앱의 인터페이스가 전용 메뉴 버튼의 존재에 의존한다고 가정하므로 3 점 버튼은 이전 전용 하드웨어 및 / 또는 화면 버전을 대신하는 것으로 보입니다. OS에 더 높은 API 레벨이있는 ​​경우 해당 버튼 (예 : Gingerbread에 표시)의 더 이상 사용하지 않는 경우에는 해당 장치의 전용 메뉴 버튼이 더 이상 가정되지 않습니다. 그러나 앱의 targetSdkVersion을 11 이상으로 설정하면 해당 수준에서 도입 된 기능을 이용하여 전용 메뉴 버튼을 대체한다고 가정합니다 (예 : g., 작업 표시 줄) 또는 시스템 메뉴 버튼이 필요하지 않은 경우 결과적으로, 3 개의 수직 점 메뉴 "호환성 버튼"이 사라집니다. 이 경우 사용자가 메뉴 버튼을 찾을 수 없으면 메뉴 버튼을 누를 수 없으며, 따라서 액티비티의 onCreateOptionsMenu (menu) 재정의가 절대로 호출되지 않을 수 있음을 의미합니다. 앱 기능의 상당 부분에 사용자 인터페이스가 박탈 될 수 있습니다. 물론, 사용자가 이러한 기능에 액세스 할 수있는 작업 표시 줄 또는 다른 대체 수단을 구현하지 않은 경우. 메뉴 버튼을 찾지 못하면 메뉴 버튼을 누를 수 없으므로 활동의 onCreateOptionsMenu (menu) 재정의가 절대 호출되지 않을 수 있으며 이는 다시 앱 기능의 중요한 부분이 될 수 있음을 의미합니다. 사용자 인터페이스가 없습니다. 물론, 사용자가 이러한 기능에 액세스 할 수있는 작업 표시 줄 또는 다른 대체 수단을 구현하지 않은 경우. 메뉴 버튼을 찾지 못하면 메뉴 버튼을 누를 수 없으므로 활동의 onCreateOptionsMenu (menu) 재정의가 절대 호출되지 않을 수 있으며 이는 다시 앱 기능의 중요한 부분이 될 수 있음을 의미합니다. 사용자 인터페이스가 없습니다. 물론, 사용자가 이러한 기능에 액세스 할 수있는 작업 표시 줄 또는 다른 대체 수단을 구현하지 않은 경우.

반대로 minSdkVersion은 장치의 OS 버전이 앱을 실행하기 위해 API 수준 이상이어야한다는 요구 사항을 나타냅니다. 이는 Google Play 앱 스토어 (및 다른 앱 스토어)에있을 때 앱을보고 다운로드 할 수있는 기기에 영향을줍니다. 앱이 해당 수준에서 설정된 OS (API 또는 기타) 기능에 의존하고 해당 기능의 부재를 처리 할 수있는 적절한 방법이 없다는 것을 나타내는 방법입니다.

API와 관련 되지 않은 기능이 있는지 확인하기 위해 minSdkVersion을 사용하는 예는 JIT 사용 버전의 Dalvik 인터프리터에서만 앱이 실행되도록하기 위해 minSdkVersion을 8로 설정하는 것입니다 (JIT가 도입 된 이후) API 레벨 8에서 Android 인터프리터로). JIT 지원 인터프리터의 성능은 해당 기능이없는 것의 5 배에 달할 수 있으므로 앱이 프로세서를 많이 사용하는 경우 적절한 성능을 보장하기 위해 API 레벨 8 이상이 필요할 수 있습니다.

항상 예제를 통해 개념을 더 잘 전달할 수 있습니다 . 안드로이드 프레임 워크 소스 코드를 파고 안드로이드 개발자 사이트 및 관련 스택 오버 플로우 스레드의 모든 문서를 읽은 후에도 몇 가지 실험을 수행 할 때 까지이 개념을 이해하는 데 어려움이있었습니다. 이 개념을 완전히 이해하는 데 도움이되는 두 가지 예를 들겠습니다.

DatePickerDialog은 당신이 (의 AndroidManifest.xml 파일의 targetSdkVersion을에 넣어 수준에 따라 다르게 나타납니다 <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>). 값을 10 이하로 설정하면 DatePickerDialog가 왼쪽처럼 보입니다. 반면에 값을 11 이상으로 설정하면 DatePickerDialog가 동일한 코드로 올바르게 표시 됩니다.

이 샘플을 만들 때 사용한 코드는 매우 간단합니다. MainActivity.java외모 :

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    public void onClickButton(View v) {
        DatePickerDialog d = new DatePickerDialog(this, null, 2014, 5, 4);
        d.show();       
    }
}

그리고 activity_main.xml보인다 :

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
<Button
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="onClickButton"
    android:text="Button" />
</RelativeLayout>

그게 다야. 이것이 실제로 이것을 테스트하는 데 필요한 모든 코드입니다.

안드로이드 프레임 워크 소스 코드 를 볼 때이 모양의 변화는 분명하다 . 다음과 같습니다.

public DatePickerDialog(Context context,
    OnDateSetListener callBack,
    int year,
    int monthOfYear,
    int dayOfMonth,
    boolean yearOptional) {
        this(context, context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.HONEYCOMB
                ? com.android.internal.R.style.Theme_Holo_Light_Dialog_Alert
                : com.android.internal.R.style.Theme_Dialog_Alert,
        callBack, year, monthOfYear, dayOfMonth, yearOptional);
}

보시다시피 프레임 워크는 현재 targetSDKversion을 가져오고 다른 테마를 설정합니다. 이러한 종류의 코드 스 니펫 ( getApplicationInfo().targetSdkVersion >= SOME_VERSION)은 Android 프레임 워크에서 여기 저기에서 찾을 수 있습니다.

또 다른 예는 WebView 클래스입니다. WebSD 클래스의 공개 메소드는 기본 스레드에서 호출해야하며 그렇지 않은 경우 RuntimeExceptiontargetSDKversion 18 이상을 설정하면 런타임 시스템 에서을 발생시킵니다. 이 동작은 소스 코드 와 함께 명확하게 전달 될 수 있습니다 . 그런 식으로 작성되었습니다.

sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >=
            Build.VERSION_CODES.JELLY_BEAN_MR2;

if (sEnforceThreadChecking) {
    throw new RuntimeException(throwable);
}

안드로이드 의사 는 " Android가 새로운 버전마다 진화함에 따라 일부 동작과 모양이 바뀔 수 있습니다"라고 말합니다. 그래서 우리는 행동과 외모의 변화와 그 변화가 어떻게 이루어지는 지 보았습니다.

요약하자면, Android 문서에 " 이 속성 (targetSdkVersion)은 시스템에 대상 버전에 대해 테스트했음을 알려주며, 시스템이 앱의 대상 버전과 의 호환성 을 유지하기 위해 호환성 동작 을 활성화해서는 안됩니다 . ". 이것은 WebView 사례에서 분명합니다. JELLY_BEAN_MR2가 릴리스되어 메인 스레드가 아닌 스레드에서 WebView 클래스의 공용 메소드를 호출 할 때까지는 정상이었습니다. Android 프레임 워크가 JELLY_BEAN_MR2 장치에서 RuntimeException을 발생시키는 경우에는 말이되지 않습니다. 단지 새로 도입 된 행동으로 인해 관심을 가질 수 없어 치명적인 결과를 초래할 수 있습니다. 따라서 우리가해야 할 일은 특정 targetSDKversions에서 모든 것이 정상인지 확인하는 것입니다. 더 높은 targetSDKversion을 설정하여 모양 향상과 같은 이점을 얻습니다.

편집 : 면책 조항. 현재 targetSDKversion (위에 표시된)을 기반으로 다른 테마를 설정 한 DatePickerDialog 생성자가 실제로 나중에 commit 에서 변경되었습니다 . 그럼에도 불구하고 논리가 변경되지 않았기 때문에이 예제를 사용했으며 해당 코드 스 니펫은 targetSDKversion 개념을 명확하게 보여줍니다.

요약을 원하는 사람들에게는

android:minSdkVersion

응용 프로그램이 지원할 때까지 최소 버전입니다. 기기에 android 버전이 더 낮 으면 앱이 설치되지 않습니다.

동안,

android:targetSdkVersion

앱이 실행될 때까지 API 수준입니다. 즉,이 API까지 테스트했기 때문에 휴대 전화 시스템은 호환성 동작을 사용하여 호환성을 유지하지 않아도됩니다.

앱은 여전히 ​​주어진 버전보다 높은 Android 버전에서 실행 targetSdkVersion되지만 Android 호환성 동작이 시작됩니다.

공짜-

android:maxSdkVersion

기기의 API 버전이 더 높으면 앱이 설치되지 않습니다. 즉. 앱을 설치할 수있는 최대 API입니다.

즉. MinSDK -4, maxSDK-8, targetSDK-8의 경우 내 앱은 최소 1.6에서 작동하지만 2.2에서만 지원되는 기능을 사용했으며 2.2 장치에 설치된 경우 표시됩니다. 또한 maxSDK-8의 경우이 앱은 API> 8을 사용하는 전화기에 설치되지 않습니다.

이 답변을 작성할 당시 Android 설명서는 설명에 큰 도움이되지 않았습니다. 이제 잘 설명되어 있습니다. 여기서 확인하십시오

예를 들어 컴파일 오류가 발생하는 경우 :

<uses-sdk
            android:minSdkVersion="10"
            android:targetSdkVersion="15" />

.

private void methodThatRequiresAPI11() {
        BitmapFactory.Options options = new BitmapFactory.Options();
                options.inPreferredConfig = Config.ARGB_8888;  // API Level 1          
                options.inSampleSize = 8;    // API Level 1
                options.inBitmap = bitmap;   // **API Level 11**
        //...
    }

컴파일 오류가 발생합니다.

필드에는 API 레벨 11이 필요합니다 (현재 최소값은 10 임) : android.graphics.BitmapFactory $ Options # inBitmap

ADT (Android Development Tools) 버전 17 이후 @TargetApi로이 문제를 매우 쉽게 해결할 수있는 새롭고 유용한 주석 이 있습니다. 문제가있는 선언을 둘러싸고있는 메소드 앞에 추가하십시오.

@TargetApi
private void methodThatRequiresAPI11() {            
  BitmapFactory.Options options = new BitmapFactory.Options();
      options.inPreferredConfig = Config.ARGB_8888;  // API Level 1          
      options.inSampleSize = 8;    // API Level 1

      // This will avoid exception NoSuchFieldError (or NoSuchMethodError) at runtime. 
      if (Integer.valueOf(android.os.Build.VERSION.SDK) >= android.os.Build.VERSION_CODES.HONEYCOMB) {
        options.inBitmap = bitmap;   // **API Level 11**
            //...
      }
    }

지금 컴파일 오류가 없으며 실행됩니다!

편집 : 11보다 낮은 API 수준에서 런타임 오류가 발생합니다. 11 이상에서는 문제없이 실행됩니다. 따라서 버전 확인으로 보호되는 실행 경로에서이 메소드를 호출해야합니다. TargetApi는 컴파일 만 가능하지만 사용자는 스스로 위험을 감수해야합니다.

android:minSdkVersion그리고 android:targetSdkVersion둘 다 안드로이드 매니페스트 파일에서 선언 해야하는 정수 값이지만 둘 다 다른 속성을 가지고 있습니다.

android:minSdkVersion:이것은 안드로이드 앱을 실행하는 데 필요한 최소 API 수준입니다. 더 낮은 API 버전에 동일한 앱을 설치하면 파서 오류가 표시되고 응용 프로그램을 지원하지 않는 문제가 나타납니다.

android:targetSdkVersion:Target SDK 버전은 앱의 Target API 수준을 설정하는 것입니다. 이 속성이 매니페스트에서 선언되지 않으면 minSdk 버전이 TargetSdk 버전이됩니다. 이것은 항상 "앱이 TargetSdk 버전으로 선언 된 모든 상위 버전의 API에 설치를 지원"한다는 사실입니다. 앱을 제한된 대상으로 만들려면 매니페스트 파일에서 maxSdkVersion을 선언해야합니다.

위험한 권한 이 필요한 앱을 만들고 targetSDK를 23 이상으로 설정하는 경우주의해야합니다. 런타임에 권한을 확인하지 않으면 SecurityException이 발생하고 try 블록 내에서 코드를 사용하는 경우 (예 : 열린 카메라) logcat을 확인하지 않으면 오류를 감지하기가 어려울 수 있습니다.

대상 SDK는 타겟팅하려는 버전이며 최소 SDK는 최소 버전입니다.