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

Wie frühere Versionen enthält auch 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.

Seht euch auch die Liste der Verhaltensänderungen an, die sich auf alle Apps auswirken, die unter Android 17 ausgeführt werden, unabhängig von der targetSdkVersion eurer App.

Nutzererfahrung und System-UI

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

Widget für Arbeitsspeicherlimit

Ab Android 17 wird für Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind, ein striktes Speicherlimit (1,5 * Bildschirmbreite * Bildschirmhöhe * 4) für die kombinierte Arbeitsspeichernutzung von Bitmaps und Symbolen im RemoteViews-Paket erzwungen. Wenn diese Limits überschritten werden, wird ein schwerwiegender IllegalArgumentException-Fehler ausgegeben und der Prozess der App stürzt ab.

Weitere Informationen finden Sie unter UpdateAppWidget.

Hauptfunktion

Android 17 enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems ändern 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 sperrfreie Implementierung von android.os.MessageQueue. Die neue Implementierung verbessert die Leistung und reduziert verpasste Frames, kann aber Clients beeinträchtigen, die private Felder und Methoden von MessageQueue reflektieren.

Weitere Informationen, einschließlich Strategien zur Risikominderung, finden Sie im Leitfaden zu Verhaltensänderungen bei MessageQueue.

Statische finale Felder können jetzt 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 Reflexion zu ändern, wird ein IllegalAccessException ausgelöst. Wenn Sie versuchen, eines dieser Felder über JNI APIs (z. B. SetStaticLongField()) zu ändern, stürzt die App ab.

Bedienungshilfen

Android 17 enthält die folgenden Änderungen zur Verbesserung der Barrierefreiheit.

Unterstützung von Bedienungshilfen für die Eingabe über komplexe physische IME-Tastaturen

Mit dieser Funktion werden die neuen APIs AccessibilityEvent und TextAttribute eingeführt, um das gesprochene Feedback von Screenreadern für die Eingabe in CJKV-Sprachen zu verbessern. CJKV-IME-Apps können jetzt signalisieren, ob während der Texteingabe ein Kandidat für die Textkonvertierung ausgewählt wurde. Apps mit Bearbeitungsfeldern können Arten von Textänderungen angeben, wenn sie Bedienungshilfen-Ereignisse für Textänderungen senden. Apps können beispielsweise angeben, dass eine Textänderung während der Texteingabe oder durch einen Commit erfolgt ist. Dadurch können Bedienungshilfen wie Screenreader präziseres Feedback basierend auf der Art der Textänderung geben.

App-Akzeptanz

  • IME-Apps: Wenn du Text in Bearbeitungsfeldern festlegst, können IMEs mit TextAttribute.Builder.setTextSuggestionSelected() angeben, ob ein bestimmter Konvertierungskandidat ausgewählt wurde.

  • Apps mit Bearbeitungsfeldern:Apps, die ein benutzerdefiniertes InputConnection verwalten, können Daten zur Kandidatenauswahl durch Aufrufen von TextAttribute.isTextSuggestionSelected() abrufen. Diese Apps sollten dann AccessibilityEvent.setTextChangeTypes() aufrufen, wenn TYPE_VIEW_TEXT_CHANGED-Ereignisse gesendet werden. Bei Apps, die auf Android 17 (API-Level 37) ausgerichtet sind und die Standard-TextView verwenden, ist diese Funktion standardmäßig aktiviert. Das heißt, TextView übernimmt das Abrufen von Daten aus der Eingabemethode und das Festlegen von Textänderungstypen, wenn Ereignisse an Bedienungshilfen gesendet werden.

  • Bedienungshilfen:Bedienungshilfen, die TYPE_VIEW_TEXT_CHANGED-Ereignisse verarbeiten, können AccessibilityEvent.getTextChangeTypes() aufrufen, um die Art der Änderung zu ermitteln und ihre Feedbackstrategien entsprechend anzupassen.

Datenschutz

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

ECH (Encrypted Client Hello) aktiviert

Android 17 bietet Plattformunterstützung für Encrypted Client Hello (ECH), eine TLS-Erweiterung, die den Datenschutz für Nutzer verbessert, indem die Server Name Indication (SNI) im TLS-Handshake verschlüsselt wird. Diese Verschlüsselung trägt dazu bei, dass Netzwerkbeobachter die spezifische Domain, mit der sich Ihre App verbindet, nicht so leicht identifizieren können.

