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

Wie bei früheren Versionen enthält Android 17 Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 17 oder höher ausgerichtet sind. Wenn Ihre App auf Android 17 oder höher ausgerichtet ist, sollten Sie sie gegebenenfalls so anpassen, dass sie diese Verhaltensweisen unterstützt.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die sich auf alle Apps auswirken, die unter Android 17 ausgeführt werden, unabhängig vom targetSdkVersion Ihrer App.

Nutzererfahrung und System-UI

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

Widget „Arbeitsspeicherlimit“

Ab Android 17 erzwingt das System für Apps, die auf Android 17 (API‑Level 37) oder höher ausgerichtet sind, ein strenges Speicherlimit (1,5 × Bildschirmbreite × Bildschirmhöhe × 4) für die kombinierte Speichernutzung von Bitmaps und Symbolen im RemoteViews-Paket. Das Überschreiten dieser Beschränkungen führt zu einem schwerwiegenden IllegalArgumentException-Fehler und zum Absturz des App-Prozesses.

Weitere Informationen finden Sie unter UpdateAppWidget.

Hauptfunktion

Android 17 umfasst die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems modifizieren oder erweitern.

Neue sperrenfreie Implementierung von MessageQueue

Ab Android 17 erhalten Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind, eine neue sperrenfreie Implementierung von android.os.MessageQueue. Die neue Implementierung verbessert die Leistung und reduziert die Anzahl der ausgelassenen Frames. Sie kann jedoch Clients beeinträchtigen, die private Felder und Methoden von MessageQueue verwenden.

Weitere Informationen, einschließlich Strategien zur Risikominderung, finden Sie unter Leitfaden zur Verhaltensänderung von MessageQueue.

Statische finale Felder können nicht mehr geändert werden

Apps, die unter Android 17 oder höher ausgeführt werden und auf Android 17 (API‑Level 37) oder höher ausgerichtet sind, können static final-Felder nicht ändern. Wenn eine App versucht, ein static final-Feld mithilfe von Reflection zu ändern, führt dies zu einem IllegalAccessException. Wenn Sie versuchen, eines dieser Felder über JNI-APIs (z. B. SetStaticLongField()) zu ändern, stürzt die App ab.

Bedienungshilfen

In Android 17 werden die folgenden Änderungen vorgenommen, um die Barrierefreiheit zu verbessern.

Unterstützung von Bedienungshilfen für die Eingabe über physische Tastaturen mit komplexen IME-Methoden

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

  • IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.

  • Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).

  • Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

Datenschutz

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

ECH (Encrypted Client Hello) aktiviert

Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.

For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.

To allow apps to customize this behavior, Android 17 adds a new <domainEncryption> element to the Network Security Configuration file. Developers can use <domainEncryption> within <base-config> or <domain-config> tags to select an ECH mode (for example, "enabled" or "disabled") on a global or per-domain basis.

For more information, see the Encrypted Client Hello documentation.

Berechtigung für das lokale Netzwerk für Apps, die auf Android 17 ausgerichtet sind, erforderlich

Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission to protect users from unauthorized local network access. Because this falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions aren't prompted again. This new requirement prevents malicious apps from exploiting unrestricted local network access for covert user tracking and fingerprinting. By declaring and requesting this permission, your app can discover and connect to devices on the local area network (LAN), such as smart home devices or casting receivers.

Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.

For more information, see the Local network permission documentation.

Passwörter auf physischen Geräten ausblenden

Wenn eine App auf Android 17 (API‑Level 37) oder höher ausgerichtet ist und der Nutzer ein physisches Eingabegerät (z. B. eine externe Tastatur) verwendet, wendet das Android-Betriebssystem die neue Einstellung show_passwords_physical auf alle Zeichen im Passwortfeld an. Standardmäßig werden alle Passwortzeichen ausgeblendet.

Das Android-System zeigt das zuletzt eingegebene Passwortzeichen an, damit der Nutzer sehen kann, ob er das Passwort falsch eingegeben hat. Bei größeren externen Tastaturen ist dies jedoch viel weniger notwendig. Außerdem haben Geräte mit externen Tastaturen oft größere Displays, was die Gefahr erhöht, dass jemand das eingegebene Passwort sieht.

