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 immer dann, wenn eine Anwendung auf eine Nicht-SDK-Schnittstelle verweist oder versucht, ihren Handle mithilfe von Reflexion oder JNI abzurufen. Diese Einschränkungen wurden festgelegt, um die Nutzer- und Entwicklererfahrung zu verbessern und das Risiko von Abstürzen für Nutzer und Notfall-Rollouts für Entwickler zu reduzieren. Weitere Informationen zu dieser Entscheidung finden Sie unter Verbessern der Stabilität 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 bei der API nicht berücksichtigt 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 nicht auf Methoden oder Felder zugreifen sollten, die nicht im SDK aufgeführt sind, wenn Sie mit einer Klasse interagieren, die Mechanismen wie Reflexion nutzt.

Nicht-SDK-API-Listen

Bei jedem Android-Release sind zusätzliche Nicht-SDK-Schnittstellen eingeschränkt. Wir wissen, dass sich diese Einschränkungen auf deinen Release-Workflow auswirken können. Deshalb möchten wir dir die Möglichkeit geben, uns Feedback zu geben und dir die Zeit für Planung und Anpassung an die neuen Richtlinien zu geben. Deshalb möchten wir dir die nötigen Tools bieten, um die Verwendung von Nicht-SDK-Schnittstellen zu erkennen.

Um die Auswirkungen solcher Einschränkungen auf Ihren Entwicklungsworkflow zu minimieren, sind die Nicht-SDK-Schnittstellen in Listen unterteilt, die festlegen, wie streng ihre Verwendung eingeschränkt wird, je nachdem, auf welche API-Ebene sie ausgerichtet werden. 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 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) gibt es für jede API-Ebene Nicht-SDK-Schnittstellen, die eingeschränkt sind, wenn eine App auf dieses API-Level ausgerichtet ist.

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

Wenn Ihre Anwendung versucht, auf eine Schnittstelle zuzugreifen, die für Ihr Ziel-API-Level eingeschränkt ist, funktioniert das System so, als wäre die API Teil der Sperrliste.
Nicht unterstützt
  • unsupported
  • Eingestellt: greylist
 Nicht-SDK-Schnittstellen, die uneingeschränkt sind und von Ihrer App verwendet werden können. Diese Schnittstellen werden jedoch 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 nutzbare 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) vereinfachen Test-APIs sind nicht Teil des SDK. Ab Android 11 (API-Level 30) sind Test-APIs in der Sperrliste enthalten, sodass Apps sie unabhängig von ihrem Ziel-API-Level nicht mehr verwenden dürfen. 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 (je nach Ziel-API-Ebene Ihrer App), jede andere Methode oder ein anderes Feld birgt jedoch immer das Risiko, dass Ihre App nicht mehr funktioniert. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, 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.

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-Releases.

Android 15 (Beta)

Für Android 15 kannst du die folgende Datei herunterladen, in der alle Nicht-SDK-Schnittstellen und die entsprechenden Listen beschrieben sind:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 7aa0987aea4b25f5371b7e377c9f37375ada3b7e30465c0e2d910a5b646c10c1

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

Android 14

Für Android 14 (API-Level 34) kannst du die folgende Datei herunterladen, in der alle Nicht-SDK-Schnittstellen und die entsprechenden Listen beschrieben sind:

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 Aktualisierungen der Einschränkungen für Nicht-SDK-APIs in Android 14.

Android 13

Für Android 13 (API-Level 33) kannst du die folgende Datei herunterladen, in der alle Nicht-SDK-Schnittstellen und die entsprechenden Listen beschrieben sind:

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 sind, finden Sie unter Aktualisierungen der Einschränkungen für Nicht-SDK-Schnittstellen in Android 13.

Android 12

Für Android 12 (API-Level 31) kannst du die folgende Datei herunterladen, in der alle Nicht-SDK-Schnittstellen und die entsprechenden Listen beschrieben sind:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: 40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761

Weitere Informationen zu den Listenänderungen bei Nicht-SDK-APIs in Android 12, einschließlich empfohlener öffentlicher API-Alternativen für APIs, die in Android 12 bedingt blockiert sind, finden Sie unter Änderungen für Android 12 auflisten.

Android 11

Für Android 11 (API-Level 30) kannst du die folgende Datei herunterladen. Darin sind alle Nicht-SDK-Schnittstellen und die entsprechenden Listen beschrieben:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56

Weitere Informationen zu den Listenänderungen für Nicht-SDK-APIs in Android 11, einschließlich vorgeschlagener öffentlicher API-Alternativen für APIs, die in Android 11 bedingt blockiert sind, 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 entsprechenden Listen beschrieben sind:

