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 deine App auf Android 14 oder höher ausgerichtet ist, solltest du sie gegebenenfalls anpassen, um diese Verhaltensweisen zu unterstützen.
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 im BluetoothAdapter
Android 14 erzwingt die Berechtigung BLUETOOTH_CONNECT
beim Aufrufen der
BluetoothAdapter
-Methode getProfileConnectionState()
für App-Targeting
Android 14 (API-Level 34) oder höher
Für diese Methode war bereits die Berechtigung BLUETOOTH_CONNECT
erforderlich, was aber nicht der Fall war
durchgesetzt wird. Achten Sie darauf, dass Ihre App BLUETOOTH_CONNECT
in der
AndroidManifest.xml
wie im folgenden Snippet gezeigt, und prüfen Sie, ob
Ein Nutzer hat die Berechtigung erteilt, bevor er aufgerufen wird.
getProfileConnectionState
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
Updates zu OpenJDK 17
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 Klassejava.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 FlagDISALLOW_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 einIllegalArgumentException
angezeigt. Wenn Sie diese Änderung während des Tests aktivieren oder deaktivieren möchten, aktivieren oder deaktivieren Sie das FlagENABLE_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, obClass.forName("java.lang.ClassValue")
eine Klasse zurückgibt oder nicht. Wenn Ihre App für eine ältere Version der Laufzeit ohne verfügbarejava.lang.ClassValue
-Klasse entwickelt wurde, wird durch diese Optimierungen möglicherweise die MethodecomputeValue
aus Klassen entfernt, die vonjava.lang.ClassValue
abgeleitet sind.
JobScheduler verstärkt Rückruf- und Netzwerkverhalten
Seit der Einführung erwartet JobScheduler, dass deine App innerhalb weniger Sekunden von onStartJob
oder onStopJob
zurückkehrt. Wenn ein Job vor Android 14 zu lange ausgeführt wird, wird er beendet und schlägt im Hintergrund fehl. Wenn Ihre App auf Android 14 (API-Level 34) oder höher ausgerichtet ist und die gewährte Zeit im Hauptthread überschreitet, löst die App einen ANR-Fehler mit der Fehlermeldung „Keine Antwort auf onStartJob
“ oder „Keine Antwort auf onStopJob
“ aus. Sie sollten zu WorkManager migrieren, um Unterstützung für die asynchrone Verarbeitung zu bieten oder anspruchsvolle Arbeiten in einen Hintergrundthread zu migrieren.
Mit JobScheduler
wird auch die Anforderung eingeführt, die Berechtigung ACCESS_NETWORK_STATE
zu deklarieren, wenn die Einschränkung setRequiredNetworkType
oder setRequiredNetwork
verwendet wird. Wenn Ihre App beim Planen des Jobs die Berechtigung ACCESS_NETWORK_STATE
nicht deklariert und auf Android 14 oder höher ausgerichtet ist, wird ein SecurityException
ausgegeben.
Tiles Launch API
Für Apps, die auf 14 und höher ausgerichtet sind, wurde TileService#startActivityAndCollapse(Intent)
verworfen und löst beim Aufruf eine Ausnahme aus. Wenn Ihre App Aktivitäten über Kacheln startet, verwenden Sie stattdessen TileService#startActivityAndCollapse(PendingIntent)
.
Datenschutz
Teilzugriff auf Fotos und Videos
Mit Android 14 wird der Zugriff auf ausgewählte Fotos eingeführt. Damit können Nutzer Apps Zugriff auf bestimmte Bilder und Videos in ihrer Fotogalerie gewähren, anstatt Zugriff auf alle Medien eines bestimmten Typs zu gewähren.
Diese Änderung ist nur aktiviert, wenn deine App auf Android 14 (API-Level 34) oder höher ausgerichtet ist. Wenn Sie die Bildauswahl noch nicht verwenden, empfehlen wir, sie in Ihrer App zu implementieren. So können Sie Bilder und Videos einheitlich auswählen und die Privatsphäre der Nutzer verbessern, ohne Speicherberechtigungen anfordern zu müssen.
Wenn Sie eine eigene Galerieauswahl mit Speicherberechtigungen verwenden und die volle Kontrolle über Ihre Implementierung haben müssen, passen Sie Ihre Implementierung an, um die neue Berechtigung READ_MEDIA_VISUAL_USER_SELECTED
zu verwenden. Wenn Ihre App die neue Berechtigung nicht verwendet, führt das System die App im Kompatibilitätsmodus aus.
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, werden Apps von Android so eingeschränkt, dass sie 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 Lieferung an nicht exportierte Komponenten verwenden oder die Komponente als exportiert markieren.
- Wenn eine App einen änderbaren ausstehenden Intent mit einem Intent erstellt, der keine Komponente oder kein Paket angibt, löst das System eine Ausnahme aus.
Diese Änderungen verhindern, dass schädliche Anwendungen implizite Intents abfangen, die für die internen Komponenten einer App verwendet werden sollen.
Das folgende Beispiel zeigt einen Intent-Filter, der in der Manifestdatei Ihrer App deklariert werden kann:
<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 Ausnahme ausgelöst:
Kotlin
// Throws an exception when targeting Android 14. context.startActivity(Intent("com.example.action.APP_ACTION"))
Java
// Throws an 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);
Empfänger von laufzeitregistrierten Broadcasts müssen das Exportverhalten festlegen
Apps und Dienste, die auf Android 14 (API-Level 34) oder höher ausgerichtet sind und kontextregistrierte Empfänger verwenden, müssen mit einem Flag angeben, ob der Empfänger in alle anderen Apps auf dem Gerät exportiert werden soll: entweder RECEIVER_EXPORTED
bzw. RECEIVER_NOT_EXPORTED
.
Diese Anforderung trägt durch die Funktionen für diese Empfänger in Android 13 zum Schutz von Apps vor Sicherheitslücken bei.
Ausnahme für Empfänger, die nur System-Broadcasts empfangen
Wenn Ihre App einen Empfänger nur für System-Broadcasts über Context#registerReceiver
-Methoden wie Context#registerReceiver()
registriert, sollte bei der Registrierung des Empfängers kein Flag angegeben werden.
Sichereres Laden von dynamischem Code
Wenn Ihre App auf Android 14 (API-Level 34) oder höher ausgerichtet ist und dynamischen Code verwendet wird Wird geladen (DCL) müssen alle dynamisch geladenen Dateien als schreibgeschützt markiert sein. Andernfalls gibt das System eine Ausnahme aus. Wir empfehlen, in Apps Code wird dynamisch geladen wenn möglich, da dadurch das Risiko, dass eine App durch Einschleusung oder Manipulation von Code gefährdet ist.
Wenn Sie Code dynamisch laden müssen, verwenden Sie den folgenden Ansatz, um den Parameter dynamisch geladene Datei (z. B. eine DEX-, JAR- oder APK-Datei) sofort schreibgeschützt wenn die Datei geöffnet wird und bevor Inhalte geschrieben werden:
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 Ausnahmen für vorhandene dynamisch geladene Dateien ausgelöst werden, empfehlen wir, die Dateien zu löschen und neu zu erstellen, bevor Sie versuchen, laden Sie sie erneut in Ihrer App. Befolgen Sie beim Neuerstellen der Dateien wie Sie die Dateien beim Schreiben als schreibgeschützt markieren. Alternativ können Sie beschriften die vorhandenen Dateien als schreibgeschützt. In diesem Fall sollten Sie jedoch unbedingt empfiehlt es sich, zuerst die Integrität der Dateien zu überprüfen (z. B. durch die Signatur der Datei auf einen vertrauenswürdigen Wert prüft), um Ihre App zu schützen vor bösartigen Handlungen.
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, wird durch das System weiter eingeschränkt, wann Apps Aktivitäten im Hintergrund starten dürfen:
- Wenn eine App eine
PendingIntent
mitPendingIntent#send()
oder ähnlichen Methoden sendet, muss die App zustimmen, wenn sie ihre eigenen Berechtigungen zum Starten von Hintergrundaktivitäten gewähren möchte, um den ausstehenden Intent zu starten. Zur Aktivierung muss die App einActivityOptions
-Bundle mitsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
übergeben. - Wenn eine sichtbare Anwendung einen Dienst einer anderen Anwendung, die sich im Hintergrund mit der Methode
bindService()
befindet, bindet, muss die sichtbare Anwendung jetzt aktivieren, wenn sie dem gebundenen Dienst ihre eigenen Berechtigungen zum Starten von Hintergrundaktivitäten gewähren möchte. Zum Aktivieren muss die App beim Aufrufen der MethodebindService()
das FlagBIND_ALLOW_ACTIVITY_STARTS
enthalten.
Durch diese Änderungen werden die bestehenden Einschränkungen erweitert, um Nutzer zu schützen. Es wird verhindert, dass schädliche Anwendungen APIs missbrauchen und störende Aktivitäten im Hintergrund auslösen.
Zip Path Traversal (Pfaddurchlauf mit ZIP-Datei)
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.
Nutzereinwilligung für jede MediaProjection-Erfassungssitzung erforderlich
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:
- Ihre App speichert das von
MediaProjectionManager#createScreenCaptureIntent
zurückgegebeneIntent
im Cache und übergibt es mehrmals anMediaProjectionManager#getMediaProjection
. - Ihre Anwendung ruft
MediaProjection#createVirtualDisplay
mehrmals auf derselbenMediaProjection
-Instanz auf.
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:
- Rufen Sie
VirtualDisplay#resize
mit der neuen Breite und Höhe auf. - Geben Sie einen neuen
Surface
mit der neuen Breite und Höhe fürVirtualDisplay#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.
Nicht-SDK-Einschränkungen aktualisiert
Android 14 enthält aktualisierte Listen eingeschränkter Nicht-SDK-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 deine App nicht auf Android 14 ausgerichtet ist, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. 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 benötigt, sollten Sie eine Migration zu SDK-Alternativen planen. Uns ist aber bewusst, dass es bei einigen Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. 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.
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.