Home / Android-Entwicklung / unser erstes Long Term Support Release

unser erstes Long Term Support Release

Gepostet von Dan Albert, Technischer Leiter von Android NDK

Android NDK r21 ist jetzt in der Beta! Es war ein längerer Entwicklungszyklus als üblich (vier Monate seit NDK r20), daher gibt es für diese Version eine Menge zu besprechen.

Wir verfügen über die üblichen Toolchain-Updates, verbesserte Standardeinstellungen für mehr Sicherheit und Leistung und nehmen Änderungen an unserem Veröffentlichungsprozess vor, um Benutzern, die Stabilität benötigen, eine bessere Anpassung zu ermöglichen, ohne diejenigen zu behindern, die neue Funktionen wünschen.

Neue Mindestsystemanforderungen

Diese Version enthält neue Mindestsystemanforderungen. Nach Android Studio und dem SDK wird 32-Bit-Windows nicht mehr unterstützt. Obwohl diese Änderung die meisten Entwickler nicht betrifft, hat diese Änderung Auswirkungen, wenn Sie 32-Bit-Versionen von Microsoft® Windows® verwenden. Linux-Benutzer müssen glibc 2.17 oder neuer haben.

Änderungen des Release-Zyklus und LTS

Ein Release pro Jahr ist unser Long Term Support-Release (LTS) für Benutzer, die mehr Stabilität wünschen als neue Funktionen benötigen. Die Veröffentlichung wird vor der Veröffentlichung einen längeren Betazyklus durchlaufen und bis zur Veröffentlichung der LTS im nächsten Jahr Fehlerbehebungen als Backports erhalten. Unsere erste LTS-Version, die im vierten Quartal veröffentlicht wird, ist NDK r21.

Die Nicht-LTS-Releases jedes Jahr, die wir als "Rolling Release" bezeichnen, werden unserem aktuellen Prozess ähneln. Dies sind ungefähr vierteljährliche Releases unserer neuesten Funktionen, die erst später für wichtige Toolchain-Korrekturen gepatcht werden. Wenn Sie die neuesten Funktionen von Clang und libc ++ möchten, ist dies die richtige Version für Sie.

Weitere Details, einschließlich der Kriterien, anhand derer wir bestimmen, welche Backports erstellt werden, welche Arten von Fehlern eine Punktveröffentlichung auslösen, und der Balken, den wir für jede Veröffentlichung halten, sind in unserem GitHub-Wiki dokumentiert.

Neue Funktionen und Updates

In dieser Version gibt es eine Reihe neuer Funktionen, mit denen Sie Fehler beheben und besseren und sichereren Code schreiben können.

Wir haben GNU Make auf Version 4.2 aktualisiert, wodurch - output-sync verhindert wird, dass Ausgaben mit Fehlermeldungen verschachtelt werden. Dies ist standardmäßig mit ndk-build aktiviert. Dies beinhaltet auch eine Reihe von Fehlerkorrekturen, einschließlich der Behebung der lästigen CreateProcess-Fehler unter Windows .

GDB wurde auf Version 8.3 aktualisiert, die Korrekturen zum Debuggen moderner Intel-CPUs enthält.

LLVM aktualisiert

Wie immer haben wir LLVM und alle seine Komponenten (Clang, lld, libc ++ usw.) aktualisiert, die viele Verbesserungen enthalten.

Die Toolchain wurde auf r365631 (der Master-Zweig vom 10. Juli 2019) aktualisiert. Dies beinhaltet Korrekturen für eine ganze Reihe von Fehlern in der vorherigen Version, wobei LLD möglicherweise nicht mehr hängt, wenn Multithread-Verknüpfungen unter Windows verwendet werden. OpenMP ist jetzt als dynamische Bibliothek verfügbar (und dies ist das neue Standardverhalten. Verknüpfen Sie also mit -static-openmp wenn Sie bei der statischen Laufzeit bleiben möchten).

Es wurden einige Treiberverbesserungen vorgenommen, um den Umfang der Compilerkonfiguration zu verringern, die auch für jedes Buildsystem erforderlich ist. Build-System-Besitzer sollten das aktualisierte Build System Maintainers-Handbuch lesen.

libc ++ wurde auf r369764 aktualisiert.

Fortify

