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, ihr 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 verbessern durch Reduzierung der Nutzung von Nicht-SDK-Schnittstellen.

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-Schnittstellen ist ein Implementierungsdetail, das von der API abstrahiert wird. Diese Schnittstellen können daher ohne Vorankü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 beim Interagieren mit einer Klasse über Mechanismen wie Reflection nicht auf Methoden oder Felder zugreifen sollten, die nicht im SDK aufgeführt sind.

Listen von Nicht-SDK-APIs

Mit jedem Release von Android werden zusätzliche Nicht-SDK-Schnittstellen eingeschränkt. Wir wissen, dass sich diese Einschränkungen auf Ihren Release-Workflow auswirken können. Deshalb möchten wir Ihnen die Tools zur Verfügung stellen, mit denen Sie die Verwendung von Nicht-SDK-Schnittstellen erkennen können. Außerdem möchten wir Ihnen die Möglichkeit geben, Feedback zu geben, und Ihnen Zeit geben, sich auf die neuen Richtlinien vorzubereiten und Ihre Apps entsprechend anzupassen.

Um die Auswirkungen von Einschränkungen für Nicht-SDKs auf Ihren Entwicklungsablauf zu minimieren, werden die Nicht-SDK-Schnittstellen in Listen unterteilt, die definieren, wie stark ihre Verwendung eingeschränkt ist, je nachdem, welches API-Level als Ziel festgelegt 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 vom Ziel-API-Level Ihrer App nicht verwenden können. Wenn Ihre App versucht, auf eine dieser Schnittstellen zuzugreifen, gibt das System einen Fehler aus.
Bedingt blockiert
  • max-target-x
  • Eingestellt: greylist-max-x

Ab Android 9 (API-Level 28) enthält jedes API-Level Nicht-SDK-Schnittstellen, die eingeschränkt werden, wenn eine App auf dieses API-Level ausgerichtet ist.

Diese Listen sind mit dem maximalen API-Level (max-target-x) gekennzeichnet, das eine App als Ziel verwenden kann, bevor sie nicht mehr auf die Nicht-SDK-Schnittstellen in der Liste zugreifen kann. Ein Beispiel: Eine Nicht-SDK-Schnittstelle, die in Android 9 nicht blockiert wurde, aber jetzt in Android 10 blockiert wird, ist Teil der Liste max-target-p (greylist-max-p), wobei „p“ für Pie oder Android 9 (API-Level 28) steht.

Wenn Ihre App versucht, auf eine Schnittstelle zuzugreifen, die für Ihr Ziel-API-Level eingeschränkt ist, verhält sich das System so, als ob die API Teil der Blockierliste ist.
Nicht unterstützt
  • unsupported
  • Eingestellt: greylist
 Nicht-SDK-Schnittstellen, die uneingeschränkt verwendet werden können. Beachten Sie jedoch, dass diese Schnittstellen nicht unterstützt werden und ohne Vorankündigung geändert werden können. Es ist zu erwarten, dass diese Schnittstellen in zukünftigen Android-Versionen in einer max-target-x-Liste bedingt blockiert werden.
SDK
  • Sowohl public-api als auch sdk
  • Eingestellt: Sowohl public-api als auch whitelist
 Schnittstellen, die frei verwendet werden können und jetzt als Teil 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 SDK. Ab Android 11 (API-Level 30) sind Test-APIs in der Blockierliste enthalten. Apps dürfen sie also unabhängig von ihrem Ziel-API-Level nicht verwenden. Alle Test-APIs werden nicht unterstützt und können ohne Vorankündigung geändert werden, unabhängig vom API-Level der Plattform.

Sie können zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), aber die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt 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 für eine Funktion in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle finden, sollten Sie eine neue öffentliche API anfordern.

Ermitteln, zu welcher Liste eine Schnittstelle gehört

Die Listen der Nicht-SDK-Schnittstellen werden als Teil der Plattform erstellt. Informationen zu den einzelnen Android-Releases finden Sie in den folgenden Abschnitten.

Android 16

Für Android 16 (API-Level 36) 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: 9102af02fe6ab68b92464bdff5e5b09f3bd62c65d1130aaf85d3296f17d38074

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 16 finden Sie unter Updates to non-SDK interface restrictions in Android 16.

Android 15

Für Android 15 (API-Level 35) 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: 40134e205e58922a708c453726b279a296e6a1f34a988abd90cec0f3432ea5a9

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 15 finden Sie unter Updates to non-SDK interface restrictions in Android 15.

Android 14

Für Android 14 (API-Level 34) 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: 7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 14 finden Sie unter Updates to non-SDK interface restrictions 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-APIs in Android 13, einschließlich vorgeschlagener öffentlicher API-Alternativen für APIs, die in Android 13 bedingt blockiert werden, finden Sie hier.

Android 12

Für Android 12 (API-Level 31) 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: 40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761