Datei: hiddenapi-flags.csv

SHA-256-Prüfsumme: f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb

Weitere Informationen zu den Listenänderungen bei 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 Ä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 (Grauliste): hiddenapi-light-greylist.txt.

Die Sperrliste (blacklist) und die Liste der bedingt blockierten APIs (dunkelgraue Liste) werden zum Zeitpunkt der Build-Erstellung abgeleitet.

Listen aus AOSP generieren

Bei der Arbeit mit AOSP 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 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(), Class.getMethod() NoSuchMethodException geworfen
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 geworfen
JNI mit env->GetMethodID() NULL zurückgegeben, NoSuchMethodError geworfen

App auf Nicht-SDK-Schnittstellen testen

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

Mit einer debug-fähigen App testen

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

Während der Tests für Ihre App gibt das System eine Lognachricht aus, wenn Ihre App auf bestimmte Nicht-SDK-Schnittstellen zugreift. In den Logeinträgen Ihrer Anwendung finden Sie die folgenden Details:

  • Die Deklarationsklasse, der Name und der Typ (in dem von der Android-Laufzeit verwendeten Format).
  • Die Mittel für den Zugriff: entweder Verknüpfung, Reflexion oder JNI.
  • Zu welcher Liste die Nicht-SDK-Schnittstelle gehört.

Sie können mit adb logcat auf diese Logeinträge zugreifen, die unter der PID der laufenden Anwendung angezeigt werden. Ein Eintrag im Log könnte beispielsweise so lauten:

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

Mit der StrictMode API testen

Sie können auch Nicht-SDK-Schnittstellen mithilfe der StrictMode API testen. Verwenden Sie die Methode detectNonSdkApiUsage, um diese Option zu aktivieren. Nachdem Sie die StrictMode API aktiviert haben, können Sie für jede Nutzung einer Nicht-SDK-Schnittstelle einen Callback erhalten. Verwenden Sie dazu penaltyListener, um eine benutzerdefinierte Verarbeitung zu implementieren. Das im Callback bereitgestellte Violation-Objekt stammt von Throwable und der eingeschlossene Stacktrace liefert den Kontext der Nutzung.

Mit dem Veridex-Tool testen

Sie können das statische Analysetool von Veridex auch in Ihrem APK ausführen. Das Veridex-Tool scannt die gesamte Codebasis des APKs, einschließlich aller Bibliotheken von Drittanbietern, und meldet alle Verwendungen 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 nur einen Teil der Aufrufe durch Reflexion erkennen.
  • Seine Analyse auf inaktive 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ärprogramme werden nicht bereitgestellt, aber Sie können das Veridex-Tool 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.

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

  1. Laden Sie das Veridex-Tool aus dem vordefinierten Android-Laufzeit-Repository herunter.
  2. Extrahieren Sie den Inhalt der Datei appcompat.tar.gz.
  3. Suchen Sie im extrahierten Ordner die Datei veridex-linux.zip und entpacken 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 Android-Laufzeit-Repository herunter.
  2. Extrahieren Sie den Inhalt der Datei appcompat.tar.gz.
  3. Suchen Sie im extrahierten Ordner die Datei veridex-mac.zip und entpacken 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 Android-Laufzeit-Repository herunter.
  2. Extrahieren Sie den Inhalt der Datei appcompat.tar.gz.
  3. Suchen Sie im extrahierten Ordner die Datei veridex-linux.zip und entpacken 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 von Android Studio testen

Wenn Sie Ihre App in Android Studio erstellen, prüft das Lint-Tool Ihren Code auf mögliche Probleme. Wenn Ihre Anwendung Nicht-SDK-Schnittstellen verwendet, können je nach Liste der Schnittstellen Build-Fehler oder ‐Warnungen angezeigt werden.

Sie können das Lint-Tool auch über die Befehlszeile ausführen oder Inspektionen 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 der Play Console hochladen, wird sie automatisch auf mögliche Probleme getestet und ein Pre-Launch-Bericht wird erstellt. Wenn Ihre 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 Pre-Launch-Berichte zum Erkennen von Problemen verwenden.

Neue öffentliche API anfordern

Wenn Sie in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle für eine Funktion finden, können Sie eine neue öffentliche API anfordern, indem Sie in unserer Problemverfolgung 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 Deskriptors, der in der Logcat-Nachricht Accessing hidden ... zu sehen ist.
  • Warum Sie diese APIs verwenden müssen, einschließlich Details zu den übergeordneten Funktionen, für die die API erforderlich ist, und nicht nur zu den Details auf niedriger Ebene.
  • Warum bestimmte öffentliche SDK-APIs für Ihre Zwecke nicht ausreichen.
  • Welche anderen Alternativen, die Sie ausprobiert haben, 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

