web-dev-qa-db-ja.com

AndroidXとは

Androidのルームライブラリーについて読んでいます。私は彼らがパッケージAndroidをandroidxに変更したのを見ます。私はそれを理解しませんでした。誰かが説明してください。

implementation "androidx.room:room-runtime:$room_version"
annotationProcessor "androidx.room:room-compiler:$room_version"

これでさえAndroidパッケージで利用可能です。

implementation "Android.Arch.persistence.room:runtime:$room_version"
annotationProcessor "Android.Arch.persistence.room:compiler:$room_version"
  • 新しいサポートライブラリをandroidxではなくAndroidにパッケージ化する必要がありました。
  • ユースケースと既存のプロジェクトの要因に影響を与えます。
androidandroid-architecture-componentsandroid-jetpackandroidx
93
Khemraj

AndroidX - Android拡張ライブラリ

AndroidXのドキュメント から

どのパッケージがAndroidオペレーティングシステムにバンドルされており、どれがアプリのAPKにパッケージされているかを明確にするために、新しいパッケージ構造を展開しています。今後、Android。*パッケージ階層は、オペレーティングシステムに同梱されているAndroidパッケージ用に予約される予定です。他のパッケージはAndroidXライブラリの一部として新しいandroidx。*パッケージ階層で発行されます。

AndroidXの必要性

AndroidXは、パッケージ名をより明確にするためにライブラリを再設計しました。だから今から Android 階層は、Androidオペレーティングシステムに付属しているAndroidのデフォルトクラスのみになります。そして他のライブラリ/依存関係は androidx の一部になります（もっと理にかなっています）。だから今からすべての新しい開発はandroidxで更新されます。

com.Android.support。**： androidx。
com.Android.support:appcompat-v7： androidx.appcompat：appcompat com.Android.support:recyclerview-v7： androidx.recyclerview：recyclerview com.Android .support：design： com.google.Android.material：material

AndroidXパッケージの完全な案件マッピング

AndroidXは Semantic-version を使用しています

以前のバージョンではsupport libraryuse SDKのバージョンがAndroidXでは Semantic-version が使用されていました。 28.0.0→1.0.0からリバージョンします。

現在のプロジェクトを移行する方法

Android Studio 3.2（2018年9月）では、既存のプロジェクトをAndroidXに移行する直接的なオプションがあります。これはすべてのパッケージを自動的に屈折させます。

移行する前に、プロジェクトをバックアップすることを強くお勧めします。

既存プロジェクト

  • Android Studio>リファクタメニュー> AndroidXに移行...
  • それは分析して、下部にRefractorウィンドウを開くでしょう。行われる変更を受け入れます。

image

新しいプロジェクト

これらのフラグをあなたのgradle.propertiesに入れてください

Android.enableJetifier=true
Android.useAndroidX=true

@ 同等のAndroidXパッケージのライブラリマッピング を確認してください。

@ AndroidXへの移行の公式ページ を確認してください。

Jetifierとは何ですか？

移行のバグ

  • あなたがアプリを構築し、移行後にいくつかのエラーを見つけた場合、あなたはそれらのマイナーなエラーを修正する必要があります。それは簡単に修正できるので、あなたはそこで立ち往生することはありません。
  • サードパーティのライブラリはディレクトリ内でAndroidXに変換されませんが、実行時に Jetifier によって変換されるので、コンパイル時のエラーについては心配しないでください。

サポート28.0.0は最後のリリースですか？

_から Android Support Revision 28.0.0

これは Android.supportパッケージの最後の機能リリースになるでしょう 、そして開発者はAndroidX 1.0.0に移行することをお勧めします

Androidは今からandroidxパッケージのみを更新するため、AndroidXを使用してください。

参考文献

https://developer.Android.com/topic/libraries/support-library/androidx-overview

https://Android-developers.googleblog.com/2018/05/hello-world-androidx.html

155
Khemraj

ドキュメント ：に基づく

androidxは、どのパッケージがAndroidオペレーティングシステムにバンドルされていて、どれがアプリのAPKにパッケージされているかを明確にするための新しいパッケージ構造です。今後、Android。*パッケージ階層は、オペレーティングシステムに同梱されているAndroidパッケージ用に予約されます。他のパッケージは新しいandroidx。*パッケージ階層で発行されます。

再設計されたパッケージ構造は、より小規模で焦点の絞られたライブラリを奨励することです。案件のマッピングに関する詳細が見つかります ここ 。

サポートされている最小のSDKレベルが14の場合、 "v7"という名前のサポートライブラリ（下位互換性のためのコンポーネントとパッケージを含む）があります。 Androidの異なるバージョンで。詳しくは 公式発表 を参照してください。

12
Sagar

この記事 Android Jetpack：Androidのサポートライブラリにとって最近の発表はどういう意味ですか？ 説明

現在、サポートライブラリはAndroidアプリ開発の重要な部分であり、Google Playストアのアプリの99％で使用されていると考えられています。ただし、サポートライブラリが成長するにつれて、ライブラリの命名規則を取り巻く矛盾が忍び寄ってきました。

最初、各パッケージの名前は、そのパッケージでサポートされている最小のAPIレベルを示していました（例：support-v4）。ただし、サポートライブラリのバージョン26.0.0では、最小APIが14に増加したため、現在、多くのパッケージ名は、サポートされている最小APIレベルとは無関係です。 support-v4パッケージとsupport-v7パッケージの両方の最小APIが14である場合、人々が混乱する理由を簡単に確認できます！

この混乱を解消するために、Googleは現在、サポートライブラリを新しいAndroid拡張ライブラリ（AndroidX）パッケージ構造にリファクタリングしています。 AndroidXは、各パッケージのコンテンツをより適切に反映するMavenのgroupIdとartifactId、およびサポートされているAPIレベルに加えて、簡略化されたパッケージ名を備えています。

現在の命名規則では、Androidオペレーティングシステムにバンドルされているパッケージと、アプリケーションのAPK（Androidパッケージキット）にパッケージ化されているパッケージも明確ではありません。この混乱を解消するために、バンドルされていないライブラリはすべてAndroidXのandroidx。*名前空間に移動し、Android。*パッケージ階層はAndroidオペレーティングシステムに同梱されるパッケージ用に予約されます。

5
onmyway133

AndroidX は、Androidチームが Jetpack 内のライブラリの開発、テスト、パッケージ化、バージョン管理、リリースに使用するオープンソースプロジェクトです。

AndroidX は、元の Android Support Library に対する大きな改善です。サポートライブラリと同様に、AndroidXはAndroid OSとは別に出荷され、Androidのリリース間で後方互換性を提供します。 AndroidXは、同等の機能と新しいライブラリを提供することで、サポートライブラリを完全に置き換えます。

AndroidXには以下の機能があります。

  • AndroidXのすべてのパッケージは、文字列androidxで始まる一貫した名前空間に存在します。サポートライブラリパッケージは対応するandroidx。*パッケージにマッピングされています。すべての古いクラスの完全なマッピングと新しいものへのアーティファクトの構築については、Package Refactoringページを参照してください。

  • サポートライブラリとは異なり、AndroidXパッケージは個別に管理および更新されています。 androidxパッケージはバージョン1.0.0から厳格なSemantic Versioningを使います。プロジェクト内のAndroidXライブラリを個別に更新できます。

  • 新しいサポートライブラリの開発はすべてAndroidXライブラリで行われます。これには、元のサポートライブラリの成果物のメンテナンスと新しいJetpackコンポーネントの導入が含まれます。

AndroidXを使用する

既存のプロジェクトを移行する方法については、 AndroidXへの移行 を参照してください。

新しいプロジェクトでAndroidXを使用する場合は、コンパイルSDKをAndroid 9.0（APIレベル28）以上に設定し、gradle.propertiesファイルで次の両方のAndroid Gradleプラグインフラグをtrueに設定する必要があります。

  • Android.useAndroidX：trueに設定すると、Androidプラグインはサポートライブラリの代わりに適切なAndroidXライブラリを使用します。指定されていない場合、フラグはデフォルトではfalseです。

  • Android.enableJetifier：trueに設定すると、Androidプラグインは既存のサードパーティライブラリをバイナリを書き換えることによってAndroidXを使用するように自動的に移行します。指定されていない場合、フラグはデフォルトではfalseです。

アーティファクトマッピング の場合 this

3
Basi

私の側から利用可能なすべての回答へのビットの追加

AndroidXの必要性

  1. @KhemRajによる驚くべき答えで述べたように、

現在の命名規則では、どのパッケージがAndroidオペレーティングシステムにバンドルされ、どのパッケージがアプリケーションのAPK（Android Package Kit）にパッケージされているかは明確ではありません。この混乱を解消するために、バンドルされていないすべてのライブラリはAndroidXのandroidx。*名前空間に移動され、Android。*パッケージ階層はAndroidとともに出荷されるパッケージ用に予約されますオペレーティング・システム。

  1. これ以外に、

    最初は、各パッケージの名前は、そのパッケージでサポートされている最小のAPIレベルを示していました（例：support-v4）。ただし、サポートライブラリのバージョン26.0.は最小APIを14に増やしたため、現在、多くのパッケージ名はサポートされている最小APIレベルとは関係ありません。 support-v4とsupport-v7パッケージの両方の最小APIが14である場合、人々が混乱する理由が簡単にわかります！したがって、AndroidXでは、APIレベルに依存しません。

もう1つの重要な変更点は、AndroidXのアーティファクトが個別に更新されるため、すべての依存関係を一度に変更するのではなく、プロジェクト内の個々のAndroidXライブラリを更新できることです。イライラする「すべてのcom.Android.supportライブラリはまったく同じバージョン仕様を使用する必要があります」というメッセージは過去のものになるはずです！

2
Abhishek Kumar

これはAppCompatバージョンのサポートと同じですが、v4とv7のバージョンの混乱が少なくなるため、Android XML要素のさまざまなコンポーネントを使用することから非常に役立ちます。

0
raj kavadia