Einschränkungen für Nicht-SDK-Schnittstellen

Ab Android 9 (API-Level 28) schränkt die Plattform ein, welche nicht SDK-Schnittstellen Ihre App verwenden kann. Diese Einschränkungen gelten immer dann, wenn eine App auf eine Nicht-SDK-Schnittstelle verweist oder versucht, ihren Handle mithilfe von Reflection oder JNI abzurufen. Diese Einschränkungen wurden eingeführt, um die Nutzer- und Entwicklerfreundlichkeit zu verbessern und das Risiko von Abstürzen für Nutzer und Notfall-Roll-outs für Entwickler zu verringern. Weitere Informationen zu dieser Entscheidung finden Sie unter Stabilität durch geringere Nutzung von Nicht-SDK-Schnittstellen verbessern.

Zwischen SDK- und Nicht-SDK-Schnittstellen unterscheiden

Im Allgemeinen sind öffentliche SDK-Schnittstellen diejenigen, die im Paketindex des Android-Frameworks dokumentiert sind. Die Verarbeitung von Nicht-SDK-Benutzeroberflächen ist ein Implementierungsdetail, das von der API abstrahiert wird. Daher können diese Benutzeroberflächen ohne vorherige Ankündigung geändert werden.

Um Abstürze und unerwartetes Verhalten zu vermeiden, sollten Apps nur die offiziell dokumentierten Teile der Klassen im SDK verwenden. Das bedeutet auch, dass Sie nicht auf Methoden oder Felder zugreifen sollten, die nicht im SDK aufgeführt sind, wenn Sie mit einer Klasse über Mechanismen wie Reflection interagieren.

Listen für Nicht-SDK-APIs

Mit jedem neuen Release von Android werden weitere Nicht-SDK-Schnittstellen eingeschränkt. Uns ist bewusst, dass sich diese Einschränkungen auf Ihren Release-Workflow auswirken können. Wir möchten Ihnen daher die Möglichkeit geben, die Nutzung von Nicht-SDK-Schnittstellen zu erkennen, Feedback zu geben und die neuen Richtlinien zu planen und anzupassen.

Um die Auswirkungen von Einschränkungen für Nicht-SDKs auf Ihren Entwicklungsablauf zu minimieren, sind die Nicht-SDK-Schnittstellen in Listen unterteilt, in denen festgelegt ist, wie stark ihre Verwendung eingeschränkt ist, je nachdem, auf welche API-Ebene das Ziel ausgerichtet ist. In der folgenden Tabelle werden die einzelnen Listen beschrieben:

Liste Code-Tags Beschreibung
Sperrliste
  • blocked
  • Eingestellt: blacklist
 Nicht-SDK-Schnittstellen, die Sie unabhängig von der Ziel-API-Ebene Ihrer App nicht verwenden können. Wenn Ihre App versucht, auf eine dieser Schnittstellen zuzugreifen, wird ein Fehler vom System ausgegeben.
Bedingt blockiert
  • max-target-x
  • Eingestellt: greylist-max-x

Ab Android 9 (API-Level 28) hat jede API-Ebene Nicht-SDK-Schnittstellen, die eingeschränkt sind, wenn eine App auf diese API-Ebene ausgerichtet ist.

Diese Listen sind mit der maximalen API-Ebene (max-target-x) gekennzeichnet, auf die eine App ausgerichtet werden kann, bevor sie nicht mehr auf die nicht SDK-Schnittstellen in dieser Liste zugreifen kann. Eine nicht SDK-Schnittstelle, die unter Android Pie nicht blockiert war, aber jetzt unter Android 10 blockiert ist, ist beispielsweise Teil der Liste max-target-p (greylist-max-p), wobei „p“ für Pie oder Android 9 (API-Ebene 28) steht.

Wenn Ihre App versucht, auf eine Oberfläche zuzugreifen, die für Ihr Ziel-API-Level eingeschränkt ist, verhält sich das System so, als wäre die API Teil der Blockliste.
Nicht unterstützt
  • unsupported
  • Eingestellt: greylist
 Nicht-SDK-Schnittstellen, die uneingeschränkt verwendet werden können und von Ihrer App verwendet werden. Beachten Sie jedoch, dass diese Schnittstellen nicht unterstützt werden und ohne vorherige Ankündigung geändert werden können. Diese Schnittstellen werden in zukünftigen Android-Versionen voraussichtlich bedingt in einer max-target-x-Liste blockiert.
