Android Min SDKバージョンとターゲットSDKバージョン

Android用のアプリケーションの開発に関して、MinとTarget SDKのバージョンの違いは何ですか？Eclipseでは、最小バージョンとターゲットバージョンが同じでない限り、新しいプロジェクトを作成できません。

android：minSdkVersion

アプリケーションの実行に必要な最小APIレベルを指定する整数。Androidシステムは、システムのAPIレベルがこの属性で指定された値よりも低い場合、ユーザーがアプリケーションをインストールできないようにします。この属性は常に宣言する必要があります。

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」）に設定し、minimumSDKをレベル3（「Cupcake」）に設定して、本当に古い電話を持っている人でもアプリを使用できるようにします。必要なことは、ジェスチャーライブラリを使用する前に、アプリが実行されていたAndroidのバージョンを確認して、存在しない場合に使用しないようにすることだけです。（確かにこれは古いバージョンの例です。ほとんどの人がまだv1.5電話を持っているためですが、v1との互換性を維持する時期がありました。

別の例として、ジンジャーブレッドまたはハニカムの機能を使用したい場合にこれを使用できます。一部の人はすぐにアップデートを入手しますが、他の多くの人、特に古いハードウェアを使用している人は、新しいデバイスを購入するまでEclairに行き詰まっている可能性があります。これにより、クールな新機能の一部を使用できるようになりますが、可能な市場の一部を除外することはありません。

この機能の使用方法、特に上記の「使用前に機能が存在するかどうかを確認する」コードの設計方法については、Android開発者のブログからの非常に優れた記事があります。

OPに：私は、あなたの質問がずっと前に尋ねられたことに気付いたので、主にこれを将来この質問に偶然遭遇した人のために書いた。

targetSdkVersion = "xx"を設定すると、アプリがAPIレベルxxで適切に機能する（たとえば、十分にテストされ、正常にテストされた）ことを保証します。

xx より上の APIレベルで実行されているAndroidのバージョンでは、互換性コードが自動的に適用され、APIレベルxx以前で利用可能であったが、現在Androidバージョンの上位レベルでは廃止されている機能に対応しています。

逆に、あなたは時代遅れになったすべての機能を使用している場合で、または前になるレベルXX、互換性のコードにはない、それらの用途をサポートするために、（もはやこれらの機能が含まれていないこと）を自動的高いAPIレベルでのOSのバージョンによって適用されることに。そのような状況では、独自のコードにAPIレベルをテストする特別なcase句が必要であり、検出されたOSレベルが特定のAPI機能を持たないより高いものである場合、実行中のOSで利用可能な代替機能をコードで使用する必要がありますAPIレベル。

これに失敗した場合、通常はコード内のイベントをトリガーするいくつかのインターフェイス機能が表示されない可能性があり、ユーザーがそれらのイベントをトリガーして機能にアクセスするために必要な重要なインターフェイス機能がない可能性があります（以下の例）。

他の回答で述べたように、minSdkVersionよりも高いAPIレベルで最初に定義された一部のAPI機能を使用する場合、およびコードがそれらの機能の不在を検出して処理できることを確認するための措置を講じていた場合、minSdkVersionよりも高いtargetSdkVersionを設定できます。 targetSdkVersionよりも低いレベル。

機能を使用するために必要な最小APIレベルを具体的にテストするように開発者に警告するために、minSdkVersionより後のAPIレベルで定義されたメソッドの呼び出しがコードに含まれている場合、コンパイラーはエラー（警告だけでなく）を発行します。 targetSdkVersionが、そのメソッドが最初に使用可能になったときのAPIレベル以上であっても。このエラーを削除するには、コンパイラディレクティブ

@TargetApi(nn)

そのディレクティブのスコープ内のコード（メソッドまたはクラスの前にある）が少なくともnnのAPIレベルをテストするために記述されてから、少なくともその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();
    }
}

