Verhaltensänderungen: Apps, die auf Android 14 oder höher ausgerichtet sind

Wie in früheren Releases umfasst Android 14 Verhaltensänderungen, die sich auf deine App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind. Wenn Ihre App auf Android 14 oder höher ausgerichtet ist, sollten Sie sie gegebenenfalls so ändern, dass sie diese Verhaltensweisen korrekt unterstützt.

Sieh dir auch die Liste der Verhaltensänderungen an, die alle Apps unter Android 14 betreffen, unabhängig von targetSdkVersion der App.

Hauptfunktion

Typen von Diensten im Vordergrund sind erforderlich

Wenn deine App auf Android 14 (API-Level 34) oder höher ausgerichtet ist, muss mindestens ein Diensttyp im Vordergrund für jeden Dienst im Vordergrund innerhalb deiner App angegeben werden. Du solltest einen Typ auswählen, der den Anwendungsfall deiner App im Vordergrund repräsentiert. Das System erwartet Dienste im Vordergrund eines bestimmten Typs, die einem bestimmten Anwendungsfall entsprechen.

Wenn ein Anwendungsfall in Ihrer Anwendung keinem dieser Typen zugeordnet ist, sollten Sie Ihre Logik auf die Verwendung von WorkManager oder vom Nutzer initiierten Datenübertragungsjobs migrieren.

Erzwingung der Berechtigung BLUETOOTH_CONNECT in BluetoothAdapter

Unter Android 14 wird die Berechtigung BLUETOOTH_CONNECT erzwungen, wenn die Methode BluetoothAdapter getProfileConnectionState() für Apps aufgerufen wird, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind.

Für diese Methode war bereits die Berechtigung BLUETOOTH_CONNECT erforderlich, sie wurde jedoch nicht erzwungen. Deklarieren Sie BLUETOOTH_CONNECT in der Datei AndroidManifest.xml Ihrer App wie im folgenden Snippet gezeigt und prüfen Sie, ob ein Nutzer die Berechtigung erteilt hat, bevor Sie getProfileConnectionState aufrufen.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

OpenJDK 17-Updates

Unter Android 14 werden die Kernbibliotheken von Android fortlaufend aktualisiert, damit sie den Funktionen der neuesten OpenJDK-LTS-Releases entsprechen. Dazu gehören sowohl Bibliotheksupdates als auch die Java 17-Sprachunterstützung für App- und Plattformentwickler.

Einige dieser Änderungen können sich auf die Kompatibilität der App auswirken:

  • Änderungen an regulären Ausdrücken: Ungültige Gruppenverweise dürfen jetzt nicht mehr der Semantik von OpenJDK mehr entsprechen. Es kann vorkommen, dass ein IllegalArgumentException von der Klasse java.util.regex.Matcher ausgegeben wird. Testen Sie Ihre Anwendung daher auf Bereiche, in denen reguläre Ausdrücke verwendet werden. Wenn Sie diese Änderung beim Testen aktivieren oder deaktivieren möchten, aktivieren oder deaktivieren Sie das Flag DISALLOW_INVALID_GROUP_REFERENCE mit den Kompatibilitäts-Framework-Tools.
  • UUID-Verarbeitung: Die Methode java.util.UUID.fromString() führt jetzt bei der Validierung des Eingabearguments strengere Prüfungen durch. Daher wird während der Deserialisierung möglicherweise ein IllegalArgumentException angezeigt. Wenn Sie diese Änderung während des Tests aktivieren oder deaktivieren möchten, aktivieren oder deaktivieren Sie das Flag ENABLE_STRICT_VALIDATION mit den Kompatibilitäts-Framework-Tools.
  • ProGuard-Probleme: In einigen Fällen verursacht das Hinzufügen der Klasse java.lang.ClassValue ein Problem, wenn Sie versuchen, Ihre App mit ProGuard zu verkleinern, zu verschleiern und zu optimieren. Das Problem beruht auf einer Kotlin-Bibliothek, die das Laufzeitverhalten abhängig davon ändert, ob Class.forName("java.lang.ClassValue") eine Klasse zurückgibt oder nicht. Wenn Ihre App für eine ältere Version der Laufzeit ohne verfügbare java.lang.ClassValue-Klasse entwickelt wurde, wird durch diese Optimierungen möglicherweise die Methode computeValue aus Klassen entfernt, die von java.lang.ClassValue abgeleitet sind.