SDK
  • Sowohl public-api als auch sdk
  • Eingestellt: Sowohl public-api als auch whitelist
 Oberflächen, die frei verwendet werden können und jetzt im Rahmen des offiziell dokumentierten Android-Frameworks Package Index unterstützt werden.
APIs testen
  • test-api
 Schnittstellen, die für interne Systemtests verwendet werden, z. B. APIs, die Tests über die Compatibility Test Suite (CTS) ermöglichen. Test-APIs sind nicht Teil des SDKs. Ab Android 11 (API-Level 30) sind Test-APIs in der Blockierungsliste enthalten. Sie dürfen also unabhängig vom Ziel-API-Level nicht mehr in Apps verwendet werden. Alle Test-APIs werden nicht unterstützt und können unabhängig vom API-Level der Plattform ohne vorherige Ankündigung geändert werden.

Sie können einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Ebene Ihrer App). Die Verwendung von Nicht-SDK-Methoden oder ‑Feldern birgt jedoch immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Schnittstellen oder anderen Alternativen beginnen. Wenn Sie keine Alternative zur Verwendung einer Nicht-SDK-Benutzeroberfläche für eine Funktion in Ihrer App finden, sollten Sie eine neue öffentliche API anfordern.

Feststellen, zu welcher Liste eine Benutzeroberfläche gehört

Die Listen der Nicht-SDK-Benutzeroberflächen werden als Teil der Plattform erstellt. In den folgenden Abschnitten finden Sie Informationen zu den einzelnen Android-Releases.

Android 16 (Entwicklervorschau)

Für Android 16 können Sie die folgende Datei herunterladen, in der alle Nicht-SDK-Schnittstellen und die entsprechenden Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: a22d5c2fa9c24ec0b864f0680208e9794222d1921114abe3245979143ce6d1c6

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 16 finden Sie unter Änderungen an den Einschränkungen für Nicht-SDK-Schnittstellen in Android 16.

Android 15

Für Android 15 (API-Level 35) können Sie die folgende Datei herunterladen, in der alle nicht SDK-spezifischen Schnittstellen und die entsprechenden Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 40134e205e58922a708c453726b279a296e6a1f34a988abd90cec0f3432ea5a9

Weitere Informationen zu den Änderungen an der Liste der nicht SDK-spezifischen APIs in Android 15 finden Sie unter Änderungen an den Einschränkungen für nicht SDK-spezifische Schnittstellen in Android 15.

Android 14

Für Android 14 (API-Level 34) können Sie die folgende Datei herunterladen, in der alle nicht SDK-spezifischen Schnittstellen und die entsprechenden Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 14 finden Sie unter Änderungen an den Einschränkungen für Nicht-SDK-Schnittstellen in Android 14.

Android 13

Für Android 13 (API-Level 33) können Sie die folgende Datei herunterladen, in der alle nicht SDK-Schnittstellen und die entsprechenden Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 233a277aa8ac475b6df61bffd95665d86aac6eb2ad187b90bf42a98f5f2a11a3

Weitere Informationen zu den Änderungen an der Liste der nicht SDK-spezifischen APIs in Android 13, einschließlich vorgeschlagener öffentlicher API-Alternativen für APIs, die in Android 13 bedingt blockiert sind, finden Sie unter Änderungen an den Einschränkungen für nicht SDK-spezifische Schnittstellen in Android 13.

Android 12

Für Android 12 (API-Level 31) können Sie die folgende Datei herunterladen, in der alle nicht SDK-spezifischen Schnittstellen und die entsprechenden Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761

Weitere Informationen zu den Änderungen an der Liste der nicht SDK-spezifischen APIs in Android 12, einschließlich vorgeschlagener öffentlicher API-Alternativen für APIs, die in Android 12 bedingt blockiert sind, finden Sie unter Liste der Änderungen für Android 12.

Android 11

Für Android 11 (API-Level 30) können Sie die folgende Datei herunterladen, in der alle nicht SDK-spezifischen Schnittstellen und die entsprechenden Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56