Weitere Informationen zu den Änderungen der Liste der Nicht-SDK-APIs in Android 12, einschließlich vorgeschlagener öffentlicher API-Alternativen für APIs, die in Android 12 bedingt blockiert werden, finden Sie unter List changes for Android 12 (Änderungen der Liste 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-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 APIs, die nicht zum SDK gehören, in Android 11, einschließlich der vorgeschlagenen öffentlichen API-Alternativen für APIs, die in Android 11 bedingt blockiert werden, finden Sie unter List changes for Android 11.

Android 10

Für Android 10 (API-Level 29) 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: f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb

Weitere Informationen zu den Änderungen der Liste der APIs, die nicht zum SDK gehören, in Android 10, einschließlich der vorgeschlagenen öffentlichen API-Alternativen für APIs, die in Android 10 bedingt blockiert sind, finden Sie hier.

Android 9

Für Android 9 (API-Level 28) enthält die folgende Textdatei die Liste der nicht eingeschränkten (graugelisteten) Nicht-SDK-APIs: hiddenapi-light-greylist.txt.

Die Sperrliste (blacklist) und die Liste der bedingt blockierten APIs (dunkelgraue Liste) werden zur Build-Zeit 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 den AOSP-Quellcode herunter und führen Sie dann den folgenden Befehl aus:

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

Sie finden die Datei dann an folgendem Speicherort:

out/soong/hiddenapi/hiddenapi-flags.csv

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

In der folgenden Tabelle wird das Verhalten beschrieben, das Sie erwarten können, wenn Ihre App versucht, auf eine Nicht-SDK-Schnittstelle zuzugreifen, die Teil der Blockierliste ist.

Zugriffsmöglichkeiten Ergebnis
Dalvik-Befehl, der auf ein Feld verweist NoSuchFieldError ausgelöst
Dalvik-Befehl, der 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 nicht in den Ergebnissen
Reflexion mit Class.getDeclaredMethods(), Class.getMethods() Nicht-SDK-Mitglieder nicht in den Ergebnissen
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 debug-fähigen App testen

Sie können nicht zum SDK gehörende Schnittstellen testen, indem Sie eine debugfähige 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 Emulator dem Ziel-API-Level Ihrer App entspricht.

Wenn das System Tests für Ihre App ausführt, wird eine Log-Meldung ausgegeben, wenn Ihre App auf bestimmte Nicht-SDK-Schnittstellen zugreift. Sie können die Logmeldungen Ihrer App prüfen, um die folgenden Details zu finden:

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

Sie können mit adb logcat auf diese Logmeldungen zugreifen, die unter der PID der laufenden App angezeigt werden. Ein Eintrag im Log 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 für jede Verwendung einer Nicht-SDK-Schnittstelle einen Callback mit penaltyListener erhalten, in dem Sie eine benutzerdefinierte Verarbeitung implementieren können. Das im Callback bereitgestellte Violation-Objekt wird von Throwable abgeleitet und der beigefügte Stacktrace enthält den Kontext der Verwendung.

Mit dem Veridex-Tool testen

Sie können das Tool zur statischen Analyse „veridex“ auch für Ihr APK ausführen. Das Veridex-Tool scannt den gesamten Code des APK, einschließlich aller Drittanbieterbibliotheken, und meldet alle gefundenen Verwendungen von Nicht-SDK-Schnittstellen.

Das Veridex-Tool hat unter anderem die folgenden Einschränkungen:

  • Aufrufe über JNI können nicht erkannt werden.
  • Es kann nur eine Teilmenge der Aufrufe durch Reflexion erkennen.
  • Die Analyse für inaktive Codepfade beschränkt sich auf API-Level-Prüfungen.
  • Sie kann nur auf Computern ausgeführt werden, die SSE4.2- und POPCNT-Befehle unterstützen.

Windows

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

Starten Sie nach der Installation von Ubuntu ein Ubuntu-Terminal und führen Sie die folgenden Schritte aus:

  1. Laden Sie das Veridex-Tool aus dem Repository für Android-Laufzeit-Prebuilts 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. Wechseln Sie zum entpackten Ordner und führen Sie den folgenden Befehl aus. Dabei ist your-app.apk das APK, das 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 Android-Laufzeit-Prebuilts 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 entzippten Ordner auf und führen Sie dann den folgenden Befehl aus. Dabei ist /path-from-root/your-app.apk der Pfad zur APK, die Sie testen möchten, beginnend mit dem 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 Android-Laufzeit-Prebuilts 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. Wechseln Sie zum entpackten Ordner und führen Sie den folgenden Befehl aus. Dabei ist your-app.apk das APK, das 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 vom Lint-Tool auf potenzielle Probleme untersucht. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, werden je nachdem, zu welcher Liste diese Schnittstellen gehören, möglicherweise Build-Fehler 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 getestet 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 „Android-Kompatibilität“ unter Pre-Launch-Berichte zum Erkennen von Problemen verwenden.

Neue öffentliche API anfordern

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

Geben Sie bei der Erstellung einer Funktionsanfrage die folgenden Informationen an:

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

Wenn Sie diese Details in Ihrem Funktionsantrag angeben, erhöhen Sie die Wahrscheinlichkeit, dass eine neue öffentliche API genehmigt wird.

Andere Fragen

In diesem Abschnitt finden Sie Antworten auf einige weitere Fragen, die Entwickler häufig gestellt haben:

Allgemeine Fragen

Wie kann Google sicher sein, dass die Bedürfnisse aller Apps über den Issue Tracker erfasst werden können?

Die ursprünglichen Listen für Android 9 (API-Level 28) wurden durch statische Analysen von Apps erstellt, die durch die folgenden Methoden ergänzt wurden:

  • Manuelle Tests von Top-Apps aus dem Play Store und anderen Apps
  • interne Berichte
  • automatische Datenerhebung von internen Nutzern
  • Berichte zur Entwicklervorschau
  • zusätzliche statische Analysen, die so konzipiert wurden, dass sie konservativ mehr Falsch-Positiv-Ergebnisse enthalten

Bei der Überprüfung der Listen für jede neue Version berücksichtigen wir die API-Nutzung sowie das Entwickler-Feedback ü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 die API-Durchsetzungsrichtlinie mit adb-Befehlen ändern. Die verwendeten Befehle variieren je nach API-Level. Für diese Befehle ist kein gerootetes Gerät erforderlich.

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

So aktivieren Sie den Zugriff:

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 den Ganzzahlwert in der API-Durchsetzungsrichtlinie auf einen der folgenden Werte festlegen:

  • 0: Die Erkennung von Nicht-SDK-Schnittstellen wird deaktiviert. Wenn Sie diese Einstellung verwenden, werden alle Logmeldungen für die Verwendung von Nicht-SDK-Schnittstellen deaktiviert und Sie können Ihre App nicht mit der StrictMode API testen. Diese Einstellung wird nicht empfohlen.
  • 1: Zugriff auf alle Nicht-SDK-Schnittstellen aktivieren, aber Logmeldungen mit Warnungen für jede Verwendung einer Nicht-SDK-Schnittstelle ausgeben. Mit dieser Einstellung können Sie Ihre App auch mit der StrictMode API testen.
  • 2. Verwendung von Nicht-SDK-Schnittstellen, die zur Sperrliste gehören oder für Ihre Ziel-API-Ebene bedingt gesperrt sind, nicht zulassen.

Fragen zu Listen von Nicht-SDK-Schnittstellen

Wo finde ich die Listen der APIs, die nicht zum SDK gehören, im System-Image?

Sie sind in den Zugriffs-Flag-Bits für Felder und Methoden in DEX-Dateien der Plattform codiert. Es gibt keine separate Datei im Systemimage, die diese Listen enthält.

Sind die API-Listen ohne SDK auf verschiedenen OEM-Geräten mit derselben Android-Version identisch?

OEMs können der Blocklist (Blacklist) eigene Schnittstellen hinzufügen, aber keine Schnittstellen aus den AOSP-Listen für Nicht-SDK-APIs entfernen. Das CDD verhindert solche Änderungen und CTS-Tests sorgen dafür, dass die Android-Laufzeit die Liste erzwingt.

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

Das Android SDK enthält Java-Schnittstellen. Die Plattform begann mit Android 7 (API-Level 26), den Zugriff auf Nicht-NDK-Schnittstellen für nativen C/C++-Code einzuschränken. Weitere Informationen finden Sie unter Improving Stability with Private C/C++ Symbol Restrictions in Android N.

Gibt es Pläne, die Manipulation von dex2oat oder DEX-Dateien einzuschränken?

Wir haben derzeit keine aktiven Pläne, den Zugriff auf die dex2oat-Binärdatei einzuschränken. Das DEX-Dateiformat soll jedoch nicht stabil sein und keine öffentliche Schnittstelle über die Teile hinaus darstellen, die öffentlich im Dalvik Executable-Format angegeben sind. Wir behalten uns das Recht vor, dex2oat und die nicht näher spezifizierten Teile des DEX-Formats jederzeit zu ändern oder zu entfernen. Beachten Sie außerdem, dass abgeleitete Dateien, die von dex2oat erstellt werden, z. B. ODEX (auch bekannt als OAT), VDEX und CDEX, alle nicht spezifizierte Formate sind.

Was ist, wenn ein wichtiges Drittanbieter-SDK (z. B. ein Obfuskator) nicht vermeiden kann, dass Nicht-SDK-Schnittstellen verwendet werden, aber die Kompatibilität mit zukünftigen Android-Versionen gewährleistet? Kann Android in diesem Fall auf die Kompatibilitätsanforderungen verzichten?

Wir haben nicht vor, Kompatibilitätsanforderungen pro SDK aufzuheben. Wenn ein SDK-Entwickler die Kompatibilität nur aufrechterhalten kann, indem er sich auf Schnittstellen in den nicht unterstützten (früher grauen) Listen verlässt, sollte er eine Migration zu SDK-Schnittstellen oder anderen Alternativen planen und eine neue öffentliche API anfordern, wenn er keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle findet.

Gelten Einschränkungen für Nicht-SDK-Schnittstellen für alle Apps, einschließlich System-Apps und von Google entwickelten Apps, und nicht nur für Drittanbieter-Apps?

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