あなたは可能性も、あなたがより高いレベルでテストされていたし、すべてが働いていた場合、あなたがた場合でも、高いtargetSdkVersionを宣言したいない高いあなたのminSdkVersionがよりAPIレベルから任意の機能を使用します。これは、ターゲットレベルから最小レベルに適応することを目的とした互換性コードにアクセスするオーバーヘッドを回避するためのものです。そのような適応が必要ないことを（テストを通じて）確認したためです。

宣言されたtargetSdkVersionに依存するUI機能の例は、11未満のtargetSdkVersionのアプリがAPI 11以降で実行されている場合にステータスバーに表示される縦に3つ並んだメニューボタンです。アプリのtargetSdkVersionが10以下の場合、アプリのインターフェースは専用メニューボタンの存在に依存していると想定されるため、3つのドットのボタンが以前の専用ハードウェアや画面上のバージョンの代わりに表示されます。 OSのAPIレベルが高く、デバイスの専用メニューボタンが想定されなくなった場合に、そのボタン（たとえば、Gingerbreadに表示される）の。ただし、アプリのtargetSdkVersionを11以上に設定すると、そのレベルで導入された専用のメニューボタンに代わる機能（e。g。、アクションバー）、またはシステムメニューボタンの必要性を回避した場合。その結果、縦に3つ並んだドットのメニュー「互換性ボタン」が消えます。その場合、ユーザーがメニューボタンを見つけることができない場合、ユーザーはそれを押すことができません。つまり、ユーザーのアクティビティのonCreateOptionsMenu（menu）オーバーライドが呼び出されない可能性があります。これもまた、アプリの機能の大部分がユーザーインターフェースを奪われている可能性があります。もちろん、ユーザーがこれらの機能にアクセスするためのアクションバーまたはその他の代替手段を実装していない限り、メニューボタンが見つからない場合、ボタンを押すことができません。つまり、アクティビティのonCreateOptionsMenu（menu）オーバーライドが呼び出されない可能性があります。これも、アプリの機能の重要な部分がそのユーザーインターフェースを奪われた。もちろん、ユーザーがこれらの機能にアクセスするためのアクションバーまたはその他の代替手段を実装していない限り、メニューボタンが見つからない場合、ボタンを押すことができません。つまり、アクティビティのonCreateOptionsMenu（menu）オーバーライドが呼び出されない可能性があります。これも、アプリの機能の重要な部分がそのユーザーインターフェースを奪われた。もちろん、ユーザーがこれらの機能にアクセスするためのアクションバーまたはその他の代替手段を実装していない限り、

対照的に、minSdkVersionは、アプリを実行するために、デバイスのOSバージョンが少なくともそのAPIレベルを持っているという要件を述べています。これは、アプリがGoogle Playアプリストア（および場合によっては他のアプリストア）にあるときに、アプリを表示およびダウンロードできるデバイスに影響します。これは、アプリがそのレベルで確立されたOS（APIまたはその他）の機能に依存しており、それらの機能の欠如に対処するための許容できる方法がないことを示す方法です。

APIに関連しない機能の存在を確認するためにminSdkVersionを使用する例は、アプリがDalvikインタープリターのJIT対応バージョンでのみ実行されるようにするためにminSdkVersionを8に設定することです（JITが導入されたため） APIレベル8のAndroidインタープリターに）。JIT対応のインタープリターのパフォーマンスは、その機能のないインタープリターの5倍にもなる可能性があるため、アプリがプロセッサーを大量に使用する場合は、適切なパフォーマンスを確保するためにAPIレベル8以上が必要になる場合があります。

概念は、常に、例を使用してより適切に提供できます。Android開発者サイトのすべてのドキュメントと関連するStackoverflowスレッドを読んだ後でも、Androidフレームワークのソースコードを掘り下げて実験を行うまで、これらの概念を理解するのに苦労しました。これらの概念を完全に理解するのに役立つ2つの例を紹介します。

A 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>

それでおしまい。これは、私がこれをテストするために必要なすべてのコードです。