JobScheduler verstärkt Rückruf- und Netzwerkverhalten

Seit der Einführung von JobScheduler wird von Ihrer App erwartet, dass sie innerhalb weniger Sekunden von onStartJob oder onStopJob zurückkehrt. Unter Android 14 wird ein Job, der zu lange läuft, angehalten und kehrt geräuschlos zum Status „Fehlgeschlagen“ zurück. Wenn Ihre App auf Android 14 (API-Level 34) oder höher ausgerichtet ist und die im Hauptthread gewährte Zeit überschreitet, löst die App einen ANR-Fehler aus mit der Fehlermeldung „Keine Antwort auf onStartJob“ oder „Keine Antwort auf onStopJob“.

Dieser ANR kann auf zwei Szenarien zurückzuführen sein: Es gibt eine Aufgabe, die den Haupt-Thread blockiert und verhindert, dass die Rückrufe onStartJob oder onStopJob innerhalb des erwarteten Zeitlimits ausgeführt und abgeschlossen werden. 2. Der Entwickler führt Blockierungsarbeiten in JobScheduler aus Callback onStartJob oder onStopJob, wodurch der Callback verhindert wird die Sie innerhalb der erwarteten Frist abschließen.

Um das Problem mit Nr. 1 zu lösen, müssen Sie weiter untersuchen, was den Hauptthread blockiert. wenn der ANR-Fehler auftritt, können Sie dies mit ApplicationExitInfo#getTraceInputStream(), um den Grabstein zu erhalten wenn der ANR-Fehler auftritt. Wenn Sie den ANR manuell reproduzieren können, können Sie einen System-Trace aufzeichnen und mit Android Studio oder Perfetto untersuchen, was im Haupt-Thread ausgeführt wird, wenn der ANR auftritt. Dies kann passieren, wenn Sie die JobScheduler API direkt oder die androidx-Bibliothek WorkManager verwenden.

Um Problem 2 zu beheben, sollten Sie zu WorkManager migrieren. Dieser Dienst unterstützt das Einbetten von Verarbeitungen in onStartJob oder onStopJob in einen asynchronen Thread.

Mit JobScheduler wird außerdem die Anforderung eingeführt, die Berechtigung ACCESS_NETWORK_STATE anzugeben, wenn die Einschränkung setRequiredNetworkType oder setRequiredNetwork verwendet wird. Wenn Ihre App die Berechtigung ACCESS_NETWORK_STATE beim Planen des Jobs nicht deklariert und auf Android 14 oder höher ausgerichtet ist, führt dies zu einer SecurityException.

Tiles-Einführungs-API

Bei Apps, die auf Android 14 und höher ausgerichtet sind, wird TileService#startActivityAndCollapse(Intent) nicht mehr unterstützt und löst beim Aufruf eine Ausnahme aus. Wenn deine App Aktivitäten von Kacheln aus startet, verwende TileService#startActivityAndCollapse(PendingIntent).

Datenschutz

Teilzugriff auf Fotos und Videos

Android 14 引入了所选照片访问权限，可让用户授权应用访问其媒体库中的特定图片和视频，而不是授予对指定类型的所有媒体的访问权限。

仅当您的应用以 Android 14（API 级别 34）或更高版本为目标平台时，才会启用此变更。如果您还没有使用照片选择器，建议您在应用中实现该选择器，以便在选择图片和视频时提供一致的体验，同时还可以加强用户隐私保护，而无需请求任何存储权限。

如果您使用存储权限维护自己的图库选择器，并且需要完全控制您的实现，请调整您的实现，以使用新的 READ_MEDIA_VISUAL_USER_SELECTED 权限。如果您的应用不使用新权限，系统会在兼容模式下运行应用。

Nutzererfahrung

Sichere Vollbild-Intent-Benachrichtigungen

Mit Android 11 (API-Level 30) konnte jede App Notification.Builder.setFullScreenIntent verwenden, um Vollbild-Intents zu senden, während das Smartphone gesperrt ist. Sie können dies bei der App-Installation automatisch gewähren, indem Sie die Berechtigung USE_FULL_SCREEN_INTENT im AndroidManifest deklarieren.

