Einschränkungen für Nicht-SDK-Schnittstellen

Ab Android 9 (API-Level 28) schränkt die Plattform ein, welche Nicht-SDK-Schnittstellen deine App verwenden kann. Diese Einschränkungen gelten, wenn eine App auf eine Nicht-SDK-Schnittstelle verweist oder versucht, ihren Alias mithilfe von Reflexion oder JNI abzurufen. Diese Einschränkungen wurden eingeführt, um die Nutzer- und Entwicklererfahrung zu verbessern und das Risiko von Abstürzen für Nutzer und Notfall-Rollouts 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 Package Index 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 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 Reflexion interagieren.

Listen der Nicht-SDK-APIs

Mit jeder Version von Android sind zusätzliche Nicht-SDK-Schnittstellen eingeschränkt. Uns ist bewusst, dass sich diese Einschränkungen auf Ihren Release-Workflow auswirken können. Deshalb möchten wir Ihnen die Tools an die Hand geben, mit denen Sie die Nutzung von Nicht-SDK-Schnittstellen erkennen können. Außerdem haben Sie die Möglichkeit, uns Feedback zu geben, und haben genügend Zeit, die neuen Richtlinien zu planen und sich daran anzupassen.

Um die Auswirkungen von Nicht-SDK-Einschränkungen auf Ihren Entwicklungsworkflow zu minimieren, werden die Nicht-SDK-Schnittstellen in Listen unterteilt. Diese definieren, wie eng ihre Verwendung eingeschränkt ist, je nachdem, auf welche API-Ebene dies angewandt wird. In der folgenden Tabelle werden diese 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 die Anwendung 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) hat jedes API-Level Nicht-SDK-Schnittstellen, die eingeschränkt sind, wenn eine App auf dieses API-Level ausgerichtet ist. Diese Listen werden durch das maximale API-Level (max-target-x) gekennzeichnet, auf das eine App ausgerichtet sein kann, bevor sie nicht mehr auf die Nicht-SDK-Schnittstellen in dieser Liste zugreifen kann. Beispielsweise ist eine Nicht-SDK-Schnittstelle, die in Android Pie nicht blockiert war, aber jetzt in Android 10 blockiert wurde, Teil der Liste max-target-p (greylist-max-p), wobei „p“ für Pie oder Android 9 (API-Level 28) steht. Wenn deine Anwendung versucht, auf eine Schnittstelle zuzugreifen, die für dein Ziel-API-Level eingeschränkt ist, verhält sich das System so, als wäre die API Teil der Sperrliste.
Nicht unterstützt	unsupported Eingestellt: greylist	Nicht-SDK-Schnittstellen, die nicht eingeschränkt sind und von Ihrer App verwendet werden können. Hinweis: Diese Schnittstellen werden nicht unterstützt und können ohne Vorankündigung geändert werden. Diese Schnittstellen werden in zukünftigen Android-Versionen in einer max-target-x-Liste bedingt blockiert.
SDK	public-api und sdk Eingestellt: public-api und whitelist	Frei verwendbare Schnittstellen, die 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 SDK. Ab Android 11 (API-Level 30) sind Test-APIs in der Sperrliste 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 vorherige Ankü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 bei Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds besteht immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie mit der Migration zu SDK-Schnittstellen oder anderen Alternativen beginnen. Wenn Sie für ein Feature in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle finden, sollten Sie eine neue öffentliche API anfordern.

Bestimmen, zu welcher Liste eine Schnittstelle gehört

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

Android 15

Für Android 15 (API-Level 35) können Sie die folgende Datei herunterladen. Darin sind alle Nicht-SDK-Schnittstellen und die zugehörigen Listen beschrieben:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 40134e205e58922a708c453726b279a296e6a1f34a988abd90cec0f3432ea5a9

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 15 findest du unter Updates für Einschränkungen von Nicht-SDK-APIs in Android 15.

Android 14

Für Android 14 (API-Level 34) können Sie die folgende Datei herunterladen. Darin sind alle Nicht-SDK-Schnittstellen und die zugehörigen Listen beschrieben:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 14 findest du unter Updates für Einschränkungen von Nicht-SDK-APIs in Android 14.

Android 13

Für Android 13 (API-Level 33) können Sie die folgende Datei herunterladen. Darin sind alle Nicht-SDK-Schnittstellen und die zugehörigen Listen beschrieben:

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 der vorgeschlagenen öffentlichen API-Alternativen für APIs, die in Android 13 bedingt blockiert werden, finden Sie unter Änderungen an den Einschränkungen für Nicht-SDK-Schnittstellen in Android 13.

Android 12

Für Android 12 (API-Level 31) können Sie die folgende Datei herunterladen. Darin sind alle Nicht-SDK-Schnittstellen und die zugehörigen Listen beschrieben:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 12, einschließlich der vorgeschlagenen öffentlichen API-Alternativen für APIs, die in Android 12 bedingt blockiert werden, finden Sie unter Änderungen für Android 12 auflisten.

