Diese Seite wurde von der Cloud Translation API übersetzt.

Namespaces für native Bibliotheken

Mit Android 7.0 wurden Namespaces für native Bibliotheken eingeführt, um die Sichtbarkeit der internen API zu begrenzen und Situationen zu vermeiden, in denen Apps versehentlich Plattformbibliotheken anstelle ihrer eigenen verwenden. Informationen zu appspezifischen Änderungen finden Sie im Blogpost Stabilität mit privaten C/C++-Symboleinschränkungen in Android 7.0 verbessern.

Architektur

Unter Android 7.0 und höher werden Systembibliotheken von App-Bibliotheken getrennt.

Abbildung 1. Namespaces für native Bibliotheken.

Namespaces für native Bibliotheken verhindern, dass Apps native APIs für private Plattformen verwenden (wie es bei OpenSSL der Fall war). Außerdem wird verhindert, dass Apps versehentlich Plattformbibliotheken anstelle ihrer eigenen verwenden (wie bei libpng). Es ist schwierig, dass App-Bibliotheken versehentlich interne Systembibliotheken verwenden (und umgekehrt).

Zusätzliche native Bibliotheken hinzufügen

Zusätzlich zu den standardmäßigen öffentlichen nativen Bibliotheken können Chipanbieter (ab Android 7.0) und Gerätehersteller (ab Android 9) zusätzliche native Bibliotheken bereitstellen, auf die Apps zugreifen können .Dazu müssen sie die Bibliotheken in die entsprechenden Bibliotheksordner verschieben und sie explizit in TXT-Dateien auflisten.

Die Bibliotheksordner sind:

/vendor/lib (für 32-Bit) und /vendor/lib64 (für 64-Bit) für Bibliotheken von Silicon-Anbietern
/system/lib (für 32-Bit) und /system/lib64 (für 64-Bit) für Bibliotheken von Geräteherstellern

Die TXT-Dateien sind:

/vendor/etc/public.libraries.txt für Bibliotheken von Silicon-Anbietern
/system/etc/public.libraries-COMPANYNAME.txt für Bibliotheken von Geräteherstellern, wobei COMPANYNAME sich auf einen Namen des Herstellers bezieht (z. B. awesome.company). COMPANYNAME muss mit [A-Za-z0-9_.-]+ übereinstimmen; alphanumerische Zeichen, _, . (Punkt) und -. Es ist möglich, mehrere solche TXT-Dateien auf einem Gerät zu haben, wenn einige Bibliotheken von externen Lösungsanbietern stammen.

Native Bibliotheken in der system-Partition, die von Geräteherstellern veröffentlicht werden, MÜSSEN den Namen lib*COMPANYNAME.so haben, z. B. libFoo.awesome.company.so. Mit anderen Worten: libFoo.so ohne Suffix für den Unternehmensnamen DARF NICHT veröffentlicht werden. Das COMPANYNAME im Dateinamen der Bibliothek MUSS mit dem COMPANYNAME im Namen der TXT-Datei übereinstimmen, in der der Name der Bibliothek aufgeführt ist.

Native Bibliotheken, die Teil von AOSP sind, DÜRFEN NICHT veröffentlicht werden (außer den standardmäßigen öffentlichen nativen Bibliotheken, die standardmäßig öffentlich sind). Nur die zusätzlichen Bibliotheken, die von Silikonanbietern oder Geräteherstellern hinzugefügt werden, dürfen für Apps zugänglich gemacht werden.

Ab Android 8.0 gelten für öffentliche Anbieterbibliotheken die folgenden zusätzlichen Einschränkungen und erforderlichen Einstellungen:

Die native Bibliothek des Anbieters muss richtig gekennzeichnet sein, damit Apps darauf zugreifen können. Wenn Anwendungen (einschließlich Drittanbieter-Apps) Zugriff benötigen, muss die Bibliothek in einer anbieterspezifischen file_contexts-Datei so mit dem Label same_process_hal_file gekennzeichnet werden:
```
/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
```
Dabei ist libnative.so der Name der nativen Bibliothek.
Die Bibliothek darf, ob direkt oder vorübergehend über ihre Abhängigkeiten, nicht von anderen Systembibliotheken als VNDK-SP- und LLNDK-Bibliotheken abhängig sein. Die Liste der VNDK-SP- und LLNDK-Bibliotheken findest du unter development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv.

Ab Android 15 können öffentliche Anbieterbibliotheken in einer APEX-Datei des Anbieters abgelegt werden. Wenn die Bibliotheken in einem Anbieter-APEX-Paket enthalten sind, listen Sie sie im APEX-Manifest in einer provideNativeLibs-Eigenschaft auf.

Apps so aktualisieren, dass sie keine nicht öffentlichen nativen Bibliotheken verwenden

Diese Funktion ist nur für Apps aktiviert, die auf die SDK-Version 24 oder höher ausgerichtet sind. Informationen zur Abwärtskompatibilität finden Sie in Tabelle 1. Was passiert, wenn Ihre App mit privaten nativen Bibliotheken verknüpft ist Die Liste der nativen Android-Bibliotheken, auf die Apps zugreifen können (auch als öffentliche native Bibliotheken bezeichnet), finden Sie im CDD-Abschnitt 3.1.1. Apps, die auf Android 24 oder höher ausgerichtet sind und nicht öffentliche Bibliotheken verwenden, müssen aktualisiert werden. Weitere Informationen finden Sie unter NDK-Apps mit Plattformbibliotheken verknüpfen .

Apps für Abhängigkeiten von nativen Bibliotheken aktualisieren

Bei Apps, die auf die SDK-Version 31 (Android 12) oder höher ausgerichtet sind, müssen die Abhängigkeiten von nativen freigegebenen Bibliotheken ausdrücklich angegeben werden. Verwenden Sie dazu das Tag <uses-native-library> im App-Manifest. Wenn ein Teil der angeforderten Bibliothek nicht auf dem Gerät vorhanden ist, wird die App nicht installiert. Bei der Installation der Apps werden nur die angeforderten nativen freigegebenen Bibliotheken bereitgestellt. Das bedeutet, dass Apps nicht auf native freigegebene Bibliotheken zugreifen können, die nicht im App-Manifest aufgeführt sind.