そして、Androidフレームワークのソースコードを見ると、この外観の変化は非常に明確です。それは次のようになります：

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クラスに関するものです。メインスレッドでWebviewクラスのパブリックメソッドを呼び出す必要があります。そうでない場合、RuntimeExceptiontargetSDKバージョン18以上を設定すると、ランタイムシステムはをスローします。この動作は、ソースコードとともに明確に提供できます。そのように書かれているだけです。

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

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

Androidのドキュメントには、「Androidが新しいバージョンごとに進化するにつれて、一部の動作や外観さえも変わる可能性があります」と書かれています。そのため、動作と外観の変更、およびその変更がどのように行われるかを調べました。

要約すると、Androidドキュメントは「この属性（targetSdkVersion）は、ターゲットバージョンに対してテストしたことをシステムに通知し、システムは互換性動作を有効にして、アプリのターゲットバージョンとの前方互換性を維持することはできません。」と述べています。これは、WebViewのケースで非常に明確です。JELLY_BEAN_MR2が解放され、メインスレッドではないWebViewクラスのパブリックメソッドを呼び出すまでは問題ありませんでした。AndroidフレームワークがJELLY_BEAN_MR2デバイスでRuntimeExceptionをスローするのは無意味です。新たに導入された動作を有効にして、致命的な結果をもたらすべきではありません。したがって、特定のtargetSDKバージョンですべてが正常かどうかを確認する必要があります。targetSDKversionを高く設定すると、外観が向上するなどのメリットがあります。

編集：免責事項。現在のtargetSDKversion（上記で示したもの）に基づいて異なるテーマを設定するDatePickerDialogコンストラクターは、実際には後のcommitで変更されています。それにもかかわらず、ロジックは変更されておらず、それらのコードスニペットはtargetSDKversionの概念を明確に示しているため、私はその例を使用しました。

要約をしたい人のために、

android:minSdkVersion

アプリケーションがサポートするまでの最小バージョンです。お使いのデバイスのAndroidのバージョンが低い場合、アプリはインストールされません。

その間、

android:targetSdkVersion

アプリが実行するように設計されるまでのAPIレベルです。つまり、このAPIまでテストしたので、携帯電話のシステムは上位互換性を維持するために互換性動作を使用する必要はありません。

アプリは指定されtargetSdkVersionたバージョンよりも高いバージョンのAndroidで引き続き実行されますが、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

Android開発ツール（ADT）のバージョン17以降、@TargetApiこれを簡単に修正できる非常に便利な新しいアノテーションが1つあります。問題のある宣言を囲んでいるメソッドの前に追加します。

@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**
            //...
      }
    }

今コンパイルエラーはなく、実行されます！

編集：これにより、APIレベル11未満でランタイムエラーが発生します。11以上では、問題なく実行されます。したがって、バージョンチェックによって保護された実行パスでこのメソッドを呼び出す必要があります。TargetApiはコンパイルすることを許可するだけですが、自己責任で実行してください。

android:minSdkVersionそして、 android:targetSdkVersionの両方が、私たちは、Androidマニフェストファイルで宣言する必要がありますが、両者が異なる性質を持つている整数値です。

android:minSdkVersion:これは、Androidアプリを実行するために最低限必要なAPIレベルです。低いAPIバージョンに同じアプリをインストールすると、パーサーエラーが表示され、アプリケーションをサポートしていない問題が表示されます。

android:targetSdkVersion:ターゲットSDKバージョンは、アプリのターゲットAPIレベルを設定することです。この属性がマニフェストで宣言されていない場合、minSdkバージョンはTargetSdkバージョンになります。これは「TargetSdkバージョンとして宣言したすべての上位バージョンのAPIへのアプリサポートインストール」に当てはまります。アプリを限定ターゲットにするために、マニフェストファイルでmaxSdkVersionを宣言する必要があります...

危険な権限が必要なアプリを作成し、targetSDKを23以上に設定する場合は注意が必要です。ランタイムの権限をチェックしないとSecurityExceptionが発生し、tryブロック内でコードを使用している場合（オープンカメラなど）、logcatをチェックしないとエラーを検出するのが難しい場合があります。

ターゲットsdkはターゲットにするバージョンで、最小sdkは最小バージョンです。