Weitere Informationen zu den Änderungen an der Liste der nicht SDK-spezifischen APIs in Android 11, einschließlich vorgeschlagener öffentlicher API-Alternativen für APIs, die in Android 11 bedingt blockiert sind, finden Sie unter Änderungen an der Liste für Android 11.

Android 10

Für Android 10 (API-Level 29) können Sie die folgende Datei herunterladen, in der alle nicht SDK-spezifischen Schnittstellen und die entsprechenden Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb

Weitere Informationen zu den Änderungen an der Liste der nicht SDK-APIs in Android 10, einschließlich vorgeschlagener öffentlicher API-Alternativen für APIs, die in Android 10 bedingt blockiert sind, finden Sie unter List changes for Android 10 (Änderungen an der Liste für Android 10).

Android 9

Für Android 9 (API-Level 28) enthält die folgende Textdatei eine Liste der nicht SDK-spezifischen APIs, die nicht eingeschränkt sind (graue Liste): hiddenapi-light-greylist.txt.

Die Sperrliste (blacklist) und die Liste der bedingt blockierten APIs (dunkelgraue Liste) werden zum Zeitpunkt des Builds abgeleitet.

Listen aus AOSP generieren

Wenn Sie mit AOSP arbeiten, können Sie eine hiddenapi-flags.csv-Datei generieren, die alle nicht SDK-Schnittstellen und die entsprechenden Listen enthält. Laden Sie dazu die AOSP-Quelle herunter und führen Sie dann den folgenden Befehl aus:

m out/soong/hiddenapi/hiddenapi-flags.csv

Sie finden die Datei dann unter folgendem Pfad:

out/soong/hiddenapi/hiddenapi-flags.csv

Erwartetes Verhalten beim Zugriff auf eingeschränkte Nicht-SDK-Schnittstellen

In der folgenden Tabelle wird beschrieben, was passiert, wenn Ihre App versucht, auf eine nicht SDK-basierte Benutzeroberfläche zuzugreifen, die sich auf der Sperrliste befindet.

Zugriffsmittel Ergebnis
Dalvik-Anweisung, die auf ein Feld verweist NoSuchFieldError ausgelöst
Dalvik-Anweisung, die auf eine Methode verweist NoSuchMethodError ausgelöst
Reflexion mit Class.getDeclaredField() oder Class.getField() NoSuchFieldException ausgelöst
Reflexion mit Class.getDeclaredMethod(), Class.getMethod() NoSuchMethodException ausgelöst
Reflexion mit Class.getDeclaredFields(), Class.getFields() Nicht-SDK-Mitglieder werden nicht in den Ergebnissen angezeigt
Reflexion mit Class.getDeclaredMethods(), Class.getMethods() Nicht-SDK-Mitglieder werden nicht in den Ergebnissen angezeigt
JNI mit env->GetFieldID() NULL zurückgegeben, NoSuchFieldError ausgelöst
JNI mit env->GetMethodID() NULL zurückgegeben, NoSuchMethodError ausgelöst

App auf Nicht-SDK-Schnittstellen testen

Es gibt mehrere Methoden, mit denen Sie in Ihrer App nach Nicht-SDK-Schnittstellen suchen können.

Mit einer debugfähigen App testen

Sie können Nicht-SDK-Schnittstellen testen, indem Sie eine debuggbare App auf einem Gerät oder Emulator mit Android 9 (API-Level 28) oder höher erstellen und ausführen. Achten Sie darauf, dass das von Ihnen verwendete Gerät oder der von Ihnen verwendete Emulator mit dem Ziel-API-Level Ihrer App übereinstimmt.

Während der Tests Ihrer App gibt das System eine Protokollmeldung aus, wenn Ihre App auf bestimmte Nicht-SDK-Schnittstellen zugreift. In den Protokollmeldungen Ihrer App finden Sie die folgenden Details:

  • Die deklarierende Klasse, der Name und der Typ (im Format, das von der Android-Laufzeit verwendet wird).
  • Die Zugriffsmethode: Verknüpfung, Reflection oder JNI.
  • Zu welcher Liste die Nicht-SDK-Benutzeroberfläche gehört.

Sie können mit adb logcat auf diese Protokollmeldungen zugreifen, die unter der PID der laufenden App angezeigt werden. Ein Eintrag im Protokoll könnte beispielsweise so aussehen:

Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)

Mit der StrictMode API testen