Wenn der Nutzer den Touchscreen des Geräts verwendet, wendet das System die neue Einstellung show_passwords_touch an.

OTP-Schutz für Standard-SMS-Nachrichten

Ab Android 17 wird der SMS-OTP-Schutz von Android auf Standard-SMS-Nachrichten ausgeweitet (SMS-Nachrichten mit einem OTP, die nicht das WebOTP- oder SMS Retriever-Format verwenden). Bei den meisten Apps, die auf Android 17 (API‑Level 37) oder höher ausgerichtet sind, sind diese SMS erst drei Stunden nach Erhalt verfügbar. Diese Verzögerung soll dazu beitragen, das Abfangen von Einmalpasswörtern zu verhindern. Während dieser dreistündigen Verzögerung wird die SMS_RECEIVED_ACTION-Übertragung zurückgehalten und die Datenbankabfragen des SMS-Anbieters werden gefiltert. Die SMS ist nach der Verzögerung für diese Apps verfügbar.

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

In Android 17 wurden die folgenden Verbesserungen an der Geräte- und App-Sicherheit vorgenommen.

Aktivitätssicherheit

In Android 17 wird die Plattform weiterhin in Richtung einer „secure-by-default“-Architektur verschoben. Es werden eine Reihe von Verbesserungen eingeführt, die darauf ausgelegt sind, Exploits mit hohem Schweregrad wie Phishing, Hijacking von Interaktionen und Confused Deputy-Angriffe zu minimieren. Mit diesem Update müssen Entwickler explizit in neue Sicherheitsstandards einwilligen, um die App-Kompatibilität und den Nutzerschutz aufrechtzuerhalten.

Wichtige Auswirkungen für Entwickler:

  • BAL-Härtung und verbesserte Einwilligung: Wir optimieren die Einschränkungen für den Start von Hintergrundaktivitäten (Background Activity Launch, BAL), indem wir den Schutz auf IntentSender ausweiten. Entwickler müssen die alte Konstante MODE_BACKGROUND_ACTIVITY_START_ALLOWED nicht mehr verwenden. Stattdessen sollten Sie detaillierte Steuerelemente wie MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE verwenden, die den Start von Aktivitäten auf Szenarien beschränken, in denen die aufrufende App sichtbar ist. Dadurch wird die Angriffsfläche erheblich verringert.
  • Tools zur Einführung:Entwickler sollten den Strict-Modus und aktualisierte Lint-Prüfungen verwenden, um alte Muster zu erkennen und die Kompatibilität mit zukünftigen Anforderungen an das Ziel-SDK sicherzustellen.

CT standardmäßig aktivieren

Wenn eine App auf Android 17 (API‑Level 37) oder höher ausgerichtet ist, ist Certificate Transparency (CT) standardmäßig aktiviert. Unter Android 16 ist CT verfügbar, aber Apps mussten aktiviert werden.

Safer Native DCL—C

If your app targets Android 17 (API level 37) or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries.

All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.

We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

Felder mit personenidentifizierbaren Informationen in der CP2-Datenansicht einschränken

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:

Apps that are using these columns from ContactsContract.Data can extract them from ContactsContract.RawContacts instead, by joining with RAW_CONTACT_ID.

Strikte SQL-Prüfungen in CP2 erzwingen

Bei Apps, die auf Android 17 (API-Level 37) und höher ausgerichtet sind, erzwingt Contacts Provider 2 (CP2) eine strenge SQL-Abfragevalidierung, wenn ohne die Berechtigung READ_CONTACTS auf die Tabelle ContactsContract.Data zugegriffen wird.

Wenn eine App nicht die Berechtigung READ_CONTACTS hat, werden mit dieser Änderung beim Abfragen der Tabelle ContactsContract.Data die Optionen StrictColumns und StrictGrammar festgelegt. Wenn eine Abfrage ein Muster verwendet, das nicht mit diesen kompatibel ist, wird sie abgelehnt und es wird eine Ausnahme ausgelöst.

