Namespaces für native Bibliotheken

Android 7.0 hat Namespaces für native Bibliotheken eingeführt, um die Sichtbarkeit der internen API einzuschränken und Situationen zu lösen, in denen Apps versehentlich Plattformbibliotheken anstelle ihrer eigenen verwenden. Informationen zu anwendungsspezifischen Ä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 ). 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, auf die Apps zugreifen können, indem sie sie unter den jeweiligen Bibliotheksordnern platzieren und 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_.-]+ ; 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.

Systemeigene Bibliotheken in der system , die von Geräteherstellern veröffentlicht werden, MÜSSEN lib*COMPANYNAME.so , zum Beispiel libFoo.awesome.company.so . Mit anderen Worten, libFoo.so ohne den Firmennamenszusatz 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 werden, 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 im Anbieter 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 bezeichnet 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ängen. 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 erwarten können, wenn Ihre App mit privaten nativen Bibliotheken verknüpft wird . Die Liste der nativen Android-Bibliotheken, auf die Apps zugreifen können (auch bekannt als öffentliche native Bibliotheken), ist in CDD-Abschnitt 3.1.1 aufgeführt. Apps, die auf 24 oder höher abzielen und alle nicht-öffentlichen Bibliotheken verwenden, sollten aktualisiert werden. Weitere Einzelheiten finden Sie unter Verknüpfung von NDK-Apps mit Plattformbibliotheken .

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 gemeinsam genutzten Bibliotheksabhängigkeiten explizit angeben , indem sie das <uses-native-library> -Tag im App-Manifest verwenden. Wenn ein Teil der angeforderten Bibliothek nicht auf dem Gerät vorhanden ist, wird die App nicht installiert. Wenn die Apps installiert sind, werden ihnen nur die angeforderten nativen gemeinsam genutzten Bibliotheken bereitgestellt. Das bedeutet, dass Apps nicht auf native freigegebene Bibliotheken zugreifen können, die nicht im App-Manifest erscheinen.