Sie können auch mit der StrictMode API nach Nicht-SDK-Schnittstellen suchen. Verwenden Sie die Methode detectNonSdkApiUsage, um diese Funktion zu aktivieren. Nachdem Sie die StrictMode API aktiviert haben, können Sie mithilfe einer penaltyListener einen Callback für jede Verwendung einer nicht SDK-Schnittstelle erhalten. Dort können Sie eine benutzerdefinierte Verarbeitung implementieren. Das im Callback bereitgestellte Violation-Objekt leitet sich von Throwable ab und der enthaltene Stack-Trace liefert den Kontext der Verwendung.

Mit dem Veridex-Tool testen

Sie können auch das Veridex-Tool zur statischen Analyse auf Ihrem APK ausführen. Das Veridex-Tool scannt die gesamte Codebasis des APK, einschließlich aller Bibliotheken von Drittanbietern, und meldet alle gefundenen Verwendungen von Nicht-SDK-Schnittstellen.

Zu den Einschränkungen des Veridex-Tools gehören:

  • Aufrufe über JNI können nicht erkannt werden.
  • Es kann nur einen Teil der Aufrufe durch Reflection erkennen.
  • Die Analyse inaktiver Codepfade ist auf Prüfungen auf API-Ebene beschränkt.
  • Sie kann nur auf Computern ausgeführt werden, die SSE4.2- und POPCNT-Anweisungen unterstützen.

Windows

Es werden keine nativen Windows-Binärdateien bereitgestellt. Sie können das Veridex-Tool jedoch unter Windows ausführen, indem Sie die Linux-Binärdateien über das Windows-Subsystem für Linux (WSL) ausführen. Bevor Sie die Schritte in diesem Abschnitt ausführen, installieren Sie die WSL und wählen Sie Ubuntu als Linux-Distribution aus.

Nachdem Ubuntu installiert ist, starten Sie ein Ubuntu-Terminal und führen Sie die folgenden Schritte aus:

  1. Laden Sie das veridex-Tool aus dem Repository für vorgefertigte Android-Laufzeitumgebungen herunter.
  2. Extrahieren Sie den Inhalt der Datei appcompat.tar.gz.
  3. Suchen Sie im extrahierten Ordner nach der Datei veridex-linux.zip und extrahieren Sie sie.

  4. Rufen Sie den entpackten Ordner auf und führen Sie den folgenden Befehl aus. Dabei steht your-app.apk für die APK-Datei, die Sie testen möchten:

    ./appcompat.sh --dex-file=your-app.apk

macOS

So führen Sie das Veridex-Tool unter macOS aus:

  1. Laden Sie das veridex-Tool aus dem Repository für vorgefertigte Android-Laufzeitumgebungen herunter.
  2. Extrahieren Sie den Inhalt der Datei appcompat.tar.gz.
  3. Suchen Sie im extrahierten Ordner nach der Datei veridex-mac.zip und extrahieren Sie sie.

  4. Rufen Sie den entpackten Ordner auf und führen Sie den folgenden Befehl aus. Dabei ist /path-from-root/your-app.apk der Pfad zum zu testenden APK, ausgehend vom Stammverzeichnis Ihres Systems:

    ./appcompat.sh --dex-file=/path-from-root/your-app.apk

Linux

So führen Sie das Veridex-Tool unter Linux aus:

  1. Laden Sie das veridex-Tool aus dem Repository für vorgefertigte Android-Laufzeitumgebungen herunter.
  2. Extrahieren Sie den Inhalt der Datei appcompat.tar.gz.
  3. Suchen Sie im extrahierten Ordner nach der Datei veridex-linux.zip und extrahieren Sie sie.

  4. Rufen Sie den entpackten Ordner auf und führen Sie den folgenden Befehl aus. Dabei steht your-app.apk für die APK-Datei, die Sie testen möchten:

    ./appcompat.sh --dex-file=your-app.apk

Mit dem Lint-Tool von Android Studio testen

Wenn Sie Ihre App in Android Studio erstellen, wird Ihr Code mit dem Lint-Tool auf mögliche Probleme geprüft. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, werden je nach Liste, zu der diese Schnittstellen gehören, möglicherweise Buildfehler oder Warnungen angezeigt.

Sie können das Lint-Tool auch über die Befehlszeile ausführen oder Prüfungen manuell für ein bestimmtes Projekt, einen bestimmten Ordner oder eine bestimmte Datei ausführen.