Full-Screen Intent-Benachrichtigungen sind für Benachrichtigungen mit extrem hoher Priorität gedacht, die die sofortige Aufmerksamkeit des Nutzers erfordern, z. B. eingehende Anrufe oder vom Nutzer konfigurierte Weckereinstellungen. Bei Apps, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind, dürfen diese Berechtigungen nur für Apps verwendet werden, die nur Anrufe und Alarme anbieten. Im Google Play Store werden die USE_FULL_SCREEN_INTENT-Standardberechtigungen für alle Apps widerrufen, die diesem Profil nicht entsprechen. Die Frist für diese Richtlinienänderungen endet am 31. Mai 2024.

Diese Berechtigung bleibt für Apps aktiviert, die auf dem Smartphone installiert wurden, bevor der Nutzer ein Update auf Android 14 durchführt. Nutzer können diese Berechtigung aktivieren oder deaktivieren.

Mit der neuen API NotificationManager.canUseFullScreenIntent kannst du prüfen, ob deine App die Berechtigung hat. Falls nicht, kann deine App mit dem neuen Intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT die Seite mit den Einstellungen öffnen, auf der Nutzer die Berechtigung erteilen können.

Sicherheit

Einschränkungen für implizite und ausstehende Intents

Bei Apps, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind, schränkt Android so ein, dass Apps implizite Intents an interne App-Komponenten senden:

  • Implizite Intents werden nur an exportierte Komponenten gesendet. Anwendungen müssen entweder einen expliziten Intent für die Übermittlung an nicht exportierte Komponenten verwenden oder die Komponente als exportiert markieren.
  • Wenn eine App ein veränderliches ausstehendes Intent mit einem Intent erstellt, in dem keine Komponente oder kein Paket angegeben ist, löst das System eine Ausnahme aus.

Diese Änderungen verhindern, dass schädliche Anwendungen implizite Intents abfangen, die von den internen Komponenten einer Anwendung verwendet werden sollen.

Hier sehen Sie beispielsweise einen Intent-Filter, der in der Manifestdatei Ihrer App deklariert werden könnte:

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Wenn Ihre App versucht, diese Aktivität mit einem impliziten Intent zu starten, wird eine ActivityNotFoundException-Ausnahme geworfen:

Kotlin

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Java

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

Um die nicht exportierte Aktivität zu starten, sollte Ihre App stattdessen einen expliziten Intent verwenden:

Kotlin

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Java

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

Für Laufzeit registrierte Übertragungsempfänger muss das Exportverhalten angegeben werden

以 Android 14（API 级别 34）或更高版本为目标平台并使用上下文注册的接收器的应用和服务必须指定一个标志，以指明接收器是否应导出到设备上的所有其他应用：分别为 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED。此要求有助于利用 Android 13 中引入的这些接收器的功能，保护应用免受安全漏洞的影响。

仅接收系统广播的接收器的例外情况

如果您的应用仅通过 Context#registerReceiver 方法（例如 Context#registerReceiver()）为系统广播注册接收器，那么在注册接收器时不应指定标志。

Sichereres Laden dynamischen Codes

Wenn Ihre App auf Android 14 (API-Level 34) oder höher ausgerichtet ist und dynamisches Code-Laden (DCL) verwendet, müssen alle dynamisch geladenen Dateien als schreibgeschützt gekennzeichnet sein. Andernfalls wirft das System eine Ausnahme aus. Wir empfehlen, in Apps nach Möglichkeit keinen Code dynamisch zu laden, da dadurch das Risiko erheblich steigt, dass eine App durch Code-Injection oder Code-Manipulation manipuliert wird.

Wenn Sie Code dynamisch laden müssen, können Sie die dynamisch geladene Datei (z. B. eine DEX-, JAR- oder APK-Datei) so einstellen, dass sie nur lesbar ist, sobald sie geöffnet wird und bevor Inhalte geschrieben werden. Gehen Sie dazu so vor:

Kotlin

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

Java

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

Dynamisch geladene Dateien verarbeiten, die bereits vorhanden sind

Um zu verhindern, dass für vorhandene dynamisch geladene Dateien Ausnahmen ausgelöst werden, empfehlen wir, die Dateien zu löschen und neu zu erstellen, bevor Sie versuchen, sie wieder dynamisch in Ihre App zu laden. Beachten Sie beim Erstellen der Dateien die vorherigen Hinweise zum Markieren der Dateien beim Schreiben als schreibgeschützt. Alternativ können Sie die vorhandenen Dateien wieder als schreibgeschützt kennzeichnen. In diesem Fall empfehlen wir Ihnen jedoch dringend, zuerst die Integrität der Dateien zu prüfen (z. B. indem Sie die Signatur der Datei mit einem vertrauenswürdigen Wert vergleichen), um Ihre App vor schädlichen Aktionen zu schützen.

