Namespaces für native Bibliotheken

Mit Android 7.0 wurden Namespaces für native Bibliotheken eingeführt, um die interne API-Sichtbarkeit einzuschränken und Situationen zu beheben, in denen Apps versehentlich Plattformbibliotheken anstelle ihrer eigenen verwenden. Anwendungsspezifische Änderungen finden Sie im Blogbeitrag „Improving Stability with Private C/C++ Symbol Restrictions in Android 7.0 Android Developers“.

Die Architektur

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

Namespaces für native Bibliotheken

Abbildung 1. Namespaces für native Bibliotheken

Namespaces für native Bibliotheken verhindern, dass Apps native APIs privater Plattformen verwenden (wie dies bei OpenSSL der Fall war). Es beseitigt auch Situationen, in denen Apps versehentlich Plattformbibliotheken anstelle ihrer eigenen verwenden (wie bei libpng beobachtet). Für App-Bibliotheken ist es schwierig, versehentlich interne Systembibliotheken zu verwenden (und umgekehrt).

Hinzufügen zusätzlicher nativer Bibliotheken

Zusätzlich zu den standardmäßigen öffentlichen nativen Bibliotheken können Siliziumanbieter (ab Android 7.0) und Gerätehersteller (ab Android 9) zusätzliche native Bibliotheken bereitstellen, die für Apps zugänglich sind, indem sie diese in den jeweiligen Bibliotheksordnern ablegen und sie explizit in .txt auflisten Dateien.

Die Bibliotheksordner sind:

  • /vendor/lib (für 32-Bit) und /vendor/lib64 (für 64-Bit) für Bibliotheken von Siliziumanbietern
  • /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 Siliziumanbietern
  • /system/etc/public.libraries-COMPANYNAME.txt für Bibliotheken von Geräteherstellern, wobei COMPANYNAME auf einen Namen des Herstellers verweist (z. B. awesome.company ). COMPANYNAME muss mit [A-Za-z0-9_.-]+ übereinstimmen; Alphanumerische Zeichen, _, . (Punkt) und -. Es ist möglich, mehrere solcher TXT-Dateien auf einem Gerät zu haben, wenn einige Bibliotheken von externen Lösungsanbietern stammen.

Native Bibliotheken in der system , die von Geräteherstellern veröffentlicht werden, MÜSSEN den Namen lib*COMPANYNAME.so tragen, zum Beispiel libFoo.awesome.company.so . Mit anderen Worten, libFoo.so ohne das Firmennamensuffix DARF NICHT veröffentlicht werden. Der COMPANYNAME im Bibliotheksdateinamen MUSS mit dem COMPANYNAME im TXT-Dateinamen übereinstimmen, in dem der Bibliotheksname aufgeführt ist.

Native Bibliotheken, die Teil von AOSP sind, DÜRFEN NICHT öffentlich gemacht werden (mit Ausnahme der standardmäßigen öffentlichen nativen Bibliotheken, die standardmäßig öffentlich sind). Nur die zusätzlichen Bibliotheken, die von Siliziumanbietern oder Geräteherstellern hinzugefügt wurden, können Apps zugänglich gemacht werden.

Ab Android 8.0 gelten für öffentliche Bibliotheken von Anbietern die folgenden zusätzlichen Einschränkungen und erforderlichen Setups:

  1. Die native Bibliothek des Anbieters muss ordnungsgemäß gekennzeichnet sein, damit Apps darauf zugreifen können. Wenn der Zugriff von Apps (einschließlich Apps von Drittanbietern) erforderlich ist, muss die Bibliothek in einer herstellerspezifischen file_contexts Datei wie folgt als same_process_hal_file gekennzeichnet werden: 
    /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
    wobei libnative.so der Name der nativen Bibliothek ist.
  2. Die Bibliothek darf weder direkt noch transitiv über ihre Abhängigkeiten von anderen Systembibliotheken als VNDK-SP- und LLNDK-Bibliotheken abhängig sein. Suchen Sie die Liste der VNDK-SP- und LLNDK-Bibliotheken unter development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv .

Aktualisieren von Apps, um keine nicht öffentlichen nativen Bibliotheken zu verwenden

Diese Funktion ist nur für Anwendungen aktiviert, die auf SDK-Version 24 oder höher abzielen. Informationen zur Abwärtskompatibilität finden Sie in Tabelle 1. Was Sie erwartet, 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 bekannt), ist im CDD-Abschnitt 3.1.1 aufgeführt. Apps, die auf 24 oder höher ausgerichtet sind und nicht öffentliche Bibliotheken verwenden, sollten aktualisiert werden. Weitere Einzelheiten finden Sie unter NDK-Apps mit Plattformbibliotheken verknüpfen .

Aktualisieren von Apps für ihre nativen Bibliotheksabhängigkeiten

Anwendungen, die auf SDK-Version 31 (Android 12) oder höher abzielen, müssen ihre nativen Abhängigkeiten von gemeinsam genutzten Bibliotheken explizit angeben , indem sie das Tag <uses-native-library> im App-Manifest verwenden. Wenn ein Teil der angeforderten Bibliothek nicht auf dem Gerät vorhanden ist, ist die App nicht installiert. Wenn die Apps installiert sind, werden ihnen nur die nativen gemeinsam genutzten Bibliotheken bereitgestellt, die sie angefordert haben. Dies bedeutet, dass Apps nicht auf native gemeinsam genutzte Bibliotheken zugreifen können, die nicht im App-Manifest angezeigt werden.