Verhaltensänderungen: alle Apps

Die Android 17-Plattform umfasst 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 sie bei Bedarf an diese Änderungen anpassen.

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

Hauptfunktion

Android 17 (API‑Level 37) enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems modifizieren 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 Grenzwerte konzentrieren sich auf Speicherlecks und andere Ausreißer, bevor sie systemweite Instabilität auslösen, die zu Ruckeln der Benutzeroberfläche, höherem Akkuverbrauch und dem Beenden von Apps führt. Wir gehen davon aus, dass die Auswirkungen auf die überwiegende Mehrheit der App-Sitzungen minimal sein werden. Wir empfehlen jedoch, die folgenden Best Practices für den Arbeitsspeicher zu befolgen, 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, ist der Beendigungsanlass REASON_OTHER und die Beschreibung enthält den String "MemoryLimiter:AnonSwap" sowie andere Informationen. Sie können auch triggerbasiertes Profiling mit TRIGGER_TYPE_ANOMALY verwenden, um Heap-Dumps zu erhalten, die erfasst werden, wenn das Speicherlimit erreicht wird.

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

Verhalten der App bei Arbeitsspeicherbeschränkungen testen

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

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

ignore

Weist den Arbeitsspeicherbegrenzer an, einige oder alle Prozesse zu ignorieren. Wenn Sie eine UID (Android-Nutzer-ID) übergeben, wird der Speicherbegrenzer angewiesen, die Erzwingung für alle Prozesse zu ignorieren, die mit dieser UID verknüpft sind. 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 den Speicherbegrenzer anweisen, eine UID zu ignorieren, können Sie weiterhin ein manuelles Speicherlimit für einen Prozess in der App festlegen, indem Sie am memory-limiter manual aufrufen.

manual

Weist das System an, dem Prozess mit der angegebenen PID (Prozess-ID) eine Speicherbeschränkung aufzuerlegen. Die Arbeitsspeicherbeschränkung wird als Ganzzahl in MB angegeben. Wenn Sie beispielsweise 30 übergeben, ist der Prozess auf 30 MB Arbeitsspeicher 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

Gibt den aktuellen Status des Arbeitsspeicherlimits an. Der Status umfasst die Speicherlimits für sichtbare und nicht sichtbare Prozesse.

Datenschutz

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

SMS-OTP-Schutz

Ab Android 17 wird der Schutz von SMS-Nachrichten 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. die Standard-SMS-App) waren jedoch von der Verzögerung ausgenommen. Das galt auch für 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-Nachrichten hat, aber nicht der beabsichtigte Empfänger einer WebOTP-Nachricht ist (was durch die Domainbestätigung ermittelt wird), kann die App erst drei Stunden nach Erhalt der Nachricht darauf zugreifen. Mit dieser Änderung soll die Sicherheit der Nutzer verbessert werden. Nur Apps, die mit der in der Nachricht genannten Domain verknüpft sind, können den Bestätigungscode programmatisch lesen.

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 nach der Verzögerung für diese Apps verfügbar. Diese Änderung gilt für alle Apps, unabhängig von ihrem Ziel-API-Level.

Bestimmte Apps wie die standardmäßige SMS-Assistenten-App oder Companion-Apps für verbundene Geräte sind von dieser Verzögerung ausgenommen. Alle Apps, die zum Extrahieren von Einmalpasswörtern auf das Lesen von SMS angewiesen sind, sollten zur Aufrechterhaltung der Funktionalität auf die APIs SMS Retriever oder SMS User Consent umgestellt werden.

Sicherheit

Android 17 bietet die folgenden Verbesserungen für die Sicherheit von Geräten und Apps.

Einstellungszeitplan für usesClearTraffic

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

Beachten Sie, dass Dateien für die Netzwerksicherheitskonfiguration nur auf API-Levels 24 und höher unterstützt werden. Wenn das Mindest-API-Level Ihrer App niedriger als 24 ist, sollten Sie beides tun:

• 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 Schreib-URI-Berechtigungen. Ab Android 18 gewährt das System diese Berechtigungen nicht mehr automatisch. Aus diesem Grund empfehlen wir, dass Apps die entsprechenden URI-Berechtigungen explizit erteilen, anstatt sich darauf zu verlassen, dass das System sie erteilt.

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 Meldung 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 das Flag FLAG_GRANT_READ_URI_PERMISSION den Intents ACTION_SEND und ACTION_SEND_MULTIPLE 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 nicht zu viele Schlüssel im Android-Keystore erstellen, da es sich um eine gemeinsam genutzte Ressource für alle Apps auf dem Gerät handelt. Ab Android 17 erzwingt das System ein Limit für die Anzahl der Schlüssel, die einer App gehören können. 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. System-Apps haben ein Limit von 200.000 Schlüsseln,unabhängig davon, auf welche API-Ebene sie ausgerichtet sind.