Android 11

Für Android 11 (API-Level 30) kannst du die folgende Datei herunterladen, in der alle Nicht-SDK-Schnittstellen und die zugehörigen Listen beschrieben werden:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56

Weitere Informationen zu den Änderungen an der Liste der Nicht-SDK-APIs in Android 11, einschließlich der vorgeschlagenen öffentlichen API-Alternativen für APIs, die in Android 11 bedingt blockiert werden, finden Sie unter Änderungen für Android 11 auflisten.

Android 10

Für Android 10 (API-Level 29) kannst du die folgende Datei herunterladen, in der alle Nicht-SDK-Schnittstellen und die zugehörigen 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 der vorgeschlagenen öffentlichen API-Alternativen für APIs, die in Android 10 bedingt blockiert werden, finden Sie unter Änderungen für Android 10 auflisten.

Android 9

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

Die Sperrliste (blacklist) und die Liste der bedingt blockierten APIs (dunkelgraue Liste) werden zum Zeitpunkt der Erstellung 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 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 Sperrliste ist.

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

Apps auf Nicht-SDK-Schnittstellen testen

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

Mit einer debugfähigen App testen

Sie können auf Nicht-SDK-Schnittstellen testen, indem Sie eine Debug-fä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 verwendete Gerät oder der Emulator mit dem Ziel-API-Level Ihrer App übereinstimmt.

Während der Tests in Ihrer Anwendung gibt das System eine Lognachricht aus, wenn Ihre Anwendung auf bestimmte Nicht-SDK-Schnittstellen zugreift. Sie können die Lognachrichten Ihrer Anwendung prüfen, um die folgenden Details zu finden:

• Die deklarierende Klasse, der Name und der Typ (in dem Format, das von der Android-Laufzeit verwendet wird)
• Die Mittel des Zugriffs: entweder Verlinkung, Reflexion oder JNI.
• Liste der Nicht-SDK-Schnittstellen

Mit adb logcat können Sie auf diese Logmeldungen zugreifen, die unter der PID der ausgeführten Anwendung 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

Mit der StrictMode API können Sie auch Nicht-SDK-Schnittstellen testen. Verwenden Sie die Methode detectNonSdkApiUsage, um diese Funktion zu aktivieren. Nachdem Sie die StrictMode API aktiviert haben, können Sie bei jeder Verwendung einer Nicht-SDK-Schnittstelle einen Callback erhalten. Dazu verwenden Sie ein penaltyListener, mit dem Sie eine benutzerdefinierte Verarbeitung implementieren können. Das im Callback bereitgestellte Violation-Objekt stammt von Throwable. Der eingeschlossene Stacktrace liefert den Kontext der Nutzung.

Mit dem Veridex-Tool testen

Sie können auch das statische Analysetool von veridex auf Ihrem APK ausführen. Das veridex-Tool scannt die gesamte Codebasis des APK, einschließlich aller Bibliotheken von Drittanbietern, und meldet jegliche Verwendung von Nicht-SDK-Schnittstellen, die es findet.

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

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

Windows

Native Windows-Binärdateien werden nicht bereitgestellt. Sie können das veridex-Tool aber unter Windows ausführen. Dazu führen Sie die Linux-Binärdateien mithilfe des Windows-Subsystems für Linux (WSL) aus. Bevor Sie die Schritte in diesem Abschnitt ausführen, installieren Sie den WSL und wählen Ubuntu als Linux-Distribution aus.

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

1. Laden Sie das Veridex-Tool aus dem vordefinierten Repository für die Android-Laufzeit herunter.
2. Extrahieren Sie den Inhalt der appcompat.tar.gz-Datei.
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, wobei your-app.apk das APK ist, 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 vordefinierten Repository für die Android-Laufzeit herunter.
2. Extrahieren Sie den Inhalt der appcompat.tar.gz-Datei.
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, wobei /path-from-root/your-app.apk der Pfad zu dem APK ist, das Sie testen möchten, beginnend im 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 vordefinierten Repository für die Android-Laufzeit herunter.
2. Extrahieren Sie den Inhalt der appcompat.tar.gz-Datei.
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, wobei your-app.apk das APK ist, das Sie testen möchten:

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

Mit dem Lint-Tool in Android Studio testen

Immer wenn Sie Ihre App in Android Studio erstellen, prüft das Lint-Tool den Code auf mögliche Probleme. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, werden möglicherweise Build-Fehler oder ‐Warnungen angezeigt, je nachdem, zu welcher Liste diese Schnittstellen gehören.

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

Mit der Play Console testen

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

Weitere Informationen findest du im Abschnitt zur Android-Kompatibilität unter Probleme mit Pre-Launch-Berichten erkennen.

Neue öffentliche API anfordern

Wenn Sie für ein Feature in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle finden, können Sie eine neue öffentliche API anfordern. Erstellen Sie dazu eine Funktionsanfrage in unserer Problemverfolgung.

Geben Sie beim Erstellen einer Funktionsanfrage die folgenden Informationen an:

• Die nicht unterstützte API, die Sie verwenden, einschließlich des vollständigen Deskriptors aus der Logcat-Nachricht Accessing hidden ....
• Warum Sie diese APIs verwenden müssen, einschließlich Details zu dem übergeordneten Feature, für das die API erforderlich ist, und nicht nur auf Low-Level-Details.
• Warum zugehörige öffentliche SDK APIs für deine Zwecke nicht ausreichen.
• Haben Sie andere Alternativen ausprobiert und warum diese nicht funktioniert haben?

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

Sonstige Fragen

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

Allgemeine Fragen

Wie kann Google sicherstellen, dass die Anforderungen aller Apps über den Issue Tracker erfasst werden?

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

• Manuelle Tests von Top-Apps bei Google Play und anderen Apps
• interne Berichte
• Automatische Datenerfassung von internen Nutzern
• Entwicklervorschauberichte
• zusätzliche statische Analyse, die konservativ mehr falsch-positive Ergebnisse einbeziehen soll.

Bei der Auswertung der Listen für jeden neuen Release berücksichtigen wir die API-Nutzung sowie Entwicklerfeedback über die Problemverfolgung.

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-Erzwingungsrichtlinie mit ADB-Befehlen ändern. Welche Befehle Sie verwenden, hängt von der API-Ebene ab. Für diese Befehle ist kein Root-Gerät erforderlich.

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

Verwenden Sie das folgende ADB, um den Zugriff zu aktivieren

command:

adb shell settings put global hidden_api_policy  1

Verwenden Sie den folgenden Befehl, um die API-Erzwingungsrichtlinie 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-Erzwingungsrichtlinie 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-Erzwingungsrichtlinie auf einen der folgenden Werte festlegen:

• 0: Erkennung von Nicht-SDK-Schnittstellen vollständig deaktivieren. Wenn Sie diese Einstellung verwenden, werden alle Logeinträge für die Nutzung 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 Lognachrichten mit Warnungen für die Verwendung von Nicht-SDK-Schnittstellen ausgeben. Mit dieser Einstellung kannst du deine Anwendung auch mit der StrictMode API testen.
• 2: Verwenden Sie keine Nicht-SDK-Schnittstellen, die auf der Sperrliste stehen oder bedingt für Ihr Ziel-API-Level blockiert sind.

Fragen zu Listen mit Nicht-SDK-Schnittstellen

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

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

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

OEMs können ihre eigenen Schnittstellen zur Sperrliste (schwarze Liste) hinzufügen, aber keine Schnittstellen aus den Listen der AOSP-Nicht-SDK-APIs entfernen. Das CDD verhindert solche Änderungen und CTS-Tests prüfen, ob die Android Runtime die Liste erzwingt.

Fragen zur Kompatibilität ähnlicher Apps

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

Das Android SDK enthält Java-Schnittstellen. Die Plattform begann, den Zugriff auf Nicht-NDK-Schnittstellen für nativen C/C++-Code in Android 7 (API-Level 26) einzuschränken. Weitere Informationen finden Sie unter Stabilität mit privaten C/C++-Symboleinschränkungen in Android N verbessern.

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

Derzeit gibt es keine Pläne, den Zugriff auf das dex2oat-Binärprogramm einzuschränken. Wir beabsichtigen jedoch nicht, dass das DEX-Dateiformat stabil ist oder eine öffentliche Schnittstelle über die öffentlich im Dalvik Executable-Format spezifizierten Abschnitte hinausgeht. Wir behalten uns das Recht vor, dex2oat und die nicht angegebenen Teile des DEX-Formats jederzeit zu ändern oder zu entfernen. Beachten Sie außerdem, dass abgeleitete Dateien, die von dex2oat wie ODEX (auch als OAT bezeichnet), VDEX und CDEX erzeugt werden, nicht spezifizierte Formate sind.

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

Wir planen nicht, auf Kompatibilitätsanforderungen für einzelne SDKs zu verzichten. Wenn ein SDK-Entwickler die Kompatibilität nur aufrechterhalten kann, wenn er auf Schnittstellen in den nicht unterstützten (früher grauen) Listen angewiesen ist, 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-Schnittstellen für alle Apps, einschließlich System- und Erstanbieter-Apps, nicht nur Drittanbieter-Apps?

Ja. Apps, die mit dem Plattformschlüssel signiert sind, und einige System-Image-Apps sind jedoch von dieser Ausnahme ausgenommen. Beachten Sie, dass diese Ausnahmen nur für Anwendungen gelten, die Teil des System-Images sind (oder aktualisierte System-Image-Apps). Die Liste ist nur für Apps vorgesehen, die für die APIs der privaten Plattform und nicht für die SDK APIs (wobei LOCAL_PRIVATE_PLATFORM_APIS := true) erstellt werden.