Verhaltensänderungen: alle Apps

Die Android 17-Plattform enthält Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten für alle Apps, wenn sie unter Android 17 ausgeführt werden, unabhängig von targetSdkVersion. Sie sollten Ihre App testen und dann gegebenenfalls so anpassen, dass sie diese Änderungen unterstützt.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die nur Apps betreffen, die auf Android 17 ausgerichtet sind.

Hauptfunktion

Android 17 (API-Level 37) enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems ändern oder erweitern.

App-Arbeitsspeicherlimits

Mit Android 17 werden App-Arbeitsspeicherlimits eingeführt, die auf dem gesamten RAM des Geräts basieren. So wird eine stabilere und deterministischere Umgebung für Ihre Apps und Android-Nutzer geschaffen. Diese Limits konzentrieren sich auf Speicherlecks und andere Ausreißer, bevor sie zu systemweiten Instabilitäten führen, die ein Ruckeln der Benutzeroberfläche, einen höheren Akkuverbrauch und das Beenden von Apps zur Folge haben. Wir gehen davon aus, dass die Auswirkungen auf die meisten App-Sitzungen minimal sein werden. Wir empfehlen jedoch, die folgenden Best Practices für den Arbeitsspeicher zu beachten, einschließlich der Festlegung einer Baseline für den Arbeitsspeicher.

Sie können feststellen, ob Ihre App-Sitzung betroffen war, indem Sie getDescription in ApplicationExitInfo aufrufen. Wenn Ihre App betroffen war, lautet der Grund für das Beenden REASON_OTHER und die Beschreibung enthält den String "MemoryLimiter:AnonSwap" sowie weitere Informationen. Sie können auch die triggerbasierte Profilerstellung mit TRIGGER_TYPE_ANOMALY verwenden, um Heap-Dumps zu erhalten, die erfasst werden, wenn das Speicherlimit erreicht wird.

In der Dokumentation Verwaltung Ihres App-Speichers finden Sie Informationen, die Ihnen helfen, Speicherprobleme Ihrer App zu diagnostizieren und den Ressourcenverbrauch zu optimieren.

Verhalten der App unter den Arbeitsspeicherbeschränkungen testen

Mit der Android Debug Bridge (adb) können Sie die Arbeitsspeicherlimits auf jedem Gerät, auf dem sie gelten, anpassen oder deaktivieren. Der Shell-Befehl am bietet drei Unterbefehle zum Anpassen der Arbeitsspeicherlimits. (Diese Befehle haben keine Auswirkungen auf ein Gerät, das keine Speicherlimits erzwingt.)

• am memory-limiter ignore <uid>|none|all
• am memory-limiter manual <pid> <limit>|max|none
• am memory-limiter status

ignore

Weist den Memory Limiter an, einige oder alle Prozesse zu ignorieren. Wenn Sie eine UID (Android-Nutzer-ID) übergeben, wird der Speicherbegrenzer angewiesen, die Erzwingung für alle mit dieser UID verknüpften Prozesse zu ignorieren. Sie können auch all (alle Apps ignorieren) oder none (keine Apps ignorieren) übergeben. Wenn Sie none übergeben, werden alle vorherigen Aufrufe von am memory-limiter ignore überschrieben.

Wenn Sie die Speicherbegrenzung anweisen, eine UID zu ignorieren, können Sie trotzdem ein manuelles Speicherlimit auf einen Prozess innerhalb der App anwenden, indem Sie am memory-limiter manual aufrufen.

manual

Weist das System an, dem Prozess mit der angegebenen PID (Prozess-ID) eine Arbeitsspeicherbeschränkung aufzuerlegen. Die Speicherbeschränkung wird als Ganzzahl in MB angegeben. Wenn Sie beispielsweise 30 übergeben, wird der Prozess auf 30 MB Speicher beschränkt. Wenn Sie max übergeben, werden alle Arbeitsspeicherlimits für diesen Prozess entfernt. Wenn Sie none übergeben, werden alle manuellen Limits für den Prozess entfernt und das Standardlimit des Systems (falls vorhanden) wird wiederhergestellt.

status

Meldet den aktuellen Status des Memory Limiters. Der Status enthält die Arbeitsspeicherlimits, die für sichtbare und nicht sichtbare Prozesse gelten.