Bei Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind, wird ECH für TLS-Verbindungen verwendet. ECH ist nur aktiv, wenn die von der App verwendete Netzwerkbibliothek (z. B. HttpEngine, WebView oder OkHttp) integrierte ECH-Unterstützung bietet und der Remote-Server das ECH-Protokoll ebenfalls unterstützt. Wenn ECH nicht ausgehandelt werden kann, sendet der Client eine ECH-Erweiterung mit zufälligen Inhalten (ein Mechanismus namens ECH GREASE). Weitere Informationen zur Funktionsweise von ECH GREASE finden Sie im RFC 9849.

Damit Apps dieses Verhalten anpassen können, wird in Android 17 ein neues <domainEncryption>-Element zur Datei für die Netzwerksicherheitskonfiguration hinzugefügt. Entwickler können <domainEncryption> innerhalb von <base-config>- oder <domain-config>-Tags verwenden, um einen ECH-Modus (z. B. "enabled" oder "disabled") global oder pro Domain auszuwählen.

Weitere Informationen finden Sie in der Dokumentation zu Encrypted Client Hello.

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

Mit Android 17 wird die Laufzeitberechtigung ACCESS_LOCAL_NETWORK eingeführt, um Nutzer vor unbefugtem Zugriff auf das lokale Netzwerk zu schützen. Da dies unter die bestehende Berechtigungsgruppe NEARBY_DEVICES fällt, werden Nutzer, die bereits andere NEARBY_DEVICES-Berechtigungen gewährt haben, nicht noch einmal dazu aufgefordert. Diese neue Anforderung verhindert, dass schädliche Apps den uneingeschränkten Zugriff auf das lokale Netzwerk für verdecktes Nutzertracking und Fingerprinting ausnutzen. Wenn Sie diese Berechtigung deklarieren und anfordern, kann Ihre App Geräte im Local Area Network (LAN) wie Smart-Home-Geräte oder Streamingempfänger finden und sich mit ihnen verbinden.

Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind, haben jetzt zwei Möglichkeiten, die Kommunikation mit LAN-Geräten aufrechtzuerhalten: Sie können systemgesteuerte, datenschutzfreundliche Geräteauswahlfunktionen verwenden, um die Berechtigungsaufforderung zu überspringen, oder diese neue Berechtigung explizit zur Laufzeit anfordern, um die Kommunikation im lokalen Netzwerk aufrechtzuerhalten.

Weitere Informationen findest du in der Dokumentation zur Berechtigung für das lokale Netzwerk.

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 mit dieser Einstellung alle Passwortzeichen ausgeblendet.

Das Android-System zeigt das zuletzt eingegebene Passwortzeichen an, damit der Nutzer sehen kann, ob er sich vertippt 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 show_passwords_touch-Einstellung 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, die ein OTP enthalten und nicht die Formate WebOTP oder SMS Retriever 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 Hijacking von OTPs zu verhindern. 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.

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 bietet die folgenden Verbesserungen für die Geräte- und App-Sicherheit.

Aktivitätssicherheit

In Android 17 wird die Plattform weiter in Richtung einer standardmäßig sicheren Architektur entwickelt. Es werden eine Reihe von Verbesserungen eingeführt, die darauf abzielen, schwerwiegende Exploits wie Phishing, Interaction Hijacking und Confused-Deputy-Angriffe abzuwehren. Entwickler müssen die neuen Sicherheitsstandards explizit akzeptieren, damit ihre Apps kompatibel bleiben und Nutzer geschützt sind.

Wichtige Auswirkungen für Entwickler:

  • BAL-Härtung und verbessertes Opt-in: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 ersetzen. Stattdessen sollten Sie detaillierte Steuerelemente wie MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE verwenden, die das Starten von Aktivitäten auf Szenarien beschränken, in denen die aufrufende App sichtbar ist. Dadurch wird die Angriffsfläche erheblich reduziert.
  • Tools zur Einführung:Entwickler sollten den strikten Modus und aktualisierte Lint-Prüfungen verwenden, um veraltete Muster zu identifizieren und die Bereitschaft für zukünftige Anforderungen an die Ziel-SDK-Version sicherzustellen.

CT standardmäßig aktivieren

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

Sicherere native DCL – C

Wenn Ihre App auf Android 17 (API-Level 37) oder höher ausgerichtet ist, wird der in Android 14 eingeführte Schutz für das sicherere dynamische Laden von Code (Dynamic Code Loading, DCL) für DEX- und JAR-Dateien jetzt auf native Bibliotheken ausgeweitet.

Alle nativen Dateien, die mit System.load() geladen werden, müssen als schreibgeschützt gekennzeichnet sein. Andernfalls wird UnsatisfiedLinkError ausgegeben.

