Android用のアプリケーション開発に関して、MinとTarget SDKのバージョンの違いは何ですか? MinとTargetのバージョンが同じでない限り、Eclipseは私に新しいプロジェクトを作成させません。
アンドロイド: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よりも上位レベルのSDKの機能を使用していますが、後方互換性の確保言い換えれば、ごく最近導入された機能を使用したいが、それがアプリケーションにとって重要ではないとします。その後、targetSDKをこの新機能が導入されたバージョンに設定し、最小値をそれより低い値に設定して、全員が引き続きアプリを使用できるようにします。
例を挙げると、ジェスチャー検出を多用するアプリを書いているとしましょう。ただし、ジェスチャによって認識できるすべてのコマンドは、ボタンまたはメニューからも実行できます。この場合、ジェスチャーは「クールな追加機能」ですが、必須ではありません。そのため、ターゲットのsdkを7(GestureDetectionライブラリが導入されたときは "Eclair")に設定し、minimumSDKをレベル3( "Cupcake")に設定して、本当に古い電話を使っている人でもアプリを使用できるようにします。ジェスチャライブラリを使用する前に、実行していたAndroidのバージョンを確認し、存在しない場合は使用しないようにする必要があります。 (確かに、これは日付付きの例ですが、まだv1.5の携帯電話を持っている人はほとんどいませんが、v1.5との互換性を維持することが本当に重要なときがありました。)
別の例を挙げると、GingerbreadまたはHoneycombの機能を使用したい場合はこれを使用できます。すぐにアップデートを入手する人もいますが、特に古いハードウェアを使用する人の多くは、新しいデバイスを購入するまでEclairにとどまる可能性があります。これにより、可能性のある市場の一部を除外することなく、いくつかのクールな新機能を使用できます。
Android開発者のブログ からこの機能の使い方、特に「以前にその機能が存在することを確認する」の設計方法についての非常に良い記事があります。それを使用する "私は上記のコード。
OPに:私はあなたの質問がずっと前に聞かれたことを理解しているので、私は主に将来この質問に偶然出会う誰かの利益のためにこれを書いた。
TargetSdkVersion = "xx"を設定すると、APIレベルxxでアプリが適切に動作すること(たとえば、完全かつ正常にテストされていること)が保証されます。
APIレベルabovexxで実行されるAndroidのバージョンは、信頼性のある機能をサポートするために互換性コードを自動的に適用しますAPIレベルxx以前で利用可能でしたが、現在Androidバージョンの上位レベルでは廃止されています。
逆に、廃止された機能を使用している場合atまたはpriorレベルxxまで、互換性コードはnotより高いAPIレベル(これらの機能を含まない)のOSバージョンによってそれらの使用をサポートするために自動的に適用されます。その状況では、独自のコードにAPIレベルをテストする特別なcase句が必要であり、検出されたOSレベルが特定のAPI機能を持たないより高いレベルである場合、コードはareは、実行中のOSの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();
}
}
alsoその高いレベルでテストし、すべてが機能していれば、notminSdkVersionよりも高いAPIレベルの機能を使用しません。これは、ターゲットレベルから最小レベルに適応することを目的とした互換性コードにアクセスするオーバーヘッドを回避するためです。そのような適応は不要であることを(テストを通じて)確認したからです。
宣言されたtargetSdkVersionに依存するUI機能の例は、それらのアプリがAPI 11以降で実行されているときに、11未満のtargetSdkVersionを持つアプリのステータスバーに表示される3つの垂直ドットメニューボタンです。アプリのtargetSdkVersionが10以下の場合、アプリのインターフェイスは専用のメニューボタンの存在に依存していると想定されるため、3つのドットボタンが以前の専用のハードウェアやオンスクリーンバージョンの代わりに表示されますOSのAPIレベルが高く、デバイスの専用メニューボタンがもはや想定されていない場合、そのボタンの(たとえば、Gingerbreadで見られる)。ただし、アプリのtargetSdkVersionを11以上に設定する場合、そのレベルで導入された専用メニューボタン(アクションバーなど)を置き換える機能を利用したか、そうでなければ必要性を回避したと想定されますシステムメニューボタンがあります。その結果、3つの垂直ドットメニューの「互換性ボタン」が消えます。その場合、ユーザーがメニューボタンを見つけられない場合、ユーザーはそれを押すことができません。つまり、アクティビティのonCreateOptionsMenu(menu)オーバーライドが呼び出されない可能性があることを意味します。アプリの機能の大部分がユーザーインターフェースを奪われる可能性があります。もちろん、ユーザーがこれらの機能にアクセスするためのアクションバーまたはその他の代替手段を実装していない限り。
対照的に、minSdkVersionは、アプリを実行するために、デバイスのOSバージョンに少なくともそのAPIレベルが必要であることを示しています。これは、Google Playアプリストア(および場合によっては他のアプリストア)にあるアプリを表示およびダウンロードできるデバイスに影響します。これは、アプリがそのレベルで確立されたOS(APIまたはその他の)機能に依存していることを示す方法であり、それらの機能の欠如に対処するための許容できる方法はありません。
MinSdkVersionを使用してnotAPI関連の機能の存在を確認する例は、アプリを確実に実行するためにminSdkVersionを8に設定することです。 JIT対応バージョンのDalvikインタープリターでのみ実行されます(JITはAPIレベル8でAndroidインタープリターに導入されたため)。 JIT対応のインタープリターのパフォーマンスは、その機能を持たないインタープリターの5倍になる可能性があるため、アプリでプロセッサーを大量に使用する場合は、適切なパフォーマンスを確保するためにAPIレベル8以上が必要になる場合があります。
概念は、例を使用してより適切に配信できます。常にです。私は、Androidフレームワークのソースコードを掘り下げるまでこれらの概念を理解するのに苦労し、そしてAndroid開発者サイトおよび関連するstackoverflowスレッドの中のすべての文書を読んだ後でさえ、いくつか実験をします。私はこれらの概念を完全に理解するのに大いに役立った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フレームワークのあちこちにあります。
別の例はabout WebView クラスです。 Webviewクラスのパブリックメソッドはメインスレッドで呼び出す必要があります。そうでない場合、targetSDKversion 18以上を設定すると、ランタイムシステムはRuntimeException
をスローします。この振る舞いは そのソースコード で明確に伝えることができます。それはちょうどそのように書かれています。
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をスローした場合は無意味です。それは、致命的な結果を引き起こすその興味のために新しく導入された行動を可能にするべきではありません。ですから、私たちがしなければならないのは、特定のtargetSDKversionsですべてが問題ないかどうかを確認することです。より高いtargetSDKversionを設定することで見た目の向上のようなメリットがありますが、責任があります。
編集:免責事項。現在のtargetSDKversion(上記で示したもの)に基づいて異なるテーマを設定するDatePickerDialogコンストラクタは、実際には 後のコミット で変更されました。それにもかかわらず、ロジックは変更されていないので、私はその例を使用しました、そしてそれらのコードスニペットは明らかに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 Development Tools(ADT)のバージョン17以降、これを非常に簡単に修正できる1つの新しくて非常に役に立つアノテーション@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は単にそれをコンパイルすることを可能にしますが、あなたはあなた自身の責任でそれを実行します。
Target sdkはあなたがターゲットにしたいバージョンで、min sdkは最小のものです。
Android:minSdkVersion
とAndroid:targetSdkVersion
はどちらもAndroidマニフェストファイルで宣言する必要がある整数値ですが、どちらも異なるプロパティを持ちます。
Android:minSdkVersion:
これは、Androidアプリを実行するために最低限必要なAPIレベルです。同じアプリをより低いAPIバージョンにインストールすると、パーサーエラーが表示され、アプリケーションがサポートしていない問題が表示されます。
Android:targetSdkVersion:
ターゲットSDKのバージョンは、アプリケーションのターゲットAPIレベルを設定するためのものです。この属性がマニフェストで宣言されていない場合、minSdkのバージョンがあなたのTargetSdkのバージョンになります。これは、「アプリがTargetSdkバージョンとして宣言したすべての上位バージョンのAPIへのインストールをサポートする」ということに常に当てはまります。アプリ限定のターゲットにするには、マニフェストファイルでmaxSdkVersionを宣言する必要があります。
あなたが危険なパーミッション を必要とし 、targetSDKを23以上に設定するアプリを作成している場合は注意が必要です。 。実行時にパーミッションをチェックしないとSecurityExceptionが発生します。例えば、オープンカメラのようにtryブロック内でコードを使用している場合は、logcatをチェックしないとエラーを検出するのが難しくなります。