Wenn eine App versucht, über das Limit hinaus Schlüssel zu erstellen, schlägt die Erstellung mit dem Fehler KeyStoreException fehl. Der Meldungsstring der Ausnahme enthält Informationen zum Schlüssellimit. 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 Cross-Profile-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, intuitive 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 erfolgt, die nicht verarbeitet wird, und die App nach der Änderung die Tastatur benötigt, müssen Sie dies explizit anfordern. Sie können diesen Antrag auf eine der folgenden Arten stellen:

• Legen Sie das Attribut android:windowSoftInputMode auf stateAlwaysVisible fest.
• 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 standardmäßig relative Ereignisse während der Zeigererfassung

Ab Android 17 erkennt das System Zeigerbewegungen und Scrollgesten, die der Nutzer auf einem Touchpad ausführt, wenn eine App mit View.requestPointerCapture() die Zeigererfassung anfordert. Diese werden der App auf dieselbe Weise gemeldet wie Zeiger- und Mausradbewegungen einer erfassten Maus. In den meisten Fällen ist es dann nicht mehr erforderlich, dass Apps, die erfasste Mäuse unterstützen, eine spezielle Logik für Touchpads hinzufügen. Weitere Informationen finden Sie in der Dokumentation zu View.POINTER_CAPTURE_MODE_RELATIVE.

Bisher hat das System nicht versucht, Touchpad-Gesten zu erkennen, sondern 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 Media-Verhalten.

Härtung von Audio im Hintergrund

Ab Android 17 werden im Audio-Framework Einschränkungen für Audiointeraktionen im Hintergrund erzwungen, darunter Audiowiedergabe, Audiofokus-Anfragen und Lautstärkeänderungs-APIs. So soll sichergestellt werden, dass diese Änderungen vom Nutzer initiiert werden.

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 Lautstärkeänderung fehl, ohne eine Ausnahme auszulösen oder eine Fehlermeldung auszugeben. Die Audio-Fokus-API schlägt mit dem Ergebniscode AUDIOFOCUS_REQUEST_FAILED fehl.

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

Konnektivität

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

Autonome Neukopplung bei Verlust der Bluetooth-Verbindung

Mit Android 17 wird die autonome erneute Kopplung eingeführt, eine Verbesserung auf Systemebene, die darauf ausgelegt ist, den Verlust von Bluetooth-Verbindungen automatisch zu beheben.

Bisher mussten Nutzer bei Verlust einer Verbindung manuell zu den Einstellungen gehen, um das Peripheriegerät zu entkoppeln und dann wieder zu koppeln. Diese Funktion baut auf den Sicherheitsverbesserungen von Android 16 auf. Das System kann Verbindungen im Hintergrund wiederherstellen, ohne dass Nutzer Peripheriegeräte manuell in den Einstellungen entkoppeln und neu koppeln müssen.

Bei den meisten Apps sind keine Codeänderungen erforderlich. Entwickler sollten jedoch die folgenden Änderungen am Bluetooth-Stack beachten:

• Neuer Kontext für die Kopplung:Das ACTION_PAIRING_REQUEST enthält jetzt das Extra EXTRA_PAIRING_CONTEXT, mit dem Apps zwischen einer Standardkopplungsanfrage und einem vom autonomen System initiierten erneuten Kopplungsversuch 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 Verbindung erreicht oder übertrifft.
• Geänderter Intent-Zeitpunkt:Der Intent ACTION_KEY_MISSING wird jetzt nur übertragen, wenn der autonome Versuch, die Geräte neu zu koppeln, fehlschlägt. Dadurch wird die unnötige Fehlerbehandlung in der App reduziert, wenn das System die Verbindung im Hintergrund erfolgreich wiederherstellt.
• Nutzerbenachrichtigung:Das System verwaltet das erneute Pairing über neue UI-Benachrichtigungen und ‑Dialogfelder. Nutzer werden aufgefordert, den erneuten Kopplungsversuch zu bestätigen, damit sie über die erneute Verbindung informiert sind.

Hersteller von Peripheriegeräten und Entwickler von Companion-Apps sollten prüfen, ob Hardware und App Übergänge bei der Gerätekopplung problemlos verarbeiten. Um dieses Verhalten zu testen, können Sie einen Verlust der Remote-Verbindung mit einer der folgenden Methoden simulieren:

• Entfernen Sie die Informationen zur Kopplung manuell vom Peripheriegerät.
• Entfernen Sie die Kopplung des Geräts manuell unter „Einstellungen“ > „Verbundene Geräte“.