Wir empfehlen, das dynamische Laden von Code in Apps nach Möglichkeit zu vermeiden, da dies das Risiko, dass eine App durch Code-Injection oder Code-Manipulation manipuliert wird, erheblich erhöht.

Personenidentifizierbare Informationen in der CP2-Datenansicht einschränken

Bei Apps, die auf Android 17 (API-Level 37) und höher ausgerichtet sind, schränkt Contacts Provider 2 (CP2) bestimmte Spalten mit personenidentifizierbaren Informationen in der Datenansicht ein. Wenn diese Änderung aktiviert ist, werden diese Spalten aus der Datenansicht entfernt, um den Datenschutz für Nutzer zu verbessern. Zu den eingeschränkten Spalten gehören:

Apps, die diese Spalten aus ContactsContract.Data verwenden, können sie stattdessen aus ContactsContract.RawContacts extrahieren, indem sie mit RAW_CONTACT_ID verknüpft werden.

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 auf die Tabelle ContactsContract.Data ohne die Berechtigung READ_CONTACTS zugegriffen wird.

Wenn eine App nicht die Berechtigung READ_CONTACTS hat, werden die Optionen StrictColumns und StrictGrammar festgelegt, wenn die Tabelle ContactsContract.Data abgefragt wird. Wenn eine Abfrage ein Muster verwendet, das nicht mit diesen kompatibel ist, wird sie abgelehnt und eine Ausnahme ausgelöst.

Intelligenz

Android 17 enthält die folgenden Änderungen an der Systemintelligenz.

Einstellung von setContentCaptureEnabled

Die Inhaltserfassung ist auf bestimmten Geräten standardmäßig aktiviert, damit KI-Funktionen auf dem Gerät Bildschirminhalte analysieren und intelligente Funktionen bereitstellen können.

Ab Android 17 wird die API-Methode ContentCaptureManager.setContentCaptureEnabled(boolean) nicht mehr unterstützt. 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 in Ihrer App die Inhaltserfassung weiterhin deaktiviert sein soll oder die Erfassung von Bildschirminhalten durch das System eingeschränkt werden soll, müssen Sie auf den Fensterlayoutparameter FLAG_SECURE umstellen.

Wenn Sie die Inhaltserfassung deaktivieren möchten, setzen Sie das Flag FLAG_SECURE für Ihr Fenster, 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 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.

Einige Audioeinschränkungen gelten für alle Apps. Die Einschränkungen sind jedoch strenger, wenn eine App auf Android 17 (API-Level 37) ausgerichtet ist. Wenn eine dieser Apps mit Audio interagiert, während sie im Hintergrund ausgeführt wird, 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 über WIU-Funktionen (While-In-Use) verfügen.
  • Die App muss die Berechtigung exakter Alarm haben und mit USAGE_ALARM-Audiostreams interagieren.

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

Geräteformfaktoren

Android 17 enthält die folgenden Änderungen, um die Nutzerfreundlichkeit auf verschiedenen Gerätegrößen und Formfaktoren zu verbessern.

Änderungen an der Plattform-API, um Einschränkungen für die Ausrichtung, Größenänderung und das Seitenverhältnis auf großen Displays (sw>=600dp) zu ignorieren

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

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

Verbindung

Android 17 führt die folgende Änderung ein, um die Konsistenz zu verbessern und das Verhalten von Bluetooth-RFCOMM-Sockets an das Standard-Java-InputStream-Verhalten anzupassen.

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

Bei Apps, die auf Android 17 (API-Level 37) ausgerichtet sind, gibt die Methode read() des InputStream, der von einem RFCOMM-basierten BluetoothSocket stammt, jetzt -1 zurück, wenn der Socket geschlossen oder die Verbindung getrennt wird.

Durch diese Änderung wird das Verhalten von RFCOMM-Sockets an das von LE-CoC-Sockets angepasst und entspricht der Standarddokumentation für InputStream.read(), in der angegeben ist, dass -1 zurückgegeben wird, wenn das Ende des Streams erreicht ist.

Apps, die sich ausschließlich darauf verlassen, dass eine IOException abgefangen wird, um eine Leseschleife zu beenden, können von dieser Änderung betroffen sein. Sie sollten die BluetoothSocket-Leseschleifen aktualisieren, um explizit nach einem Rückgabewert von -1 zu suchen. So wird sichergestellt, dass die Schleife korrekt beendet wird, wenn die Verbindung zum Remote-Gerät getrennt oder der Socket geschlossen wird. Ein Beispiel für die empfohlene Implementierung finden Sie im Code-Snippet im Leitfaden Bluetooth-Daten übertragen.