Fortify ist jetzt standardmäßig aktiviert, wenn ndk-build oder die CMake-Toolchain-Datei verwendet wird (dies schließt ExternalNativeBuild Benutzer ein). Fortify aktiviert zusätzliche Überprüfungen in der Standardbibliothek, die helfen können, Fehler früher zu erkennen und Sicherheitsprobleme zu verringern. Beispiel: Ohne Verstärkung wird der folgende Code einwandfrei kompiliert:



const char src [] 
 = "Diese Zeichenfolge ist zu lang";
    char dst [10] 
;
    strcpy (dst, src);

Mit Fortify wird der Pufferüberlauf zur Kompilierungszeit diagnostiziert:



     test.cpp: 10: 18: Fehler: 'strcpy' wird mit einer Zeichenfolge aufgerufen, die größer als der Puffer ist
      strcpy (dst, src);
                     ^

Es ist nicht immer möglich, dass der Compiler dieses Problem beim Kompilieren erkennt. In diesen Fällen wird stattdessen eine Laufzeitprüfung verwendet, die dazu führt, dass das Programm abgebrochen wird, anstatt unsicher fortzufahren.

Wenn Sie ein anderes Build-System als ndk-build oder CMake über die NDK-Toolchain-Datei verwenden, wird dies nicht standardmäßig aktiviert. Zum Aktivieren definieren Sie einfach _FORTIFY_SOURCE = 2 . Der zuverlässigste Weg, dies zu tun, ist das Hinzufügen von -D_FORTIFY_SOURCE = 2 zu Ihren Compiler-Flags.

Clang kann einige dieser Probleme auch statisch erkennen, indem er -Wfortify-source verwendet (ebenfalls neu in r21). Dies ist standardmäßig aktiviert, es wird jedoch empfohlen, die Behebung von Problemen mit -Werror = fortify-source zu erzwingen. Verwenden Sie dies zusätzlich zu den Funktionen der C-Bibliothek, nicht stattdessen, da die Warnungen nicht dieselben Fälle wie die Erweiterung der C-Bibliothek abdecken und auch keine Laufzeitprüfungen hinzufügen können.

Beachten Sie, dass der genaue Satz der durch fortify geschützten APIs von Ihrer minSdkVersion abhängt, da Laufzeitunterstützung für fortify erforderlich ist und die Funktion im Laufe der Zeit schrittweise zu Android hinzugefügt wurde. Fortify ist eine Verbesserung, aber kein Ersatz für gute Tests, ASan und das Schreiben von sicherem Code.

Unter FORTIFY in Android finden Sie eine ausführliche Erläuterung von Fortify.

Weitere Updates

64-Bit-Anforderung

Seit August 2019 müssen alle vorhandenen und neuen Apps 64-Bit unterstützen, bevor sie für Google Play freigegeben werden können. Es gibt eine Erweiterung für eine begrenzte Anzahl von Apps. Weitere Informationen und Hilfe zum Hinzufügen von Unterstützung für 64-Bit finden Sie in unserem Handbuch.

Neon standardmäßig

Der Aktivierungscode wird jetzt standardmäßig mit Neon erstellt. In einer früheren Version haben wir es bedingt aktiviert, basierend auf minSdkVersion, aber angesichts der sehr geringen Anzahl von Geräten, die Neon nicht unterstützen, können wir es jetzt bedingungslos aktivieren. Dies bietet eine verbesserte Leistung auf allen 32-Bit-Arm-Geräten (64-Bit-Arm hatte dies immer, und es wirkt sich nicht auf Intel ABIs aus).

Wie zuvor kann dieses Verhalten für Apps deaktiviert werden, die weiterhin Geräte ohne Neon unterstützen müssen. Alternativ können diese Geräte in der Play Console auf die Blacklist gesetzt werden. Weitere Informationen finden Sie unter https://developer.android.com/ndk/guides/cpu-arm-neon.

Nach oben Weiter

Sehen Sie in unserer Roadmap nach, woran wir als Nächstes arbeiten. Die nächsten großen Aufgaben sind die Paketverwaltung und eine bessere CMake-Integration.

About AndroidWeltEditor

Check Also

Wie Android-Entwickler Benutzer auf jedem Gerät erreichen können

Gepostet von Allan Livingston, Produktmanagementdirektor, Chrome OS App Ecosystem Android unterstützt mobile Apps auf Geräten, …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.