Zusätzliche Einschränkungen beim Starten von Aktivitäten im Hintergrund

Bei Apps, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind, schränkt das System weiter ein, wann Apps Aktivitäten im Hintergrund starten dürfen:

  • Wenn eine App eine PendingIntent mit PendingIntent#send() oder ähnlichen Methoden sendet, muss sie die Option aktivieren, wenn sie Berechtigungen zum Starten von Hintergrundaktivitäten gewähren möchte, um den ausstehenden Intent zu starten. Wenn Sie die Funktion aktivieren möchten, muss die App ein ActivityOptions-Bundle mit setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED) übergeben.
  • Wenn eine sichtbare App einen Dienst einer anderen App bindet, die im Hintergrund ausgeführt wird bindService()-Methode aktiviert, muss die sichtbare App wenn er dem Nutzer eigene Berechtigungen zum Starten von Hintergrundaktivitäten erteilen möchte. gebundenen Dienst. Wenn Sie die Funktion aktivieren möchten, muss die App das Flag BIND_ALLOW_ACTIVITY_STARTS beim Aufrufen der Methode bindService() enthalten.

Durch diese Änderungen werden die bestehenden Einschränkungen erweitert, indem Sie verhindern, dass schädliche Apps APIs missbrauchen und dadurch Unterbrechungen verursachen. Aktivitäten im Hintergrund.

Zip Path Traversal

Bei Apps, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind, verhindert Android die Sicherheitslücke beim ZIP-Pfaddurchlauf auf folgende Weise: ZipFile(String) und ZipInputStream.getNextEntry() gibt ZipException aus, wenn die Namen der ZIP-Dateieinträge „..“ enthalten oder mit „/“ beginnen.

Apps können diese Überprüfung durch Aufrufen von dalvik.system.ZipPathValidator.clearCallback() deaktivieren.

Für Apps, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind, wird in einem der folgenden Szenarien von MediaProjection#createVirtualDisplay ein SecurityException ausgelöst:

In Ihrer App muss der Nutzer vor jeder Aufnahme um seine Einwilligung gebeten werden. Eine einzelne Erfassungssitzung ist ein einzelner Aufruf von MediaProjection#createVirtualDisplay. Jede MediaProjection-Instanz darf nur einmal verwendet werden.

Umgang mit Konfigurationsänderungen

Wenn Ihre Anwendung MediaProjection#createVirtualDisplay aufrufen muss, um Konfigurationsänderungen wie Änderungen der Bildschirmausrichtung oder der Bildschirmgröße zu verarbeiten, können Sie die folgenden Schritte ausführen, um VirtualDisplay für die vorhandene MediaProjection-Instanz zu aktualisieren:

  1. Rufen Sie VirtualDisplay#resize mit der neuen Breite und Höhe auf.
  2. Geben Sie einen neuen Surface mit der neuen Breite und Höhe für VirtualDisplay#setSurface an.

Rückruf registrieren

Ihre App sollte einen Callback für den Fall registrieren, in dem der Nutzer keine Einwilligung zum Fortsetzen einer Erfassungssitzung erteilt. Implementieren Sie dazu Callback#onStop und lassen Sie Ihre App alle zugehörigen Ressourcen wie VirtualDisplay und Surface veröffentlichen.

Wenn deine App diesen Callback nicht registriert, MediaProjection#createVirtualDisplay gibt ein IllegalStateException aus, wenn deine App ihn aufruft.

Aktualisierte Einschränkungen für Nicht-SDKs

Android 14 enthält aktualisierte Listen eingeschränkter nicht SDK-basierter Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wann immer möglich, achten wir darauf, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn Ihre App nicht auf Android 14 ausgerichtet ist, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Level Ihrer App), aber bei Verwendung von Nicht-SDK-Methoden und -Feldern besteht immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert.

Wenn du nicht sicher bist, ob deine App Nicht-SDK-Schnittstellen verwendet, kannst du die App testen, um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Uns ist jedoch bewusst, dass es für einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. 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.

Weitere Informationen zu den Änderungen in diesem Android-Release finden Sie unter Aktualisierungen der Einschränkungen für Schnittstellen, die nicht auf SDK basieren, unter Android 14. Allgemeine Informationen zu Nicht-SDK-Schnittstellen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen.