AndroidX の代わりにサポート ライブラリを使用する
記録
最近はフック技術の研究をしているのですが、フックポイントを探すときはソースコードを読まないといけません。さまざまな SDK ソース コードでは、メソッドの変更は常に多かれ少なかれあります。すると私の手元にあるデバイスはAPI27である8.1です。アプリのバージョンを 27 に減らして、27 のソース コードに準拠できるようにします。その結果、問題が発生しました。
現在、私が使用している Android studio のバージョンは 4.1 で、AS3.5 以降では、新しいプロジェクトを作成するときに、デフォルトの統合サポート ライブラリが v7 から androidx に調整されます。ここで問題が発生します。サポートされている androidx の最小 API バージョンは 28 です。これを 27 に変更すると、エラーが報告されます。
バックグラウンド
問題を解決する前に、androidx とは何かを見てみましょう。
以下内容は郭おばさんのブログからの抜粋です 詳細はAndroidXとは？
Android システムが最初にリリースされたとき、その設計者でさえ、それが成功するとは考えていなかった可能性があるため、最初からその API を十分に検討することはできませんでした。Android のシステム バージョンの継続的な更新により、バージョンごとに多くの新しい API が追加されますが、新しく追加された API は古いバージョンのシステムには存在しないため、下位互換性の問題があります。
たとえば、Android システムがバージョン 3.0 にリリースされたとき、タブレットの重要性に突然気付きました.そこで、Android チームは、タブレットとの互換性を高めるために、Fragment 関数を 3.0 システムに追加しました (API 11)。Fragmentの役割はタブレットに限ったことではありませんが、古いシステムでこの機能を使いたい場合はどうすればいいですか？そのため、Android チームは下位互換性を提供するために、よく知られている Android サポート ライブラリを立ち上げました。例えば、誰もが知っている support-v4 ライブラリと appcompat-v7 ライブラリは Android Support Library に属しており、Android 開発を行っている人なら誰でもこの 2 つのライブラリを使用したことがあると思います。
しかし、support-v4 ライブラリの名前が何を意味するのか考えたことがない人も多いので、ここで説明させてください。ここで 4 は Android API のバージョン番号を指し、対応するシステム バージョンは 1.6 です。次に、support-v4 は、このライブラリで提供される API が Android 1.6 システムと下位互換性を持つことを意味します。対応するパッケージ名は android.support.v4.app です。
同様に、appcompat-v7 は、ライブラリで提供される API の Android 2.1 システムである API 7 への下位互換性を示します。対応するパッケージ名は android.support.v7.appcompat です。
Android Support Library で提供されているライブラリのパッケージ名はすべて android.support.* で始まることがわかります。
しかし、ゆっくりと時間の経過とともに、1.6 と 2.1 のシステムは長い間廃止され、現在、Android で公式にサポートされている最小システム バージョンは 4.0.1 であり、対応する API バージョン番号は 15 です。support-v4 および appcompat-v7 ライブラリは、そのような長年のシステムをサポートしなくなりましたが、実際の機能は元の命名理由と一致しませんが、名前は保持されています。
明らかに、Android チームはこの命名が非常に不適切であることに気付き、これらの API のアーキテクチャを再分割して AndroidX を立ち上げました。
つまり、androidx は android オペレーティング システムの拡張ライブラリであり、開発に通常使用する多くの API はこのライブラリから取得されます。
この問題を解決するには、サポート ライブラリを androidx から android.support.v7 にダウングレードします。
最初のステップは、compileSdkVersion と targetSdkVersion を 27 に戻すことです。
エラー Android resource linking failed が報告されていますが、これは上記のプロジェクトで androidx ライブラリが使用されており、api28 の最小サポートがサポートされているためです。ここで直接28に変更すれば問題ないのですが、27が欲しいので引き続き問題を解いていくしかありません。
2 番目のステップは、androidx 関連の依存関係をサポート ライブラリに変更することです。
主にサポートライブラリの置き換え
没更改之前
implementation 'androidx.appcompat:appcompat:1.1.0'
更改之后
implementation 'com.android.support:appcompat-v7:28.0.0'
プロジェクトにはまだ androidx ライブラリ内のリソースへの呼び出しがあるため、一連のエラーが報告されるか、Android リソースのリンクに失敗します。
3 番目のステップは、プロジェクトの androidx ライブラリ内のリソースへの呼び出しを削除することです。
間違った呼び出しパスのログにプロンプトが表示され、開いて順番に削除します。例:
G:\workspace2020\Test2\app\src\main\res\values\themes.xml:3:5
G:\workspace2020\ Test2\app\src \main\res\values-night\themes.xml:3:5
ファイルを開き、サポートにこれらのリソースが見つからないことを示す赤いマークがあることを確認します
。サポート ライブラリに存在する .DarkActionBar テーマ Theme.AppCompat.Light.NoActionBar などのテーマ、残りの人気のあるテーマは削除する必要があります。
コード内にも呼び出しがあり、androidx はサポート ライブラリに置き換える必要がありますが、
この時点でサポート ライブラリが見つからないというコードが表示されていることがわかりました
。
、そのため、プロジェクト構造を開いてプロジェクトの依存関係を確認しました。そうなんですけど、
All Moudulesがあって、表示された依存関係が明らかに問題なので、
グローバルに検索したところ、まあ、まだ変更されていないところがたくさんあります。しかし、ポイントは android.useAndroidX=true の構成です
4 番目のステップでは、プロジェクト内の androidx ライブラリの構成を削除します
このフォルダーを開くと、2 つの構成が表示されます。最も重要なことは、android.useAndroidx=true を見つけたことではなく、android.enableJetifier=true の設定です。
新しいプロジェクトで、AndroidX 関連の依存関係を使用する場合は、gradle.properties ファイルに構成を追加する必要があります。
android.useAndroidX=true
android.enableJetifier=true
AndroidX を使用したいが、以前のバージョンが移行されない場合は、次のように構成できます。
android.useAndroidX=true
android.enableJetifier=false
次に、Androidx を使用したくないので、これらの 2 行を削除します。
以上