Datenschutz

Android 17 enthält die folgenden Änderungen zur Verbesserung des Datenschutzes für Nutzer.

SMS-OTP-Schutz

Ab Android 17 wird der Schutz für SMS mit Einmalpasswörtern (OTP) erweitert.

In früheren Android-Versionen konzentrierte sich dieser Schutz hauptsächlich auf das SMS Retriever-Format. Die Zustellung von Nachrichten mit einem SMS-Retriever-Hash wurde für die meisten Apps um drei Stunden verzögert. Bestimmte Apps (z. B. der Standard-SMS-Handler) waren jedoch von der Verzögerung ausgenommen, ebenso wie die App, die den Hash besaß.

Ab Android 17 wird der Schutz auch auf Nachrichten im WebOTP-Format angewendet. Wenn eine App die Berechtigung zum Lesen von SMS hat, aber nicht der vorgesehene Empfänger einer WebOTP-Nachricht ist (wie durch die Domainbestätigung ermittelt), kann die App erst drei Stunden nach dem Empfang der Nachricht auf diese zugreifen. Mit dieser Änderung soll die Sicherheit der Nutzer verbessert werden, da nur Apps, die mit der in der Nachricht genannten Domain verknüpft sind, den Bestätigungscode programmatisch lesen können.

Während dieser dreistündigen Verzögerung wird die SMS_RECEIVED_ACTION-Übertragung zurückgehalten und Datenbankabfragen des SMS-Anbieters werden gefiltert. Die SMS ist für diese Apps nach der Verzögerung verfügbar. Diese Änderung gilt für alle Apps, unabhängig von ihrem Ziel-API-Level.

Bestimmte Apps wie die Standard-SMS-Assistent-App, Companion-Apps für verbundene Geräte usw. sind von dieser Verzögerung ausgenommen. Alle Apps, die zum Extrahieren von OTPs auf das Lesen von SMS-Nachrichten angewiesen sind, sollten auf die SMS Retriever API oder die SMS Nutzereinwilligung API umgestellt werden, damit sie weiterhin funktionieren.

Sicherheit

Android 17 enthält die folgenden Verbesserungen für die Geräte- und App-Sicherheit.

Zeitplan für die Einstellung von „usesClearTraffic“

Wir planen, das usesCleartextTraffic-Element in einer zukünftigen Version einzustellen. Apps, die unverschlüsselte (HTTP-)Verbindungen herstellen müssen, sollten auf die Verwendung einer Netzwerksicherheitskonfigurationsdatei umgestellt werden. Mit dieser Datei können Sie angeben, zu welchen Domains Ihre App Klartextverbindungen herstellen muss.

Konfigurationsdateien für die Netzwerksicherheit werden nur ab API-Level 24 unterstützt. Wenn Ihre App ein Mindest-API-Level unter 24 hat, sollten Sie beide der folgenden Schritte ausführen:

• Setzen Sie das Attribut usesCleartextTraffic auf true.
• Netzwerkkonfigurationsdatei verwenden

Wenn das Mindest-API-Level Ihrer App 24 oder höher ist, können Sie eine Netzwerkkonfigurationsdatei verwenden und müssen usesCleartextTraffic nicht festlegen.

Implizite URI-Gewährungen einschränken

Wenn eine App derzeit einen Intent mit einem URI startet, der die Aktion ACTION_SEND, ACTION_SEND_MULTIPLE oder ACTION_IMAGE_CAPTURE hat, gewährt das System der Ziel-App automatisch die Lese- und Schreibberechtigungen für den URI. Ab Android 18 gewährt das System diese Berechtigungen nicht mehr automatisch. Aus diesem Grund empfehlen wir, dass Apps die relevanten URI-Berechtigungen explizit gewähren, anstatt sich darauf zu verlassen, dass das System sie gewährt.

Wenn Sie die Verwendung dieser Intents in Ihrer App erkennen möchten, verwenden Sie StrictMode mit detectImplicitUriPermissionGrant(), um einen Verstoß auszulösen:

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Alternativ können Sie nach protokollierten Ausnahmen mit der Nachricht Please set the grant explicitly in the app suchen, die angezeigt wird, wenn das System die Berechtigung implizit festlegt. Sie können diese Logs mit dem folgenden adb-Befehl überwachen:

adb logcat | grep "Please set the grant explicitly in the app"

Wenn Sie die erforderlichen Berechtigungen explizit gewähren möchten, fügen Sie den Intents ACTION_SEND und ACTION_SEND_MULTIPLE das Flag FLAG_GRANT_READ_URI_PERMISSION hinzu:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Fügen Sie sowohl das Flag FLAG_GRANT_READ_URI_PERMISSION als auch das Flag FLAG_GRANT_WRITE_URI_PERMISSION für ACTION_IMAGE_CAPTURE-Intents ein:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Keystore-Limits pro App

Apps sollten es vermeiden, eine übermäßige Anzahl von Schlüsseln im Android Keystore zu erstellen, da es sich um eine gemeinsam genutzte Ressource für alle Apps auf dem Gerät handelt. Ab Android 17 gilt eine Beschränkung für die Anzahl der Schlüssel, die eine App besitzen kann. Das Limit liegt bei 50.000 Schlüsseln für Nicht-System-Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind, und bei 200.000 Schlüsseln für alle anderen Apps. Für System-Apps gilt ein Limit von 200.000 Schlüsseln,unabhängig davon, auf welches API-Level sie ausgerichtet sind.

Wenn eine App versucht, Schlüssel über das Limit hinaus zu erstellen, schlägt die Erstellung mit dem Fehler KeyStoreException fehl. Der Nachrichtenstring der Ausnahme enthält Informationen zum Schlüssel-Limit. Wenn die App getNumericErrorCode() für die Ausnahme aufruft, hängt der Rückgabewert davon ab, auf welches API-Level die App ausgerichtet ist:

• Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind: getNumericErrorCode() gibt den neuen ERROR_TOO_MANY_KEYS-Wert zurück.
• Alle anderen Apps: getNumericErrorCode() gibt ERROR_INCORRECT_USAGE zurück.

Profilübergreifenden Loopback-Traffic blockieren

Ab Android 17 ist profilübergreifender Loopback-Traffic standardmäßig nicht mehr zulässig. Loopback-Traffic innerhalb desselben Profils ist nicht betroffen. Diese Änderung gilt für alle Apps, die unter Android 17 oder höher ausgeführt werden, unabhängig davon, auf welches API-Level die App ausgerichtet ist.

Nutzererfahrung und System-UI

Android 17 enthält die folgenden Änderungen, die für eine einheitlichere, intuitivere Nutzererfahrung sorgen sollen.

Standard-IME-Sichtbarkeit nach Drehung wiederherstellen

Ab Android 17 wird die vorherige IME-Sichtbarkeit nicht wiederhergestellt, wenn sich die Konfiguration des Geräts ändert (z. B. durch Drehen) und dies nicht von der App selbst verarbeitet wird.

Wenn in Ihrer App eine Konfigurationsänderung vorgenommen wird, die nicht von der App verarbeitet wird, und die Tastatur nach der Änderung sichtbar sein muss, müssen Sie dies explizit anfordern. Sie können diese Anfrage auf eine der folgenden Arten stellen:

• Setzen Sie das Attribut android:windowSoftInputMode auf stateAlwaysVisible.
• Fordern Sie die Bildschirmtastatur programmatisch in der Methode onCreate() Ihrer Aktivität an oder fügen Sie die Methode onConfigurationChanged() hinzu.

Menschliche Eingabe

Android 17 enthält die folgenden Änderungen, die sich darauf auswirken, wie Apps mit Eingabegeräten wie Tastaturen und Touchpads interagieren.

Touchpads liefern während der Zeigererfassung standardmäßig relative Ereignisse

Ab Android 17 erkennt das System, wenn eine App die Zeigererfassung mit View.requestPointerCapture() anfordert und der Nutzer ein Touchpad verwendet, die Zeigerbewegungen und Scrollgesten des Nutzers und meldet sie der App auf die gleiche Weise wie Zeiger- und Scrollradbewegungen einer erfassten Maus. In den meisten Fällen ist es dann nicht mehr erforderlich, dass Apps, die erfasste Mäuse unterstützen, eine spezielle Verarbeitungslogik für Touchpads hinzufügen. Weitere Informationen finden Sie in der Dokumentation zu View.POINTER_CAPTURE_MODE_RELATIVE.

