持っていることの結果を知りたかったtargetSDK > buildTarget
。
最近、タブレット (実行中、API レベル 16) で と タブを保持するbuildTarget=16
と、actionBar の中央に移動することがわかりました。私は行動を合理化することができませんでした。なぜこれが起こったのか、誰かが光を当てることができますか?targetSDK=17
4.1.1
持っていることの結果を知りたかったtargetSDK > buildTarget
。
最近、タブレット (実行中、API レベル 16) で と タブを保持するbuildTarget=16
と、actionBar の中央に移動することがわかりました。私は行動を合理化することができませんでした。なぜこれが起こったのか、誰かが光を当てることができますか?targetSDK=17
4.1.1
いい質問です!buildTarget と targetSDK が説明されている方法で異なっていたとき、私は少し前に同様の動作をしました。理解するのに時間がかかりましたが、私の理解を要約してみます。
次の 3 つの重要な値を区別する必要があります。
minSdkVersion
:
これは、アプリが実行される (または実行される必要がある) 利用可能な最も低いバージョンです。.apk を Android にインストールする場合、値がチェックされ、実行している Android のバージョンが指定されたバージョンよりも低い場合、インストールされません。
buildTarget
:
これは、アプリケーションの .apk がコンパイルされる SDK です (コンパイル エラーをチェックするために、Eclipse もその値をターゲットにします)。buildTarget
が より大きい場合minSdkVersion
、Android のバージョンがすべての方法をサポートしていなくても、アプリをインストールできます。デフォルトでは、これは SDK で利用可能な最新バージョンの Android に設定されています。古いバージョンをサポートするようにアプリをビルドすることはできますが、ビルド ターゲットを最新バージョンに設定すると、新しい機能を有効にしてアプリを最適化し、最新のデバイスで優れたユーザー エクスペリエンスを実現できます。
より低い API レベルで実行している場合は、使用しているメソッドが実行時に存在するかどうかを確認する必要があります。そうしないと、アプリケーションがクラッシュする可能性があります。
targetSdkVersion
:
はtargetSdkVersion
、アプリが正常に動作する SDK プラットフォームを指定します。したがって、API 17 に対してテストした場合は、API 17 を として追加できますtargetSdkVersion
。Android バージョン > を使用している場合targetSdkVersion
、Android システムは、アプリケーションのサポートを確保するために、ある種の前方互換性モードに入ります。この互換性動作は、API レベル間で動作が変更される可能性があるため、アプリが期待どおりに動作し続けることを保証するために入力されます (最も重要な変更の一部を次に示します)。そのため、古い動作 (廃止された値など) が互換モード内で「シミュレート」される可能性があるため、下位の API レベル用に開発されたアプリケーションは上位バージョンで実行できます。
例えば:
targetSdkVersion
HONEYCOMB (API 11) に設定すると、既定のテーマはTheme_Holo
(暗いホログラフィック UI) に変更されます。低い値に設定targetSdkVersion
すると、使用するビルド API に関係なく、システムはデフォルトのライト テーマのままになります。
あなたの場合、API 16 と 17 の間には、デザインの変更に影響するはずの顕著な変更はあまりないようですがtargetSdkVersion
、コンパイル時にいくつかの追加の変更に影響を与えると思います (追加のクラス、テーマを含めるなど)。 、値、...)、上記のテーマの例と同様に、異なる動作に影響を与えます。
奇妙な振る舞いを理解するのに少し役立ったことを願っています。Android 開発者向けドキュメントで読むべきその他の関連情報を次に示します。
PS: ある種の順逆地獄があります。Android システムは下位互換性があるため、Android アプリケーションの上位互換性が保証されます。つまり、OTA 経由で Android のバージョンを更新した場合、古いアプリケーションはすべて実行されたままになります (したがって、上位互換性が維持されます)。
ビルド ターゲットはアプリ開発用で、ターゲット SDK はアプリの互換性用です。
ビルドターゲットアプリの実装中にアクセスできる API を指定します。ビルド ターゲットを Android API レベル 10 に設定した場合と同様に、コードに関する限り、ActionBar のようなものはありません。開発中に使用する API は、Android の単なるスタブ実装です。これは、実際のデバイスでエミュレートまたは実行する必要がある方法です。したがって、ビルド ターゲットは、使用している Android インターフェイスを (コンパイラと IDE に対して) 定義します。コンパイルが完了すると、ビルド ターゲットに基づく違いはありません (Android システムはビルド ターゲットを認識しません。これはコンパイル時のフラグです)。これは、アプリケーションで使用できる Android のコンポーネントを定義する、Android コンパイラ (および IDE) との間の厳密な契約です。
ターゲットSDKは、Android システムと署名する契約であり、アプリが最小 SDK からターゲット SDK まで適切に動作する準備ができていることを保証します (最大 SDK 設定は通常回避する必要があるため、最大 SDK に有効です)。いくつかのセキュリティの変更など、前方互換性を得られないものがいくつかあると思います (おそらく、変更はアプリ開発を超えてシステム全体に適用されます)。この契約は、すべての状況で期待される動作を提供するように、アプリがその範囲内の Android API の変更を確実に処理するための措置を講じたことを意味する契約です。契約のもう一方の端は Android システムからのもので、ターゲット SDK を超えない Android 実装を使用することに同意します。
前方互換性に関する注意は、ビルド ターゲットが少なくともターゲット SDK と常に一致する必要があることを意味します。アプリをターゲット SDK で実行するようにテストしたと言っているのに、なぜ下位の API レベルに対してアプリをビルドするのでしょうか?
実際のビルド ターゲットとターゲット SDK の動作例: ActionBarSherlockは下位互換性のある ActionBar を提供します。現時点でライブラリを使用するための要件からの引用を次に示します。
ライブラリ自体は、Android 4.0 (API レベル 14) に対してビルドする必要があります。プロジェクトは、4.0 以降である限り、可能な限り最新バージョンの SDK を使用してビルドする必要があります。
新しいデバイスで Android を実行すると、ネイティブ アクション バーが自動的に追加されるため、API レベル 11 以降をターゲットにする必要があります。新しい API に対してコンパイルしますが、アプリは Android の古いバージョンを搭載したデバイスで実行される可能性が高いため、最小限の SDK バージョン以降に導入されたメソッドを使用しないようにするか、適切にチェックして呼び出すように特に注意する必要があります。
最初の段落は、4.0 ActionBar API を含むビルド ターゲットが必要であることを示しています。これは、ライブラリがそれを利用し、それなしではコンパイルできないためです。2 番目の段落は、ライブラリがそのようなデバイスでネイティブの ActionBar を使用するため、3.0 ActionBar API を含むターゲット SDKが必要であることを示していますが、ターゲット SDK が 3.0 より低い場合、Android システムは ActionBar を提供しません。ターゲットよりも新しいものを使用するには (3.0 ActionBar など)。
参考文献: