AndroidマルチCPUアダプタまとめ

この2,3日は数年の古いプロジェクトを再構築するつもりで、プロジェクトの中でNDKを使っていますが、不思議なABIの間違いを報告して、最終的に問題を見つけたのはプロジェクトの中です.soファイルの場所が間違っています.ABIのコンセプトは前にも知っていたので、今日まとめてみます.
いくつかの概念を理解する

NDKすなわちNative Development Kitは、オリジナル開発ツールセットであるため、Googleでは「NDK」とも呼ばれ、Android開発ではNDKがC/C++のようなオリジナルコード言語で一部のプログラムを実行できるようにした.メリットは、サードパーティC/C++オープンソースライブラリの呼び出しが容易で、コードの移植も容易であることです.

JNIすなわちJava Native Interfaceは、Javaと他の言語の通信(主にC&C+)を実現するいくつかのAPIを提供するインタフェースとしての役割を文字通り知っている.

ABIはアプリケーションBinary Interfaceであり、アプリケーションバイナリインタフェースである.異なるAndroid携帯電話には異なるCPUがあり、さらに異なる命令セットをサポートし、CPUと命令セットのそれぞれに独自のABI(アプリケーションバイナリファイル)が組み合わせられ、「実行時、アプリケーションのマシンコードとシステムのインタラクション方式」に属する.

APIすなわちアプリケーションプログラムインターフェース.ソースコードレベルまたはライブラリ関数レベルとのインタラクション方式を向いており,コンパイル期間中に発生する.