Mit der Play Console testen

Wenn Sie Ihre App in der Play Console in einen Test-Track hochladen, wird sie automatisch auf potenzielle Probleme geprüft und ein Pre-Launch-Bericht wird generiert. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, wird im Pre-Launch-Bericht je nach Liste, zu der diese Schnittstellen gehören, ein Fehler oder eine Warnung angezeigt.

Weitere Informationen finden Sie im Abschnitt zur Android-Kompatibilität im Hilfeartikel Pre-Launch-Berichte zum Erkennen von Problemen verwenden.

Neue öffentliche API anfordern

Wenn Sie keine Alternative zur Verwendung einer Nicht-SDK-Benutzeroberfläche für eine Funktion in Ihrer App finden, können Sie eine neue öffentliche API anfordern, indem Sie in unserem Issue Tracker eine Funktionsanfrage erstellen.

Geben Sie beim Erstellen einer Funktionsanfrage die folgenden Informationen an:

  • Welche nicht unterstützte API Sie verwenden, einschließlich des vollständigen Descriptors in der Accessing hidden ...-Logcat-Nachricht.
  • Warum Sie diese APIs verwenden müssen, einschließlich Details zur übergeordneten Funktion, für die die API erforderlich ist, nicht nur Details auf niedriger Ebene.
  • Warum die zugehörigen öffentlichen SDK-APIs für Ihre Zwecke nicht ausreichen.
  • Andere Alternativen, die Sie ausprobiert haben, und warum diese nicht funktioniert haben.

Wenn Sie diese Details in Ihrer Funktionsanfrage angeben, steigt die Wahrscheinlichkeit, dass eine neue öffentliche API gewährt wird.

Sonstige Fragen

In diesem Abschnitt finden Sie Antworten auf weitere häufig gestellte Fragen von Entwicklern:

Allgemeine Fragen

Wie kann Google sicher sein, dass die Anforderungen aller Apps über den Issuetracker erfasst werden können?

Die ersten Listen für Android 9 (API-Level 28) wurden durch eine statische Analyse von Apps erstellt, die mit den folgenden Methoden ergänzt wurde:

  • manuelle Tests der Top-Apps bei Google Play und anderer Anbieter
  • Interne Berichte
  • automatische Datenerhebung von internen Nutzern
  • Berichte zur Entwicklervorschau
  • eine zusätzliche statische Analyse, die konservativ mehr Falschalarme einbezieht

Bei der Bewertung der Listen für jede neue Version berücksichtigen wir die API-Nutzung sowie das Feedback der Entwickler über den Issue-Tracker.

Wie kann ich den Zugriff auf Nicht-SDK-Schnittstellen aktivieren?

Sie können den Zugriff auf Nicht-SDK-Schnittstellen auf Entwicklungsgeräten aktivieren, indem Sie mithilfe von adb-Befehlen die API-Durchsetzungsrichtlinie ändern. Die verwendeten Befehle variieren je nach API-Ebene. Für diese Befehle ist kein gerootetes Gerät erforderlich.

Android 10 (API-Level 29) oder höher

Verwenden Sie den folgenden adb-Befehl, um den Zugriff zu aktivieren:

command:

adb shell settings put global hidden_api_policy  1

Verwenden Sie den folgenden Befehl, um die API-Durchsetzungsrichtlinie auf die Standardeinstellungen zurückzusetzen:

adb shell settings delete global hidden_api_policy
Android 9 (API-Level 28)

Verwenden Sie die folgenden adb-Befehle, um den Zugriff zu aktivieren:

adb shell settings put global hidden_api_policy_pre_p_apps  1
adb shell settings put global hidden_api_policy_p_apps 1

Verwenden Sie die folgenden Befehle, um die API-Durchsetzungsrichtlinie auf die Standardeinstellungen zurückzusetzen:

adb shell settings delete global hidden_api_policy_pre_p_apps
adb shell settings delete global hidden_api_policy_p_apps

