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 Chipanbietern
/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 Chipanbietern
/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 darf ohne den Suffix des Unternehmensnamens 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 Chipanbietern oder Geräteherstellern hinzugefügt wurden, können 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 der Zugriff für Anwendungen (einschließlich Drittanbieteranwendungen) erforderlich ist, muss die Bibliothek in einer anbieterspezifischen file_contexts-Datei folgendermaßen als same_process_hal_file gekennzeichnet sein:
```
/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 weder direkt noch indirekt über ihre Abhängigkeiten von anderen Systembibliotheken als VNDK-SP- und LLNDK-Bibliotheken abhängig sein. Die Liste der VNDK-SP- und LLNDK-Bibliotheken finden Sie 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 Eine Liste der für Apps zugänglichen nativen Android-Bibliotheken (auch als öffentliche native Bibliotheken bezeichnet) finden Sie im Abschnitt 3.1.1 der CDD. 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, die mit Plattformbibliotheken verknüpft sind .

Apps auf Abhängigkeiten von nativen Bibliotheken prüfen

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, ist 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.