それはほとんどすべてタイトルにあります。私が見<uses-sdk>たすべてのサンプルライブラリプロジェクトで指定されているように見えますAndroidManifest.xmlが、それは無関係だと感じています。
実際、以外<uses-permission>の のすべての属性と同様に、これも無関係であると思います。<manifest>package
誰でも確認できますか？
6368 次
4 に答える
22
ADT r20 プレビュー 3 以降
ライブラリ マニフェストは、メイン アプリケーション マニフェストとマージできます。これは、プロパティを指定することにより、ant ビルドで有効になります。
manifestmerger.enabled=true
[他の (maven などの) ビルドで有効にする方法がわかりません。わかったらここにコメントしてください。aapt コマンドライン引数に変換されると思います。]
さまざまなルールが競合とオーバーライド動作を管理します。
ここで提起された特定の問題 (<uses-sdk> と <uses-permission> のマージ) に関連して、<uses-sdk> のルールは次のとおりです。
- minSdkVersion: 宛先マニフェストに lib 値より小さい値が含まれている場合はエラー。目的地の値は lib の値と同じかそれより大きい値のままにし、そこに何も指定されていない場合にのみ目的地に lib の値を格納します (どちらにも指定されていない場合はデフォルトで 1 になります)。
- targetSdkVersion: 宛先マニフェストに lib 値より小さい値が含まれている場合は警告。lib 値と同じか大きい場合は destination 値のままにし、そこに何も指定されていない場合にのみ lib 値を destination に格納します (どちらにも指定されていない場合は、デフォルトでマージされた minSdkVersion 値になります)。
<uses-permission> のルールは次のとおりです。目的地にライブラリのアクセス許可がまだ存在しない場合は、目的地に追加します。両方に同じパーミッションがあればOKです。
ADT r20 プレビュー 2 以前を使用している場合は、次のことが適用されます。
これを自分で理解するために、小さなテスト ライブラリ プロジェクトとそれを使用するテスト アプリを作成しました。ライブラリ プロジェクトのマニフェストで <uses-sdk> と <uses-permission> を指定し、アプリケーションのマニフェストから両方を省略しました。
その結果、ライブラリ プロジェクトの <uses-sdk> および <uses-permission> の値は、ビルド時にアプリケーションにマージされませんでした。これは、AppXploreツールを使用してデバイスにインストールされているアプリを調べることで証明されています。
テスト コードはhttps://github.com/adennie/android-library-project-manifest-testで入手できます。
私の結論は、Android ライブラリ プロジェクトのマニフェストで <uses-sdk> と <uses-permission> を指定しても、消費するアプリケーションのマージされたマニフェストには影響しないということです。
于 2012-05-01T15:55:23.403 に答える
1
ライブラリ プロジェクトでのマニフェストの使用例:
リントを試しましたか？プロジェクトが、マニフェストに設定した min-sdk では機能しない、あまりにも新しいクラス/メソッドを使用している場合に警告することができます。それをチェックしたいですか？ここに示すように、sdk manager の近くにある V-checkbox ボタンを押すだけです: http://tools.android.com/tips/lint/lint-toolbar.png?attredirects=0
マニフェストは、プロジェクトを使用するために何が必要かについて、他の人に手がかりを与えることができます。
内部にいくつかのテスト アクティビティを追加することもできます。これにより、プロジェクトをライブラリ プロジェクトから通常のプロジェクトにすばやく切り替えて、テストを実行できます。
Google が過去に提案したように、ライブラリ プロジェクトは、ライブラリ プロジェクトを使用するすべてのプロジェクトとマージされることにより、将来的にマニフェストを使用する可能性があります。
つまり、マニフェストは無意味ではありません。それはあなたを大いに助けることができます。
于 2012-05-04T08:49:20.820 に答える
0
ライブラリ プロジェクトが特定の Android バージョンに依存しない場合は、このタグを省略できます。
uses-sdk が SDK のバージョンなどを定義するためです。
于 2012-02-29T17:32:12.987 に答える
-1
ドキュメントによると、それは<uses-sdk>
属性 android:minSdkVersionは必ず必要であり、何も渡さない場合は1 つの意味になります。アプリは Android のすべての API バージョンをサポートします。静的に渡さない場合は、アプリでそれらすべてをサポートする必要があります。
注意: この属性を宣言しない場合、システムはデフォルト値の「1」を想定します。これは、アプリケーションが Android のすべてのバージョンと互換性があることを示します。アプリケーションがすべてのバージョンと互換性がなく (たとえば、API レベル 3 で導入された API を使用している)、適切な minSdkVersion を宣言していない場合、API レベル 3 未満のシステムにインストールすると、アプリケーションはクラッシュします。利用できない API にアクセスしようとしたときのランタイム。このため、必ず minSdkVersion 属性で適切な API レベルを宣言してください。
属性 android:maxSdkVersionを理解するのは少し難しいです..docは、
警告: この属性を宣言することはお勧めしません。まず、リリースされた新しいバージョンの Android プラットフォームへのアプリケーションの展開をブロックする手段として属性を設定する必要はありません。設計上、プラットフォームの新しいバージョンは完全な下位互換性があります。アプリケーションは、標準 API のみを使用し、開発のベスト プラクティスに従っていれば、新しいバージョンでも適切に動作するはずです。次に、場合によっては、属性を宣言すると、より高い API レベルへのシステム更新後にアプリケーションがユーザーのデバイスから削除される可能性があることに注意してください。アプリケーションがインストールされる可能性が高いほとんどのデバイスは、定期的なシステム アップデートを無線で受信するため、この属性を設定する前にアプリケーションへの影響を考慮する必要があります。
と、
Android の将来のバージョン (Android 2.0.1 以降) では、インストール時または再検証時に maxSdkVersion 属性をチェックまたは適用しなくなります。ただし、Google Play は、ダウンロード可能なアプリケーションをユーザーに提示する際に、引き続きこの属性をフィルターとして使用します。
その警告は、その属性を宣言した場合に発生する可能性のあるマイナス点を示すことですが、反対側を調べると、特定の Android バージョンをサポートするものを開発している場合、ATTRIBUTE が最も役立ちます。
その属性を削除するために取られたステップは、開発者が自分のアプリをすべての異なる (新しい) バージョンをサポートするようにすることです。
バージョン 2.0.1^ で開発している場合にのみ、それを書く必要はないと言うことができますが、それを書くと、Google paly はそれをユーザーを提示するためのフィルターとして使用します
だから私の結論とアドバイス
<uses-sdk>少なくとも 1 つの属性を持つ要素を使用するandroid:minSdkVersion
于 2012-05-01T13:07:01.283 に答える