In Android-Anwendungen können in der Datei build.gradle eine Reihe von SDK-Versionsattributen festgelegt werden. In der Android-Dokumentation für build.gradle wird erläutert, was diese Eigenschaften für die Anwendung im Allgemeinen bedeuten. In diesem Dokument wird erläutert, wie sich diese Eigenschaften auf NDK-Builds auswirken.
compileSdkVersion
Diese Property hat keine Auswirkungen auf NDK-Builds. Die API-Verfügbarkeit für das NDK wird stattdessen durch minSdkVersion geregelt. Das liegt daran, dass C++-Symbole beim Laden der Bibliothek sofort aufgelöst werden und nicht erst bei ihrem ersten Aufruf (wie in Java). Wenn Sie Symbole verwenden, die nicht in der minSdkVersion verfügbar sind, kann die Bibliothek in Betriebssystemversionen, die die neuere API nicht haben, nicht geladen werden. Das gilt unabhängig davon, ob diese APIs aufgerufen werden oder nicht.
Wählen Sie für eine neue App die neueste verfügbare Version aus. Aktualisieren Sie eine vorhandene App bei Gelegenheit auf die neueste Version.
targetSdkVersion
Ähnlich wie bei Java kann sich die targetSdkVersion Ihrer App auf das Laufzeitverhalten von nativem Code auswirken. Verhaltensänderungen im System werden, sofern möglich, nur auf Apps mit einem targetSdkVersion angewendet, das größer oder gleich der Betriebssystemversion ist, in der die Änderung eingeführt wurde.
Wählen Sie für eine neue App die neueste verfügbare Version aus. Aktualisieren Sie diese für eine vorhandene App auf die neueste Version, wenn es Ihnen passt (nachdem Sie compileSdkVersion aktualisiert haben).
Während Anwendungsentwickler im Allgemeinen die targetSdkVersion ihrer App kennen, ist diese API für Bibliotheksentwickler nützlich, die nicht wissen können, welche targetSdkVersion ihre Nutzer auswählen.
Zur Laufzeit können Sie die von einer Anwendung verwendete targetSdkVersion abrufen, indem Sie android_get_application_target_sdk_version() aufrufen. Diese API ist ab API-Level 24 verfügbar. Diese Funktion hat die folgende Signatur:
/**
* Returns the `targetSdkVersion` of the caller, or `__ANDROID_API_FUTURE__` if
* there is no known target SDK version (for code not running in the context of
* an app).
*
* The returned values correspond to the named constants in `<android/api-level.h>`,
* and is equivalent to the AndroidManifest.xml `targetSdkVersion`.
*
* See also android_get_device_api_level().
*
* Available since API level 24.
*/
int android_get_application_target_sdk_version() __INTRODUCED_IN(24);
Andere Verhaltensänderungen hängen möglicherweise vom API-Level des Geräts ab. Sie können den API-Level des Geräts, auf dem Ihre Anwendung ausgeführt wird, abrufen, indem Sie android_get_device_api_level() aufrufen. Diese Funktion hat die folgende Signatur:
/**
* Returns the API level of the device we're actually running on, or -1 on failure.
* The returned values correspond to the named constants in `<android/api-level.h>`,
* and is equivalent to the Java `Build.VERSION.SDK_INT` API.
*
* See also android_get_application_target_sdk_version().
*/
int android_get_device_api_level();
Wenn Sie die API-Levels von Geräten abrufen, kann NDK-Code dynamisch auf Verhaltensänderungen auf der Plattform reagieren. Da API-Nebenversionen nicht an Verhaltensänderungen gebunden sind und wir derzeit nicht planen, neue NDK-Funktionen in API-Nebenversionen hinzuzufügen, ist es nicht möglich, das vollständige Geräte-API-Level direkt über einen NDK-Aufruf abzurufen.
Sie können entweder dlopen()/dlsym() oder schwache API-Verweise verwenden, um neuere APIs aufzurufen, als in Ihrem minSdkVersion angegeben ist.
maxSdkVersion
Diese Property hat keine Auswirkungen auf NDK-Builds.
minSdkVersion
Die in Ihrer build.gradle-Datei festgelegte minSdkVersion bestimmt, welche APIs zur Build-Zeit verfügbar sind. Weitere Informationen dazu, warum sich dies von Java-Builds unterscheidet, finden Sie unter compileSdkVersion. Außerdem wird damit die Mindestversion des Betriebssystems festgelegt, mit der Ihr Code kompatibel ist.
Das minSdkVersion wird vom NDK verwendet, um zu bestimmen, welche Funktionen beim Kompilieren Ihres Codes verwendet werden dürfen. Mit dieser Eigenschaft wird beispielsweise festgelegt, welche FORTIFY-Funktionen in libc verwendet werden. Außerdem können damit Leistungs- oder Größenoptimierungen (z. B. GNU-Hashes oder RELR) für Ihre Binärdateien aktiviert werden, die nicht mit älteren Android-Versionen kompatibel sind. Auch wenn Sie keine neuen APIs verwenden, bestimmt diese Eigenschaft weiterhin die mindestens unterstützte Betriebssystemversion Ihres Codes.
Bei einer neuen App finden Sie die Daten zur Nutzerverteilung im Assistenten für neue Projekte in Android Studio oder auf apilevels.com. Wählen Sie ein ausgewogenes Verhältnis zwischen potenziellem Marktanteil und Wartungskosten. Je niedriger Ihr minSdkVersion ist, desto mehr Zeit müssen Sie für die Behebung alter Fehler und das Hinzufügen von Fallback-Verhaltensweisen für Funktionen aufwenden, die noch nicht implementiert wurden.
Bei einer bestehenden App sollten Sie das minSdkVersion erhöhen, wenn sich die Wartungskosten für alte API-Levels nicht mehr lohnen, oder senken, wenn Ihre Nutzer dies verlangen und die neuen Wartungskosten sich lohnen. In der Play Console finden Sie Messwerte, die sich speziell auf die Nutzerverteilung Ihrer App beziehen.
Die minSdkVersion Ihrer Anwendung wird dem Präprozessor über das Makro __ANDROID_MIN_SDK_VERSION__ zur Verfügung gestellt. Das alte Makro __ANDROID_API__ ist identisch, aber __ANDROID_MIN_SDK_VERSION__ ist vorzuziehen, da seine Bedeutung klarer ist. Dieses Makro wird automatisch von Clang definiert. Es muss also kein Header eingebunden werden, um es zu verwenden. Bei NDK-Builds ist dieses Makro immer definiert.