Namespaces für native Bibliotheken

Mit Android 7.0 wurden Namespaces für native Bibliotheken eingeführt, um die Sichtbarkeit interner APIs einzuschränken und Situationen zu vermeiden, in denen Apps versehentlich Plattformbibliotheken anstelle ihrer eigenen verwenden. Informationen zu app-spezifischen Änderungen finden Sie im Blog für Android-Entwickler im Beitrag Improving Stability with Private C/C++ Symbol Restrictions in Android 7.0.

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 private native Plattform-APIs 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 öffentlichen Standardbibliotheken können Chiphersteller (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 einfügen und 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 Chipherstellern
  • /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. Es dürfen nur alphanumerische Zeichen, Unterstriche und Punkte verwendet werden. (Punkt) und „-“. Es ist möglich, dass mehrere solcher TXT-Dateien auf einem Gerät vorhanden sind, wenn einige Bibliotheken von externen Lösungsanbietern stammen.

Native Bibliotheken auf der system-Partition, die von Geräteherstellern öffentlich gemacht werden, MÜSSEN lib*COMPANYNAME.so heißen, z. B. libFoo.awesome.company.so. Anders ausgedrückt: libFoo.so ohne das Suffix für den Unternehmensnamen darf NICHT veröffentlicht werden. Die COMPANYNAME im Bibliotheksdateinamen MUSS mit der COMPANYNAME im Namen der TXT-Datei übereinstimmen, in der 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 Chipherstellern oder Geräteherstellern hinzugefügt wurden, können für Apps zugänglich gemacht werden.

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

  1. Die native Bibliothek im Anbieter muss richtig gekennzeichnet sein, damit Apps darauf zugreifen können. Wenn der Zugriff für Apps (einschließlich Drittanbieter-Apps) erforderlich ist, muss die Bibliothek in einer anbieterspezifischen file_contexts-Datei als 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.
  2. Die Bibliothek darf weder direkt noch transitiv über ihre Abhängigkeiten von anderen Systembibliotheken als VNDK-SP- und LLNDK-Bibliotheken abhängen. 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 einem Anbieter-APEX platziert werden. Wenn die Bibliotheken in einem Anbieter-APEX verpackt sind, listen Sie sie in einer provideNativeLibs-Property im APEX-Manifest auf.

Apps aktualisieren, damit keine nicht öffentlichen nativen Bibliotheken verwendet werden

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 Tabelle 1. Was passiert, wenn Ihre App private native Bibliotheken verknüpft? Die Liste der nativen Android-Bibliotheken, auf die Apps zugreifen können (auch als öffentliche native Bibliotheken bezeichnet), ist im CDD-Abschnitt 3.1.1 aufgeführt. Apps, die auf Android 24 oder höher ausgerichtet sind und nicht öffentliche Bibliotheken verwenden, sollten aktualisiert werden. Weitere Informationen finden Sie unter NDK-Apps, die mit Plattformbibliotheken verknüpft sind .

Apps für ihre nativen Bibliotheksabhängigkeiten aktualisieren

Apps, die auf SDK-Version 31 (Android 12) oder höher ausgerichtet sind, müssen ihre nativen Abhängigkeiten von gemeinsam genutzten Bibliotheken explizit angeben. Verwenden Sie dazu das Tag <uses-native-library> im App-Manifest. Wenn ein Teil der angeforderten Bibliothek auf dem Gerät nicht vorhanden ist, wird die App nicht installiert. Wenn die Apps installiert sind, werden ihnen nur die nativen gemeinsam genutzten Bibliotheken zur Verfügung gestellt, die sie angefordert haben. Das bedeutet, dass Apps nicht auf native freigegebene Bibliotheken zugreifen können, die nicht im App-Manifest aufgeführt sind.