APIとABIの重要な違いは、前者がソースコード向けであり、後者がソースコードの観点から異なるcpuアーキテクチャまたは異なるメモリ割り当て方式(システムが異なるか言語が異なる可能性があるメモリ割り当て方式も異なる)を駆動するバイナリファイル向けであることである.したがって、一連のソースコードの下でAPIが同じABIでは異なる可能性が高いが、後者の互換性はより厳格である.[外部チェーンピクチャの転送に失敗しました(img-lmcCAjVD-15630711218677)](https://note.youdao.com/yws/api/personal/file/A44E1CFB4B3249FB8A1C87CB2ECBBA14?method=download&shareKey=e1479723fb2736cb27374bab84dcd797)]
AndroidがサポートするCPUアーキテクチャ(ABI)

armeabiはARM*v 5 TEデバイスのライブラリに基づいて、ソフトウェア浮動小数点演算を使用して、すべてのARMデバイスと互換性があり、汎用性が高く、速度が遅い.

armeabi-v 7 a ARM*v 7デバイスのライブラリに基づいて、ハードウェア浮動小数点演算を使用し、高度な拡張機能(2010年)を備えています.

arm 64-v 8は、第8世代、64ビットARMプロセッサ向けのライブラリです.

x 86は32ビットintelプロセッサ向け(2011年).(デスクトップやタブレット用が多い)

x86_64ビットIntelプロセッサ(2014年)向け.

mipsはmipsアーキテクチャ向けのプロセッサです.(初期のソニーのゲーム機は、intelよりも命令システムの計算構造が簡素だった)

mips 64は64ビットmipsアーキテクチャのプロセッサ向けです.

Android Studioで使用する.soライブラリ
2つの形式の構成:1.eclipseのプロジェクトと同様に、libsディレクトリの下にarmeabiなどのディレクトリを新規作成する方法は、Androidstudioのデフォルトでサポートされていないため、gradleに指定のロードを追加する.soライブラリのディレクトリ:

sourceSets {
    main {
        jniLibs.srcDirs = ['libs']
    }
}

2.Android Studioのデフォルト形式で、直接src/main/下にjniLibsディレクトリを新規作成し、armeabiなどのディレクトリをそのディレクトリの下に置けばよい.また、同級ディレクトリの下には、jniディレクトリNDKを新規作成して、cppまたはcファイルを配置することもできます.すなわち、jniとjniLibsは同級で存在することができます.
インストール時の互換性チェック
システムにインストールすると、soファイルが:data/app/comに抽出されます.xxxxxxxx.app-x/lib/ディレクトリ下(5.0バージョン)、/data/app-lib/ディレクトリ下(4.2バージョン)、armeabiおよびarmeabi-v 7 aがarmディレクトリを生成し、arm 64-v 8 aがarm 64ディレクトリを生成します.
appをインストールするとき、appがsoファイルを使用し、ネイティブcpuアーキテクチャに適したsoファイルが存在しない場合は、エラーが発生します.たとえば、x 86シミュレータにはx 86バージョンのsoフォルダが必要です.さもないとインストールに成功しません.
ランタイム互換性チェック
1.ターゲットディレクトリの下にsoライブラリファイルが存在するかどうかを確認します.アイテムによってABIフォルダの下にある場合があります.soファイルの個数が一致しないため、ロード後、一部のCPUアーキテクチャが抽出したディレクトリの下で正常に読み取ることができない.soファイル.2.存在するsoファイルが現在のcpuアーキテクチャに合致しているかどうかを確認します.一部のABIフォルダのsoが合わない.
ロードsoファイルルール
プロジェクトにarmeabiディレクトリのみが提供されている場合、armeabi-v 7 a、arm 64-v 8 aアーキテクチャのプログラムはarmeabiに検索され、プロジェクトにarmeabi-v 7 a、armeabi-v 8 aディレクトリが同時に提供されている場合、システムはarmeabiに検索されません.この2つのディレクトリで見つからない場合は、直接エラーを報告します.
よくある質問

ABIディレクトリには配置するが.soファイルは同じですが、一部のディレクトリの下に配置するのは最適ではありません.soファイル、または低バージョンアーキテクチャからコピーしたもの.

はAndroidの高バージョンプラットフォームバージョンを使用してコンパイルされた.soファイルは低バージョンのデバイスで実行されます.

は、サポートするCPUアーキテクチャごとに対応するものを提供していない.soファイル.

将.soファイルは間違った場所に置かれています.

はarmeabiアーキテクチャのみを提供する.soファイルは他のABIsを無視します.

これらの問題は、エラーが発生するか、パフォーマンスが低下するか、実行可能であっても古いデバイスでエラーが発生する可能性があります.
推奨
ここでは、上記の問題に基づいて、開発の過程でいくつかの提案を行います.

アプリケーションを広くインストールしたい場合は、できるだけABIをすべて含むようにします.もちろん、インストールパッケージが大きくなります.

アプリケーションのインストール範囲を考慮すると、例えばより多くの携帯電話に対して、armeabi、armeabi-v 7、arm 64-v 8を適切に配合することができる.

インストールパッケージの大きさを考慮してCPUの性能をあまり重視しない場合は、市販の新しいマシンに直面している可能性がありますが、armeabiに適しているだけです.

複数のABIについては、ABIディレクトリの下にある.soファイルはすべて同じで、ABI向けが望ましい.

Native Libs Monitorこのアプリケーションは、携帯電話にインストールされているAPKがどのように使われているかを理解するのに役立ちます.soファイル、および.soファイルは、どの関数ライブラリまたはフレームワークに由来しますか.

は、複数のサードパーティ製ライブラリを参照する場合があります.libsフォルダとjniLibsフォルダが配置されている可能性があります.この場合、競合が発生するため、できるだけ1つの場所に配置します.

上から選択した適合ABIはGradleで構成することができる:

ndk {
    //        cpu   .so 。
    abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a'
    //       'x86', 'x86_64', 'mips', 'mips64'
}

注意:ndk.abiFiltersが指定したabiプラットフォームのライブラリフォルダおよびライブラリファイルは、すべて存在するか、存在しません.
Tap:

踏んだ穴:以前はarmeabiとarmeabi-v 7 aのcpuアーキテクチャのみをサポートしていたプロジェクトがあったが、デバッグ中にいつもエラーが報告されていた:

Caused by: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/idonic.mobileapp.xxx-1/base.apk"],nativeLibraryDirectories=[/data/app/idonic.mobileapp.xxx-1/lib/arm, /data/app/idonic.mobileapp.xxx-1/base.apk!/lib/armeabi-v7a, /vendor/lib, /system/lib]]] couldn't find "libxxx.so"

自分のプロジェクトでもarmeabiライブラリフォルダしかなく、上のルールによると、armeabi-v 7 aフォルダがなくても最終的にarmeabiフォルダに探しに行くことになる.プロジェクト構築後にarmeabi-v 7 aフォルダが存在するに違いないが、すぐにapkを解凍するのはやはりこの問題である.もともとプロジェクトにはテンセントのBuglyが依存していたが、構築パッケージ化後にarmeabi-v 7 aのフォルダが解放されたが、中にはlibBuglyだけが入っていた.soファイル.この問題を解決するには3つの注意点があります.

プロジェクトの表面の構造だけを見ないでください.隠れた依存は最大の元凶かもしれません.

abiフィルタを必ず設定してください.

対応するabiライブラリファイルを補完します.

シミュレータにインストールするときに「Failure[INSTALL_FAILED_NO_MATCHING_ABIS:Failed to extract native libraries,res=-113]」という具体的なエラーを報告することがあります.native librariesが使用されているためです.このnative librariesは、現在のcpuのアーキテクチャをサポートしません.
INSTALL_FAILED_NO_MATCHING_ABIS is when you are trying to install an app that has native libraries and it doesn’t have a native library for your cpu architecture. For example if you compiled an app for armv7 and are trying to install it on an emulator that uses the Intel architecture instead it will not work.
簡単に言えば、あるabiアーキテクチャ(シミュレータx 86アーキテクチャなど)マシン上でエンジニアリングサポートが実行されているが、エンジニアリングに含まれるライブラリにはabiアーキテクチャがサポートするライブラリがなく、インストールが実行できないことが明らかになった.この問題を解決するには、a.x 86のライブラリフォルダとファイルを補完する2つの方法があります.b.ndkを除去する.abiFiltersは、abiパケットを採用し、apkを構築する際にx 86アーキテクチャをサポートするapkを単独で分離する.

splits {
  abi {
    enable true
    reset()
    include 'x86'
    universalApk true
  }
}

上記のapkパケットの構築については、abiサポートに従って分割することもできるし、スクリーン密度サポートに従って分割することもできる.

splits {
  density {
    enable true
    reset()
    include "mdpi", "hdpi"
  }
  abi {
    enable true
    reset()
    include "x86", "x86_64"
  }
}

メニューBuild>Build APKをクリックし、エンジニアリングでbuild>outputs>apkで複数のapkを取得することができる.詳細については、公式ドキュメントを参照してください.https://developer.android.com/studio/build/configure-apk-splits

リファレンス

https://zhuanlan.zhihu.com/p/23102158

https://developer.android.com/studio/build/configure-apk-splits