Intelligenz

Android 17 enthält die folgenden Änderungen an der System-KI.

Einstellung von setContentCaptureEnabled

Die Funktion „Inhalte erfassen“ ist auf bestimmten Geräten standardmäßig aktiviert, damit On-Device-KI-Funktionen Bildschirminhalte für intelligente Funktionen analysieren können.

Ab Android 17 ist die API-Methode ContentCaptureManager.setContentCaptureEnabled(boolean) veraltet. Bei Apps, die auf Android 17 (API‑Level 37) oder höher ausgerichtet sind, wird die Inhaltserfassung durch den Aufruf von setContentCaptureEnabled(false) nicht mehr deaktiviert.

Wenn Ihre App weiterhin die Aufnahme von Inhalten deaktivieren oder verhindern muss, dass Bildschirm-Inhalte vom System aufgenommen werden, müssen Sie zum Fensterlayout-Parameter FLAG_SECURE wechseln.

Wenn Sie die Inhaltserfassung deaktivieren möchten, legen Sie das Flag FLAG_SECURE für Ihr Fenster fest, wie im folgenden Beispiel gezeigt:

Kotlin

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

Java

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

Weitere Informationen finden Sie in der Referenzdokumentation zu WindowManager.LayoutParams.FLAG_SECURE.

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.

Für alle Apps gelten bestimmte Audioeinschränkungen. Die Einschränkungen sind jedoch strenger, wenn eine App auf Android 17 (API‑Level 37) ausgerichtet ist. Wenn eine dieser Apps im Hintergrund mit Audio interagiert, muss ein Dienst im Vordergrund ausgeführt werden. Außerdem muss die App eine oder beide der folgenden Anforderungen erfüllen:

  • Der Dienst im Vordergrund muss die Berechtigung „Während der Nutzung“ haben.
  • Die App muss die Berechtigung exact alarm haben und mit USAGE_ALARM-Audiostreams interagieren.

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

Formfaktoren von Geräten

Android 17 enthält die folgenden Änderungen, um die Nutzerfreundlichkeit auf einer Reihe von Gerätegrößen und ‑formfaktoren zu verbessern.

Plattform-API-Änderungen zum Ignorieren von Einschränkungen für Ausrichtung, Größenänderung und Seitenverhältnis auf großen Displays (sw>=600dp)

In Android 16 haben wir Änderungen an der Plattform-API eingeführt, um Einschränkungen für Ausrichtung, Seitenverhältnis und Größenänderung auf großen Displays (sw >= 600 dp) zu ignorieren für Apps, die auf API-Level 36 oder höher ausgerichtet sind. Entwickler haben die Möglichkeit, diese Änderungen mit SDK 36 zu deaktivieren. Diese Deaktivierung ist jedoch nicht mehr für Apps verfügbar, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind.

Weitere Informationen finden Sie unter Einschränkungen für Ausrichtung und Größenänderung werden ignoriert.

Konnektivität

In Android 17 wird die folgende Änderung eingeführt, um die Konsistenz zu verbessern und das Verhalten von Bluetooth-RFCOMM-Sockets an das Standardverhalten von Java InputStream anzupassen.

Einheitliches BluetoothSocket-read()-Verhalten für RFCOMM

For apps targeting Android 17 (API level 37), the read() method of the InputStream obtained from an RFCOMM-based BluetoothSocket now returns -1 when the socket is closed or the connection is dropped.

This change makes RFCOMM socket behavior consistent with LE CoC sockets and aligns with the standard InputStream.read() documentation, which states that -1 is returned when the end of the stream is reached.

Apps that rely solely on catching an IOException to break out of a read loop may be impacted by this change and should update the BluetoothSocket read loops to explicitly check for a return value of -1. This ensures the loop terminates correctly when the remote device disconnects or the socket is closed. For an example of the recommended implementation, see the code snippet in the Transfer Bluetooth data guide.