2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
ネイティブ ライブラリの名前空間
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android 7.0 では、ネイティブ ライブラリの名前空間を導入して内部 API の公開を制限し、アプリが独自のライブラリではなく誤ってプラットフォーム ライブラリを使用することがないようにしています。アプリ固有の変更点については、Android デベロッパー ブログにて、Android 7.0 でのプライベート C/C++ シンボルの制限による安定性の向上に関する記事をご覧ください。
アーキテクチャ
Android 7.0 以降では、システム ライブラリはアプリ ライブラリから分離されています。
図 1. ネイティブ ライブラリの名前空間。
ネイティブ ライブラリの名前空間により、アプリはプライベート プラットフォームのネイティブ API を使用できなくなります（OpenSSL を使用した場合と同様）。また、アプリが独自のライブラリではなく誤ってプラットフォーム ライブラリを使用する（libpng で発生するような）事態も回避されます。アプリ ライブラリが誤って内部システム ライブラリを使用する（または内部システム ライブラリが誤ってアプリ ライブラリを使用する）可能性が低くなります。
その他のネイティブ ライブラリを追加する
標準の公開ネイティブ ライブラリに加えて、シリコン ベンダー（Android 7.0 以降）とデバイス メーカー（Android 9 以降）は、アプリがアクセスできるように、追加のネイティブ ライブラリを各ライブラリ フォルダに配置して、.txt ファイルで明示的に記述することもできます。
ライブラリ フォルダは次のとおりです。
- シリコン ベンダーのライブラリの
/vendor/lib（32 ビット用）と /vendor/lib64（64 ビット用）
- デバイス メーカーのライブラリの
/system/lib（32 ビット用）と /system/lib64（64 ビット用）
.txt ファイルは次のとおりです。
- シリコン ベンダーのライブラリの
/vendor/etc/public.libraries.txt。
- デバイス メーカーのライブラリの
/system/etc/public.libraries-COMPANYNAME.txt（COMPANYNAME は awesome.company などのメーカー名）。COMPANYNAME は [A-Za-z0-9_.-]+、つまり英数字、「_」、「.」（ドット）、「-」と一致する必要があります。外部ソリューション プロバイダのライブラリを使用する場合は、デバイスで複数の .txt ファイルを使用できます。
デバイス メーカーによって公開される system パーティション内のネイティブ ライブラリの名前は、lib*COMPANYNAME.so の形式にする必要があります（例: libFoo.awesome.company.so）。つまり、会社名の接尾辞がない libFoo.so は公開できません。ライブラリ ファイル名の COMPANYNAME は、ライブラリ名がリストされている txt ファイル名の COMPANYNAME と一致している必要があります。
AOSP に含まれているネイティブ ライブラリは公開できません（デフォルトで公開される標準の公開ネイティブ ライブラリは除きます）。シリコン ベンダーまたはデバイス メーカーによって追加されたライブラリのみ、アプリからアクセス可能にできます。
Android 8.0 以降、ベンダーの公開ライブラリには以下の追加制限と必須設定が設けられています。
- アプリからアクセスできるように、ベンダーのネイティブ ライブラリには適切なラベルを付ける必要があります。あらゆるアプリ（サードパーティ アプリを含む）によるアクセスが必要な場合は、次のようにベンダー固有の
file_contexts ファイルでライブラリに same_process_hal_file というラベルを付ける必要があります。
/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
この libnative.so はネイティブ ライブラリの名前です。
- ライブラリは、直接的であっても依存関係を介して推移的であっても、VNDK-SP ライブラリと LLNDK ライブラリ以外のシステム ライブラリに依存してはなりません。VNDK-SP ライブラリと LLNDK ライブラリのリストは、
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv にあります。
Android 15 以降では、ベンダーの公開ライブラリをベンダー APEX に含めることができます。ベンダー APEX にパッケージ化する場合は、APEX マニフェストの provideNativeLibs プロパティ内にライブラリをリストします。
非公開のネイティブ ライブラリを使用しないようにアプリを更新する
この機能は SDK バージョン 24 以降をターゲットとするアプリに対してのみ有効です。下位互換性については、表 1. アプリが非公開ネイティブ ライブラリにリンクしている場合に予期される動作をご覧ください。アプリがアクセスできる Android ネイティブ ライブラリ（公開ネイティブ ライブラリとも呼ばれる）のリストは、CDD の 3.1.1 項に記載されています。バージョン 24 以降をターゲットとし、非公開ライブラリを使用しているアプリは更新する必要があります。詳しくは、プラットフォーム ライブラリにリンクしている NDK アプリをご覧ください。
アプリを更新してネイティブ ライブラリの依存関係を指定する
SDK バージョン 31（Android 12）以降をターゲットとするアプリは、アプリ マニフェストで <uses-native-library> タグを使用して、ネイティブ共有ライブラリの依存関係を明示的に指定する必要があります。リクエストされたライブラリの一部がデバイスに存在しない場合、アプリはインストールされません。アプリのインストール時には、アプリがリクエストしたネイティブ共有ライブラリのみが提供されます。つまり、アプリはアプリ マニフェストにないネイティブ共有ライブラリにアクセスすることはできません。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-03 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-03 UTC。"],[],[],null,["# Namespaces for native libraries\n\nAndroid 7.0 introduced namespaces for native libraries to limit internal API\nvisibility and resolve situations where apps accidentally use platform\nlibraries instead of their own. See the [Improving\nStability with Private C/C++ Symbol Restrictions in Android 7.0](http://android-developers.blogspot.com/2016/06/improving-stability-with-private-cc.html) Android\nDevelopers blog post for app-specific changes.\n\nArchitecture\n------------\n\n\nIn Android 7.0 and higher, system libraries are separated from app libraries.\n\n\n**Figure 1.** Namespaces for native libraries.\n\n\nNamespaces for native libraries prevent apps from using private-platform native\nAPIs (as was done with OpenSSL). It also removes situations where apps\naccidentally use platform libraries instead of their own (as witnessed\nwith `libpng`). It's difficult for app libraries to use internal\nsystem libraries by accident (and vice versa).\n\nAdd additional native libraries\n-------------------------------\n\n\nIn addition to standard public native libraries, silicon vendors (starting from Android 7.0) and\ndevice manufacturers (starting from Android 9) may choose to provide additional native libraries\naccessible to apps by putting them under the respective library folders and explicitly listing them\nin .txt files.\n\nThe library folders are:\n\n- `/vendor/lib` (for 32-bit) and `/vendor/lib64` (for 64-bit) for libraries from silicon vendors\n- `/system/lib` (for 32-bit) and `/system/lib64` (for 64-bit) for libraries from device manufacturers\n\nThe .txt files are:\n\n- `/vendor/etc/public.libraries.txt` for libraries from silicon vendors\n- `/system/etc/public.libraries-COMPANYNAME.txt` for libraries from device manufacturers, where `COMPANYNAME` refers to a name of the manufacturer (such as `awesome.company`). `COMPANYNAME` must match with `[A-Za-z0-9_.-]+`; alphanumeric characters, _, . (dot) and -. It is possible to have multiple such .txt files in a device if some libraries are from external solution providers.\n\n\nNative libraries in the `system` partition that are made public by device manufacturers\n**MUST** be named `lib*COMPANYNAME.so`, for example, `libFoo.awesome.company.so`.\nIn other words, `libFoo.so` without the company name suffix MUST NOT be made public.\nThe `COMPANYNAME` in the library file name MUST match with the `COMPANYNAME` in the\ntxt file name in which the library name is listed.\n\n\nNative libraries that are part of AOSP MUST NOT be made public (except the standard\npublic native libraries which are public by default). Only the additional libraries added by\nsilicon vendors or device manufacturers can be made accessible to apps.\n\n\nStarting from Android 8.0, vendor public libraries have the following additional\nrestrictions and required setups:\n\n1. The native library in vendor must be properly labeled so it can be accessible to apps. If access is required by any apps (including third party apps), the library must be labeled as `same_process_hal_file` in a vendor-specific `file_contexts` file as follows: \n\n ```\n /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0\n ```\n where `libnative.so` is the name of the native library.\n2. The library, either directly or transitively through its dependencies, must not depend on system libraries other than VNDK-SP and LLNDK libraries. Locate the list of VNDK-SP and LLNDK libraries at `development/vndk/tools/definition/tool/datasets/eligible-list-\u003cversion\u003e-release.csv`.\n\n\nStarting from Android 15, vendor public libraries can be put in a\n[vendor APEX](/docs/core/ota/vendor-apex). When packaged in a vendor APEX, list the libraries\nin a `provideNativeLibs` property in the APEX manifest.\n\nUpdate apps to not use nonpublic native libraries\n-------------------------------------------------\n\n\nThis feature is enabled only for apps targeting SDK version 24 or later;\nfor backward compatibility, see [Table\n1. What to expect if your app is linking against private native libraries](http://android-developers.blogspot.com/2016/06/improving-stability-with-private-cc.html).\nThe list of Android native libraries accessible to apps (also know as\npublic native libraries) is listed in CDD section 3.1.1. Apps targeting 24 or\nlater and using any non-public libraries should be updated. See [NDK\nApps Linking to Platform Libraries](https://developer.android.com/about/versions/nougat/android-7.0-changes.html#ndk) for more details.\n\nUpdate apps for their native library dependencies\n-------------------------------------------------\n\nApps that target SDK version 31 (Android 12) or higher must\n*explicitly specify* their native shared library dependencies by using the\n`\u003cuses-native-library\u003e` tag in the app manifest. If any part of the requested\nlibrary doesn't exist on the device, the app isn't installed. When the apps are installed, they're\nprovided with *only* the native shared libraries that they've requested. This means that\napps can't access native shared libraries that don't appear in the app manifest."]]
