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 interne API einzuschränken Sichtbarkeit und Behebung von Situationen, in denen Apps versehentlich die Plattform nutzen in Bibliotheken und nicht in ihren eigenen. Weitere Informationen finden Sie im Abschnitt Verbesserung Stabilität mit privaten C/C++-Symbolbeschränkungen in Android 7.0 Entwickler-Blogpost zu App-spezifischen Änderungen.

Architektur

In Android 7.0 und höher sind Systembibliotheken von App-Bibliotheken getrennt.

Abbildung 1: Namespaces für native Bibliotheken.

Namespaces für native Bibliotheken verhindern, dass Anwendungen native private Plattformen verwenden APIs (wie bei OpenSSL). Außerdem werden Situationen entfernt, in denen Apps versehentlich Plattformbibliotheken verwenden und nicht ihre eigenen verwenden (wie gesehen mit libpng). Es ist schwierig für App-Bibliotheken, interne aus Versehen Systembibliotheken (und umgekehrt).

Zusätzliche native Bibliotheken hinzufügen

Zusätzlich zu den standardmäßigen öffentlichen nativen Bibliotheken werden Anbieter von Siliziumtechnologien (ab Android 7.0) und Gerätehersteller (ab Android 9) können zusätzliche native Bibliotheken anbieten. für Apps zugänglich sein, indem Sie sie in die entsprechenden Bibliotheksordner verschieben und sie explizit auflisten in TXT-Dateien.

Die Bibliotheksordner sind:

/vendor/lib (für 32-Bit) und /vendor/lib64 (für 64-Bit) für Bibliotheken von Siliziumherstellern
/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 Silikonanbietern
/system/etc/public.libraries-COMPANYNAME.txt für Bibliotheken von Geräteherstellern, Dabei steht COMPANYNAME für den Namen des Herstellers (z. B. awesome.company. COMPANYNAME muss übereinstimmen mit [A-Za-z0-9_.-]+; alphanumerische Zeichen, _, . (Punkt) und -. Es ist möglich, Mehrere solcher TXT-Dateien befinden sich auf einem Gerät, wenn einige Bibliotheken von einer externen Lösung stammen. Anbieter.

Native Bibliotheken in der Partition system, 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. Die COMPANYNAME im Namen der Bibliotheksdatei MUSS mit der COMPANYNAME im TXT-Datei, in der der Bibliotheksname 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 Anbietern von Silizium oder Geräteherstellern für Apps zugänglich gemacht werden.

Ab Android 8.0 bieten öffentliche Bibliotheken des Anbieters die folgenden zusätzlichen Einschränkungen und erforderliche Einrichtungen:

Die native Bibliothek des Anbieters muss ordnungsgemäß beschriftet sein, damit sie für Apps zugänglich zu machen. Wenn der Zugriff für Apps (einschließlich Apps von Drittanbietern), muss die Mediathek mit dem Label „same_process_hal_file“ gekennzeichnet sein in einer anbieterspezifischen file_contexts-Datei so an:
```
/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 vorübergehend durch ihre Abhängigkeiten von anderen Systembibliotheken als den VNDK-SP- und LLNDK-Bibliotheken abhängen. Suchen Sie die Liste der VNDK-SP- und LLNDK-Bibliotheken unter development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv

Ab Android 15 (AOSP experimentell) können öffentliche Bibliotheken des Anbieters in eine Anbieter APEX. Listen Sie die Bibliotheken auf, wenn sie in einem Anbieter-APEX verpackt sind. in einem provideNativeLibs-Attribut im APEX-Manifest.

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

Diese Funktion ist nur für Apps aktiviert, die auf SDK-Version 24 oder höher ausgerichtet sind. Informationen zur Abwärtskompatibilität finden Sie in der Tabelle 1.Was passiert, wenn Ihre App eine Verknüpfung mit privaten nativen Bibliotheken herstellt? Die Liste der nativen Android-Bibliotheken, auf die Apps zugreifen können (auch bekannt als öffentlichen nativen Bibliotheken) im CDD-Abschnitt 3.1.1 aufgeführt. Apps mit Ausrichtung auf 24 oder und bei Verwendung nicht öffentlicher Bibliotheken aktualisiert werden. Siehe NDK Weitere Informationen zu Apps, die mit Plattformbibliotheken verknüpft sind

Anwendungen für ihre nativen Bibliotheksabhängigkeiten aktualisieren

Apps, die auf SDK-Version 31 (Android 12) oder höher ausgerichtet sind, die Abhängigkeiten ihrer nativen gemeinsam genutzten Bibliothek explizit mit der Methode <uses-native-library>-Tag im App-Manifest ein. Wenn ein Teil der angeforderten keine Bibliothek auf dem Gerät vorhanden ist, wurde die App nicht installiert. Sobald die Apps installiert sind, nur die nativen gemeinsam genutzten Bibliotheken bereitgestellt, die sie angefordert haben. Das bedeutet, dass Apps können nicht auf native gemeinsam genutzte Bibliotheken zugreifen, die nicht im App-Manifest aufgeführt sind.