Zuvor hat das System nicht versucht, Touchpad-Gesten zu erkennen. Stattdessen wurden die rohen, absoluten Fingerpositionen in einem ähnlichen Format wie Touchscreen-Berührungen an die App gesendet. Wenn eine App diese absoluten Daten weiterhin benötigt, sollte sie stattdessen die neue Methode View.requestPointerCapture(int) mit View.POINTER_CAPTURE_MODE_ABSOLUTE aufrufen.

Medien

Android 17 enthält die folgenden Änderungen am Medienverhalten.

Härtung von Hintergrundaudio

Ab Android 17 erzwingt das Audio-Framework Einschränkungen für Audiointeraktionen im Hintergrund, einschließlich Audiowiedergabe, Audiofokus-Anfragen und APIs zur Lautstärkeänderung, um sicherzustellen, dass diese Änderungen vom Nutzer beabsichtigt sind.

Wenn die App versucht, Audio-APIs aufzurufen, während sie sich nicht in einem gültigen Lebenszyklus befindet, schlagen die APIs für die Audiowiedergabe und die Lautstärkeänderung ohne Fehlermeldung oder Ausnahme fehl. Die Audiofokus-API schlägt mit dem Ergebniscode AUDIOFOCUS_REQUEST_FAILED fehl.

Weitere Informationen, einschließlich Strategien zur Risikominderung, finden Sie unter Härtung von Hintergrundaudio.

Verbindung

Android 17 enthält die folgenden Änderungen zur Verbesserung der Gerätekonnektivität.

Automatische Wiederherstellung der Bluetooth-Verbindung bei Verbindungsverlust

Mit Android 17 wird die automatische Neukopplung eingeführt, eine Verbesserung auf Systemebene, die Bluetooth-Verbindungsverluste automatisch beheben soll.

Bisher mussten Nutzer, wenn eine Verbindung verloren ging, manuell die Einstellungen aufrufen, um das Peripheriegerät zu entkoppeln und dann wieder zu koppeln. Diese Funktion baut auf der Sicherheitsverbesserung von Android 16 auf. Das System kann Verbindungen im Hintergrund wiederherstellen, ohne dass Nutzer manuell die Einstellungen aufrufen müssen, um Peripheriegeräte zu entkoppeln und neu zu koppeln.

Für die meisten Apps sind keine Codeänderungen erforderlich. Entwickler sollten jedoch die folgenden Verhaltensänderungen im Bluetooth-Stack beachten:

• Neuer Kopplungskontext:Der ACTION_PAIRING_REQUEST enthält jetzt das Extra EXTRA_PAIRING_CONTEXT, mit dem Apps zwischen einer Standardkopplungsanfrage und einem autonomen, vom System initiierten Versuch zur erneuten Kopplung unterscheiden können.
• Bedingte Schlüsselaktualisierungen:Vorhandene Sicherheitsschlüssel werden nur ersetzt, wenn die erneute Kopplung erfolgreich ist und die neue Verbindung das Sicherheitsniveau der vorherigen Bindung erreicht oder übertrifft.
• Geändertes Intent-Timing:Der Intent ACTION_KEY_MISSING wird jetzt nur noch gesendet, wenn der Versuch einer automatischen erneuten Kopplung fehlschlägt. Dadurch wird die unnötige Fehlerbehandlung in der App reduziert, wenn das System die Kopplung im Hintergrund erfolgreich wiederherstellt.
• Nutzerbenachrichtigung:Das System verwaltet die erneute Kopplung über neue UI-Benachrichtigungen und ‑Dialogfelder. Nutzer werden aufgefordert, den Versuch der erneuten Kopplung zu bestätigen, damit sie sich der erneuten Verbindung bewusst sind.

Hersteller von Peripheriegeräten und Entwickler von Companion-Apps sollten prüfen, ob die Hardware und die App die Übergänge zwischen den Bindungen ordnungsgemäß verarbeiten. Wenn Sie dieses Verhalten testen möchten, simulieren Sie einen Remote-Bond-Verlust mit einer der folgenden Methoden:

• Entferne die Kopplungsinformationen manuell vom Peripheriegerät.
• Entkopple das Gerät manuell unter „Einstellungen“ > „Verbundene Geräte“.