Dieser Abschnitt enthält einige Antworten auf andere Fragen, die Entwickler häufig gestellt haben:

Allgemeine Fragen

Wie kann Google mithilfe der Problemverfolgung sicherstellen, dass die Anforderungen aller Apps erfüllt werden?

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

  • Manuelles Testen von Top-Apps bei Google Play und anderen Anbietern
  • Interne Berichte
  • automatische Datenerhebung durch interne Nutzer
  • Entwicklervorschauberichte
  • Eine zusätzliche statische Analyse, die konservativ mehr falsch positive Ergebnisse liefert,

Bei der Auswertung der Listen für jede neue Version berücksichtigen wir die API-Nutzung sowie das Feedback von Entwicklern ü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 ADB-Befehle verwenden, um die API-Erzwingungsrichtlinie zu ändern. Welche Befehle Sie verwenden, hängt vom API-Level 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 Richtlinie für die API-Erzwingung 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 Richtlinie für die API-Erzwingung 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 Richtlinie zur API-Erzwingung auf einen der folgenden Werte festlegen:

  • 0: Deaktiviert die Erkennung von Nicht-SDK-Schnittstellen. Mit dieser Einstellung werden alle Logeinträge für die Nutzung ohne SDK-Schnittstelle deaktiviert und Sie können die Anwendung 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 die Nutzung von Nicht-SDK-Schnittstellen ausgeben. Mit dieser Einstellung können Sie Ihre App auch mit der StrictMode API testen.
  • 2: Die Verwendung von Nicht-SDK-Schnittstellen nicht zulassen, die zur Sperrliste gehören oder für Ihr Ziel-API-Level bedingt blockiert sind.

Fragen zu Nicht-SDK-Schnittstellenlisten

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

Sie sind in den Bits für Feld- und Methodenzugriffs-Flags in Plattform-DEX-Dateien codiert. Das System-Image enthält 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 ihre eigenen Schnittstellen zur Sperrliste (Sperrliste) hinzufügen, aber sie können keine Schnittstellen aus den AOSP-Nicht-SDK-API-Listen entfernen. Das CDD verhindert solche Änderungen und CTS-Tests sorgen dafür, dass die Liste von der Android Runtime erzwingt wird.

Gibt es Einschränkungen für Nicht-NDK-Schnittstellen im nativen Code?

Das Android SDK umfasst Java-Schnittstellen. Die Plattform begann damit, 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 Verbessern der Stabilität mit privaten C-/C++-Symboleinschränkungen in Android N.

Gibt es Pläne, die dex2oat- oder DEX-Dateimanipulation einzuschränken?

Wir haben keine Pläne, den Zugriff auf das DEX-Binärprogramm zu beschränken. Das DEX-Dateiformat soll aber nicht über die öffentlich im Dalvik Executable-Format angegebenen Teile hinaus stabil sein oder eine öffentliche Schnittstelle bieten. Wir behalten uns das Recht vor, Dex2oat und die nicht angegebenen Teile des DEX-Formats jederzeit zu ändern oder zu entfernen. Beachten Sie auch, dass von Dex2oat erstellte abgeleitete Dateien wie ODEX (auch OAT), VDEX und CDEX nicht angegebene Formate sind.

Was passiert, wenn ein wichtiges Drittanbieter-SDK (z. B. ein Obfuscator) die Verwendung von Nicht-SDK-Schnittstellen nicht vermeiden kann, sich aber verpflichtet, die Kompatibilität mit zukünftigen Android-Versionen aufrechtzuerhalten? Kann Android in diesem Fall auf die Kompatibilitätsanforderungen verzichten?

Es ist nicht geplant, auf die Kompatibilitätsanforderungen pro SDK zu verzichten. Wenn ein SDK-Entwickler nur durch die Schnittstellen in den nicht unterstützten (früher grauen) Listen die Kompatibilität 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 Benutzeroberfläche ohne SDK finden kann.

Gelten Einschränkungen für die Nicht-SDK-Schnittstelle für alle Apps, einschließlich System- und Erstanbieter-Apps, und nicht nur Drittanbieter-Apps?

Ja. Mit dem Plattformschlüssel signierte Apps sowie einige System-Image-Apps sind jedoch ausgenommen. Diese Ausnahmen gelten nur für Anwendungen, die Teil des System-Images sind (oder aktualisierte System-Image-Apps). Die Liste ist nur für Apps vorgesehen, die mit den APIs der privaten Plattform und nicht mit den SDK APIs (wobei LOCAL_PRIVATE_PLATFORM_APIS := true) erstellt werden.