Sie können die Ganzzahl in der API-Durchsetzungsrichtlinie auf einen der folgenden Werte festlegen:

  • 0: Deaktiviert die Erkennung aller Nicht-SDK-Benutzeroberflächen. Wenn Sie diese Einstellung verwenden, werden alle Protokollmeldungen für die Verwendung einer Nicht-SDK-Benutzeroberfläche deaktiviert und Sie können Ihre App nicht mit der StrictMode API testen. Diese Einstellung wird nicht empfohlen.
  • 1: Zugriff auf alle Nicht-SDK-Benutzeroberflächen aktivieren, aber Protokollmeldungen mit Warnungen bei jeder Verwendung einer Nicht-SDK-Benutzeroberfläche ausgeben. Mit dieser Einstellung können Sie Ihre App auch mit der StrictMode API testen.
  • 2: Die Verwendung von Nicht-SDK-Schnittstellen, die auf der Sperrliste stehen oder für Ihre Ziel-API-Ebene bedingt blockiert sind, wird unterbunden.

Fragen zu Listen mit Nicht-SDK-Benutzeroberflächen

Wo finde ich die Listen der nicht SDK-APIs im System-Image?

Sie sind in den Flag-Bits für den Feld- und Methodenzugriff in Plattform-DEX-Dateien codiert. Im System-Image gibt es keine separate Datei, die diese Listen enthält.

Sind die Listen der nicht SDK-APIs auf verschiedenen OEM-Geräten mit denselben Android-Versionen identisch?

OEMs können der Sperrliste eigene Schnittstellen hinzufügen, aber keine Schnittstellen aus den AOSP-Listen für nicht SDK-APIs entfernen. Die CDD verhindert solche Änderungen und CTS-Tests sorgen dafür, dass die Liste von der Android Runtime erzwungen wird.

Gibt es Einschränkungen für Nicht-NDK-Schnittstellen in nativem Code?

Das Android SDK enthält Java-Schnittstellen. Ab Android 7 (API-Level 26) hat die Plattform den Zugriff auf nicht NDK-Schnittstellen für nativen C/C++-Code eingeschränkt. Weitere Informationen finden Sie unter Stabilität mit privaten C/C++-Symboleinschränkungen in Android N verbessern.

Ist geplant, die Manipulation von dex2oat- oder DEX-Dateien einzuschränken?

Wir haben derzeit keine Pläne, den Zugriff auf die dex2oat-Binärdatei einzuschränken. Wir beabsichtigen jedoch nicht, das DEX-Dateiformat stabil zu machen oder es über die Teile hinaus als öffentliche Schnittstelle zu verwenden, die im Dalvik-Ausführformat öffentlich spezifiziert sind. Wir behalten uns das Recht vor, dex2oat und die nicht näher bezeichneten Teile des DEX-Formats jederzeit zu ändern oder zu entfernen. Beachten Sie auch, dass abgeleitete Dateien, die von dex2oat erstellt wurden, wie ODEX (auch OAT genannt), VDEX und CDEX, alle als „Nicht spezifiziert“ gekennzeichnet sind.

Was ist, wenn ein wichtiges Drittanbieter-SDK (z. B. ein Obfuscator) nicht umhinkommt, nicht-SDK-Schnittstellen zu verwenden, sich aber verpflichtet, die Kompatibilität mit zukünftigen Android-Versionen aufrechtzuerhalten? Kann Android in diesem Fall von seinen Kompatibilitätsanforderungen absehen?

Wir haben nicht vor, Kompatibilitätsanforderungen pro SDK zu erlassen. Wenn ein SDK-Entwickler die Kompatibilität nur durch die Verwendung von Schnittstellen in den nicht unterstützten Listen (früher grau) aufrechterhalten kann, sollte er mit der Planung einer Migration zu SDK-Schnittstellen oder anderen Alternativen beginnen und eine neue öffentliche API anfordern, wenn er keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle findet.

Gelten Einschränkungen für nicht SDK-basierte Oberflächen für alle Apps, einschließlich System- und selbst entwickelter Apps, und nicht nur für Drittanbieter-Apps?

Ja, es gibt jedoch Ausnahmen für Apps, die mit dem Plattformschlüssel signiert sind, und für einige System-Image-Apps. Diese Ausnahmen gelten nur für Apps, die Teil des System-Images (oder aktualisierter System-Image-Apps) sind. Die Liste ist nur für Apps gedacht, die auf den privaten Plattform-APIs und nicht auf den SDK-APIs basieren (LOCAL_PRIVATE_PLATFORM_APIS := true).