Verhaltensänderungen: alle Apps

Mit Android 9 (API-Level 28) werden einige Änderungen am Android-System eingeführt. Die folgenden Verhaltensänderungen gelten für alle Apps, die auf der Android 9-Plattform ausgeführt werden, unabhängig von der API-Ebene, auf die sie ausgerichtet sind. Alle Entwickler sollten diese Änderungen prüfen und ihre Apps entsprechend anpassen, sofern dies für die App zutrifft.

Informationen zu Änderungen, die nur Apps betreffen, die auf API-Ebene 28 oder höher ausgerichtet sind, finden Sie unter Verhaltensänderungen: Apps, die auf API-Ebene 28 oder höher ausgerichtet sind.

Energiespareinstellungen

Android 9 bietet neue Funktionen zur Verbesserung des Energiemanagements von Geräten. Diese Änderungen sowie Funktionen, die bereits vor Android 9 vorhanden waren, tragen dazu bei, dass Systemressourcen den Apps zur Verfügung gestellt werden, die sie am dringendsten benötigen.

Weitere Informationen finden Sie unter Energieverwaltung.

Änderungen beim Datenschutz

Um den Datenschutz für Nutzer zu verbessern, werden in Android 9 mehrere Verhaltensänderungen eingeführt. Dazu gehören die Einschränkung des Zugriffs von Apps im Hintergrund auf Gerätesensoren, die Einschränkung der aus WLAN-Scans abgerufenen Informationen sowie neue Berechtigungsregeln und Berechtigungsgruppen für Anrufe, den Smartphone-Status und WLAN-Scans.

Diese Änderungen wirken sich auf alle Apps aus, die auf Android 9 ausgeführt werden, unabhängig von der Ziel-SDK-Version.

Eingeschränkter Zugriff auf Sensoren im Hintergrund

Unter Android 9 ist der Zugriff von Apps im Hintergrund auf Nutzereingaben und Sensordaten eingeschränkt. Wenn Ihre App auf einem Gerät mit Android 9 im Hintergrund ausgeführt wird, gelten für sie die folgenden Einschränkungen:

  • Ihre App kann nicht auf das Mikrofon oder die Kamera zugreifen.
  • Sensoren, die den kontinuierlichen Berichtsmodus verwenden, z. B. Beschleunigungsmesser und Gyroskope, erhalten keine Ereignisse.
  • Für Sensoren, die die Berichtsmodi bei Änderung oder Einzelmessung verwenden, werden keine Ereignisse empfangen.

Wenn Ihre App Sensorereignisse auf Geräten mit Android 9 erkennen muss, verwenden Sie einen Dienst im Vordergrund.

Eingeschränkter Zugriff auf Anruflisten

In Android 9 wird die Berechtigungsgruppe CALL_LOG eingeführt und die Berechtigungen READ_CALL_LOG, WRITE_CALL_LOG und PROCESS_OUTGOING_CALLS werden in diese Gruppe verschoben. In früheren Android-Versionen waren diese Berechtigungen in der Berechtigungsgruppe PHONE zu finden.

Mit dieser CALL_LOG-Berechtigungsgruppe erhalten Nutzer mehr Kontrolle und Transparenz bei Apps, die auf vertrauliche Informationen zu Anrufen zugreifen müssen, z. B. zum Lesen von Anruflisten und zum Identifizieren von Telefonnummern.

Wenn Ihre App Zugriff auf Anruflisten benötigt oder ausgehende Anrufe verarbeiten muss, müssen Sie diese Berechtigungen explizit aus der Berechtigungsgruppe CALL_LOG anfordern. Andernfalls tritt ein SecurityException auf.

Hinweis : Da diese Berechtigungen die Gruppe geändert haben und zur Laufzeit gewährt werden, kann der Nutzer Ihrer App den Zugriff auf Informationen in Anruflisten verweigern. In diesem Fall sollte Ihre App den fehlenden Zugriff auf Informationen problemlos verarbeiten können.

Wenn Ihre App bereits den Best Practices für Berechtigungen zur Laufzeit entspricht, kann sie die Änderung der Berechtigungsgruppe verarbeiten.

Eingeschränkter Zugriff auf Telefonnummern

Apps, die unter Android 9 ausgeführt werden, können Telefonnummern oder den Gerätestatus nur lesen, wenn sie zusätzlich zu den anderen Berechtigungen, die für die Anwendungsfälle Ihrer App erforderlich sind, die Berechtigung READ_CALL_LOG haben.

Telefonnummern, die mit eingehenden und ausgehenden Anrufen verknüpft sind, sind im Broadcast zum Telefonstatus zu sehen, z. B. für eingehende und ausgehende Anrufe. Sie sind über die Klasse PhoneStateListener zugänglich. Ohne die Berechtigung READ_CALL_LOG ist das Feld für die Telefonnummer, das in PHONE_STATE_CHANGED-Streams und über PhoneStateListener angegeben wird, jedoch leer.

Wenn Sie Telefonnummern aus dem Smartphone-Status lesen möchten, aktualisieren Sie Ihre App, um die erforderlichen Berechtigungen für Ihren Anwendungsfall anzufordern:

Eingeschränkter Zugriff auf WLAN-Standort- und Verbindungsinformationen

Unter Android 9 sind die Berechtigungsanforderungen für Apps, die WLAN-Scans ausführen, strenger als in früheren Versionen. Weitere Informationen finden Sie unter Einschränkungen für WLAN-Scans.

Ähnliche Einschränkungen gelten auch für die Methode getConnectionInfo(), die ein WifiInfo-Objekt zurückgibt, das die aktuelle WLAN-Verbindung beschreibt. Sie können die Methoden dieses Objekts nur zum Abrufen von SSID- und BSSID-Werten verwenden, wenn die aufrufende App die folgenden Berechtigungen hat:

  • ACCESS_FINE_LOCATION oder ACCESS_COARSE_LOCATION
  • ACCESS_WIFI_STATE

Zum Abrufen der SSID oder BSSID müssen außerdem die Standortdienste auf dem Gerät aktiviert sein (unter Einstellungen > Standort).

Aus WLAN-Dienstmethoden entfernte Informationen

Unter Android 9 werden für die folgenden Ereignisse und Übertragungen keine Informationen zum Standort des Nutzers oder personenidentifizierbare Daten empfangen:

Der NETWORK_STATE_CHANGED_ACTION-System-Broadcast über WLAN enthält keine SSID (früher EXTRA_SSID), BSSID (früher EXTRA_BSSID) oder Verbindungsinformationen (früher EXTRA_NETWORK_INFO) mehr. Wenn Ihre App diese Informationen benötigt, rufen Sie stattdessen getConnectionInfo() auf.

Telefonieinformationen basieren jetzt auf den Gerätestandorteinstellungen

Wenn der Nutzer die Geräteortung auf einem Gerät mit Android 9 deaktiviert hat, liefern die folgenden Methoden keine Ergebnisse:

Einschränkungen bei der Verwendung von Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität von Apps zu gewährleisten, schränkt die Plattform die Verwendung einiger nicht SDK-Methoden und ‑Felder ein. Diese Einschränkungen gelten unabhängig davon, ob Sie versuchen, direkt, über Reflection oder mit JNI auf diese Methoden und Felder zuzugreifen. Unter Android 9 kann Ihre App weiterhin auf diese eingeschränkten Oberflächen zugreifen. Die Plattform verwendet Toast-Nachrichten und Protokolleinträge, um Sie darauf aufmerksam zu machen. Wenn Ihre App eine solche Benachrichtigung anzeigt, ist es wichtig, dass Sie eine andere Implementierungsstrategie als die eingeschränkte Benutzeroberfläche verfolgen. Wenn Sie der Meinung sind, dass keine alternative Strategie möglich ist, können Sie einen Fehler melden, um eine Neubewertung der Einschränkung zu beantragen.

Weitere wichtige Informationen finden Sie unter Einschränkungen für Nicht-SDK-Schnittstellen. Sie sollten prüfen, ob Ihre App weiterhin ordnungsgemäß funktioniert.

Änderungen am Sicherheitsverhalten

Änderungen bei der Gerätesicherheit

Android 9 bietet mehrere Funktionen, die die Sicherheit Ihrer App verbessern, unabhängig davon, auf welche Version Ihre App ausgerichtet ist.

Änderungen bei der TLS-Implementierung

Die TLS-Implementierung des Systems wurde in Android 9 in mehreren Punkten geändert:

  • Wenn bei der Erstellung einer Instanz von SSLSocket keine Verbindung hergestellt werden kann, gibt das System eine IOException anstelle einer NullPointerException zurück.
  • Die Klasse SSLEngine verarbeitet alle auftretenden close_notify-Benachrichtigungen ordnungsgemäß.

Weitere Informationen zum Senden sicherer Webanfragen in einer Android-App finden Sie unter Ein HTTPS-Beispiel.

Striger SECCOMP-Filter

Unter Android 9 sind noch weniger Systemaufrufe für Apps verfügbar. Dieses Verhalten ist eine Erweiterung des SECCOMP-Filters, der in Android 8.0 (API-Ebene 26) enthalten ist.

Kryptografische Änderungen

Android 9 führt mehrere Änderungen an der Implementierung und Verarbeitung kryptografischer Algorithmen ein.

Conscrypt-Implementierungen von Parametern und Algorithmen

Android 9 bietet zusätzliche Implementierungen von Algorithmusparametern in Conscrypt. Zu diesen Parametern gehören AES, DESEDE, OAEP und EC. Die Bouncy Castle-Versionen dieser Parameter und vieler Algorithmen wurden ab Android 9 eingestellt.

Wenn Ihre App auf Android 8.1 (API-Level 27) oder niedriger ausgerichtet ist, erhalten Sie eine Warnung, wenn Sie die Bouncy Castle-Implementierung eines dieser eingestellten Algorithmen anfordern. Wenn Sie jedoch Android 9 als Ziel verwenden, wird bei diesen Anfragen jeweils NoSuchAlgorithmException geworfen.

Sonstige Änderungen

Android 9 führt mehrere weitere Änderungen im Zusammenhang mit Kryptografie ein:

  • Wenn bei der Verwendung von PBE-Schlüsseln Bouncy Castle einen Initialisierungsvektor (IV) erwartet und Ihre App keinen bereitstellt, erhalten Sie eine Warnung.
  • Mit der Conscrypt-Implementierung der ARC4-Chiffre können Sie entweder ARC4/ECB/NoPadding oder ARC4/NONE/NoPadding angeben.
  • Der Crypto Java Cryptography Architecture (JCA)-Anbieter wurde entfernt. Wenn Ihre App also SecureRandom.getInstance("SHA1PRNG", "Crypto") aufruft, wird NoSuchProviderException ausgegeben.
  • Wenn Ihre App RSA-Schlüssel aus Puffern analysiert, die größer als die Schlüsselstruktur sind, tritt keine Ausnahme mehr auf.

Weitere Informationen zur Verwendung der kryptografischen Funktionen von Android finden Sie unter Kryptografie.

Sicher verschlüsselte Dateien unter Android werden nicht mehr unterstützt

Unter Android 9 wird die Unterstützung für Android Secure Encrypted Files (ASECs) vollständig entfernt.

Mit Android 2.2 (API-Level 8) wurden ASECs eingeführt, um die Funktion „Apps auf SD-Karte“ zu unterstützen. Mit Android 6.0 (API-Level 23) wurde die Technologie Adaptive Storage Device eingeführt, die Entwickler anstelle von ASECs verwenden können.

Updates für die ICU-Bibliotheken

Unter Android 9 wird Version 60 der ICU-Bibliothek verwendet. Android 8.0 (API-Level 26) und Android 8.1 (API-Level 27) verwenden ICU 58.

ICU wird verwendet, um öffentliche APIs unter der android.icu package bereitzustellen, und wird intern auf der Android-Plattform für die Unterstützung der Internationalisierung verwendet. Sie wird beispielsweise verwendet, um Android-Klassen in java.util, java.text und android.text.format zu implementieren.

Das Update auf ICU 60 enthält viele kleine, aber nützliche Änderungen, darunter die Unterstützung von Emoji 5.0-Daten und verbesserte Datums-/Zeitformate, wie in den Release Notes zu ICU 59 und ICU 60 beschrieben.

Wichtige Änderungen in diesem Update:

  • Die Plattform verarbeitet Zeitzonen jetzt anders.
    • Die Plattform verarbeitet GMT und UTC besser. UTC ist nicht mehr mit GMT identisch.

      ICU bietet jetzt übersetzte Zonennamen für GMT und UTC. Diese Änderung wirkt sich auf das Formatieren und Parsen von android.icu in Zeitzonen wie „GMT“, „Etc/GMT“, „UTC“, „Etc/UTC“ und „Zulu“ aus.

    • java.text.SimpleDateFormat verwendet jetzt ICU, um Anzeigenamen für UTC /GMT anzugeben. Das bedeutet:
      • Wenn Sie zzzz formatieren, wird für viele Sprachen ein langer lokalisierter String generiert. Bisher wurde „UTC“ für UTC und Strings wie „GMT+00:00“ für GMT ausgegeben.
      • Beim Parsen von zzzz werden Strings wie „Universal Coordinated Time“ und „Greenwich Mean Time“ erkannt.
      • In Apps können Kompatibilitätsprobleme auftreten, wenn davon ausgegangen wird, dass „UTC“ oder „GMT+00:00“ in allen Sprachen für zzzz ausgegeben wird.
    • Das Verhalten von java.text.DateFormatSymbols.getZoneStrings() hat sich geändert:
      • Wie bei SimpleDateFormat haben jetzt auch UTC und GMT lange Namen. Sommerzeitvarianten von Zeitzonennamen für die UTC-Zone, z. B. „UTC“, „Etc/UTC“ und „Zulu“, werden in GMT+00:00 umgewandelt. Dies ist der Standard-Fallback, wenn keine Namen verfügbar sind, und nicht der hartcodierte String UTC.
      • Einige Zonen-IDs werden jetzt korrekt als Synonyme für andere Zonen erkannt. So findet Android Strings für veraltete Zonen-IDs wie Eire, die zuvor nicht aufgelöst werden konnten.
    • „Asien/Hanoi“ ist keine Zone mehr. Aus diesem Grund gibt java.util.TimeZones.getAvailableIds() diesen Wert nicht zurück und java.util.TimeZone.getTimeZone() erkennt ihn nicht. Dieses Verhalten entspricht dem bestehenden android.icu-Verhalten.
  • Die Methode android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) kann auch dann eine ParseException zurückgeben, wenn legitimer Währungstext geparst wird. Sie können dieses Problem vermeiden, indem Sie für Währungstext im PLURALCURRENCYSTYLE-Format NumberFormat.parseCurrency verwenden, das seit Android 7.0 (API-Ebene 24) verfügbar ist.

Änderungen bei Android-Tests

Mit Android 9 werden mehrere Änderungen an der Bibliothek und Klassenstruktur des Android Test Frameworks eingeführt. Diese Änderungen erleichtern Entwicklern die Verwendung von framework-unterstützten öffentlichen APIs. Sie ermöglichen aber auch mehr Flexibilität beim Erstellen und Ausführen von Tests mit Drittanbieterbibliotheken oder benutzerdefinierter Logik.

Aus dem Framework entfernte Bibliotheken

In Android 9 werden die JUnit-basierten Klassen in drei Bibliotheken neu angeordnet: android.test.base, android.test.runner und android.test.mock. Dadurch können Sie Tests mit einer Version von JUnit ausführen, die am besten mit den Abhängigkeiten Ihres Projekts funktioniert. Diese Version von JUnit kann sich von der von android.jar bereitgestellten Version unterscheiden.

Weitere Informationen dazu, wie die JUnit-basierten Klassen in diesen Bibliotheken organisiert sind und wie Sie das Projekt Ihrer App zum Schreiben und Ausführen von Tests vorbereiten, finden Sie unter Projekt für Android-Tests einrichten.

Änderungen am Build der Testsuite

Die Methode addRequirements() in der Klasse TestSuiteBuilder wurde entfernt und die Klasse TestSuiteBuilder wurde eingestellt. Bei der addRequirements()-Methode mussten Entwickler Argumente angeben, deren Typen versteckte APIs sind, was die API ungültig macht.

Java UTF-Decoder

UTF-8 ist der Standardzeichensatz unter Android. Eine UTF-8-Byte-Sequenz kann mit einem String-Konstruktor decodiert werden, z. B. String(byte[] bytes).

Der UTF-8-Decodierer in Android 9 folgt den Unicode-Standards strenger als in früheren Versionen. Die Änderungen umfassen Folgendes:

  • Die nicht kürzeste Form von UTF-8, z. B. <C0, AF>, wird als fehlerhaft behandelt.
  • Die Ersatzform von UTF-8, z. B. U+D800..U+DFFF, wird als fehlerhaft behandelt.
  • Der maximale Teil wird durch ein einzelnes U+FFFD ersetzt. In der Bytefolge „41 C0 AF 41 F4 80 80 41“ sind beispielsweise „C0“, „AF“ und „F4 80 80“ die maximalen Teilbereiche. „F4 80 80“ kann die Anfangsunterfolge von „F4 80 80 80“ sein, „C0“ kann jedoch nicht die Anfangsunterfolge einer korrekt formatierten Codeeinheitssequenz sein. Die Ausgabe sollte also „A\ufffd\ufffdA\ufffdA“ lauten.
  • Verwenden Sie die Methode DataInputStream.readUTF() oder die JNI-Methode NewStringUTF(), um eine modifizierte UTF-8-/CESU-8-Sequenz in Android 9 oder höher zu decodieren.

Hostnamenüberprüfung mit einem Zertifikat

RFC 2818 beschreibt zwei Methoden zum Abgleichen eines Domainnamens mit einem Zertifikat: die Verwendung der verfügbaren Namen in der Erweiterung subjectAltName (SAN) oder, falls keine SAN-Erweiterung vorhanden ist, die Rückfallebene auf commonName (CN).

Der Rückfall auf die CN wurde jedoch in RFC 2818 eingestellt. Aus diesem Grund greift Android nicht mehr auf die CN zurück. Zur Bestätigung eines Hostnamens muss der Server ein Zertifikat mit einer übereinstimmenden SAN vorlegen. Zertifikate, die kein SAN mit dem Hostnamen enthalten, werden nicht mehr als vertrauenswürdig eingestuft.

Netzwerkadressabfragen können Netzwerkverstöße verursachen

Suchanfragen nach Netzwerkadressen, die eine Namensauflösung erfordern, können Netzwerk-E/A umfassen und gelten daher als blockierende Vorgänge. Blockierte Vorgänge im Haupt-Thread können zu Pausen oder Rucklern führen.

Die StrictMode-Klasse ist ein Entwicklungstool, mit dem Entwickler Probleme in ihrem Code erkennen können.

In Android 9 und höher erkennt StrictMode Netzwerkverstöße, die durch Netzwerkadressabfragen verursacht werden, die eine Namensauflösung erfordern.

Sie sollten Ihre Apps nicht mit aktiviertem StrictMode veröffentlichen. Andernfalls kann es bei Ihren Apps zu Ausnahmen kommen, z. B. wenn Sie NetworkOnMainThreadException mit den Methoden detectNetwork() oder detectAll() verwenden, um eine Richtlinie abzurufen, die Netzwerkverstöße erkennt.

Die Auflösung einer numerischen IP-Adresse gilt nicht als Blockierungsvorgang. Die Auflösung numerischer IP-Adressen funktioniert wie in Versionen vor Android 9.

Socket-Tagging

Wenn ein Socket in Plattformversionen niedriger als Android 9 mit der Methode setThreadStatsTag() getaggt wird, wird das Tag entfernt, wenn er über Binder-IPC mit einem ParcelFileDescriptor-Container an einen anderen Prozess gesendet wird.

Unter Android 9 und höher wird das Socket-Tag beibehalten, wenn es über Binder-IPC an einen anderen Prozess gesendet wird. Diese Änderung kann sich auf Statistiken zum Netzwerkverkehr auswirken, z. B. bei Verwendung der queryDetailsForUidTag()-Methode.

Wenn Sie das Verhalten der vorherigen Versionen beibehalten möchten, bei dem ein Tag von einem Socket entfernt wird, der an einen anderen Prozess gesendet wird, können Sie untagSocket() vor dem Senden des Sockets aufrufen.

Gemeldete Anzahl der verfügbaren Byte im Socket

Die available()-Methode gibt 0 zurück, wenn sie nach dem Aufrufen der shutdownInput()-Methode aufgerufen wird.

Detailliertere Berichte zu Netzwerkfunktionen für VPNs

Unter Android 8.1 (API-Ebene 27) und niedriger wurde von der NetworkCapabilities-Klasse nur eine begrenzte Anzahl von Informationen für VPNs erfasst, z. B. TRANSPORT_VPN, aber ohne NET_CAPABILITY_NOT_VPN. Aufgrund dieser begrenzten Informationen war es schwierig zu ermitteln, ob die Nutzung eines VPN für den Nutzer der App kostenpflichtig ist. Wenn Sie beispielsweise NET_CAPABILITY_NOT_METERED prüfen, können Sie nicht feststellen, ob die zugrunde liegenden Netzwerke getaktet sind oder nicht.

Wenn unter Android 9 und höher ein VPN die Methode setUnderlyingNetworks() aufruft, werden die Transport- und Funktionen aller zugrunde liegenden Netzwerke vom Android-System zusammengeführt und das Ergebnis als effektive Netzwerkfunktionen des VPN-Netzwerks zurückgegeben.

Unter Android 9 und höher erhalten Apps, die bereits nach NET_CAPABILITY_NOT_METERED suchen, die Netzwerkfunktionen des VPN und der zugrunde liegenden Netzwerke.

Dateien im Ordner „xt_qtaguid“ sind für Apps nicht mehr verfügbar

Ab Android 9 dürfen Apps keinen direkten Lesezugriff auf Dateien im Ordner /proc/net/xt_qtaguid mehr haben. Das soll für Konsistenz bei einigen Geräten sorgen, auf denen diese Dateien gar nicht vorhanden sind.

Die öffentlichen APIs, die auf diesen Dateien basieren, TrafficStats und NetworkStatsManager, funktionieren weiterhin wie vorgesehen. Die nicht unterstützten cutils-Funktionen wie qtaguid_tagSocket() funktionieren jedoch möglicherweise nicht wie erwartet oder gar nicht auf verschiedenen Geräten.

Die Anforderung für FLAG_ACTIVITY_NEW_TASK wird jetzt erzwungen

Unter Android 9 können Sie eine Aktivität nur dann aus einem nicht aktivitätsbezogenen Kontext starten, wenn Sie das Intent-Flag FLAG_ACTIVITY_NEW_TASK übergeben. Wenn Sie versuchen, eine Aktivität zu starten, ohne dieses Flag zu übergeben, wird die Aktivität nicht gestartet und das System druckt eine Meldung in das Protokoll.

Änderungen an der Bildschirmdrehung

Ab Android 9 gibt es erhebliche Änderungen am Modus für die Porträtdrehung. Unter Android 8.0 (API-Ebene 26) konnten Nutzer über eine Schnelleinstellungskachele oder die Displayeinstellungen zwischen den Modi Automatische Drehung und Hochformat wechseln. Der Porträtmodus wurde in Drehsperre umbenannt und ist aktiv, wenn die automatische Drehung deaktiviert ist. Am Modus für die automatische Drehung hat sich nichts geändert.

Wenn sich das Gerät im Modus „Drehung sperren“ befindet, können Nutzer den Bildschirm auf eine beliebige Drehung sperren, die von der oben sichtbaren Aktivität unterstützt wird. Bei einer Aktivität sollte nicht davon ausgegangen werden, dass sie immer im Hochformat gerendert wird. Wenn die oberste Aktivität im Modus „Automatische Drehung“ in mehreren Drehungen gerendert werden kann, sollten dieselben Optionen auch im Modus „Drehung gesperrt“ verfügbar sein, mit einigen Ausnahmen, die von der screenOrientation-Einstellung der Aktivität abhängen (siehe Tabelle unten).

Bei Aktivitäten, für die eine bestimmte Ausrichtung angefordert wird (z. B. screenOrientation=landscape), wird die Einstellung für die Nutzersperre ignoriert und die Aktivität verhält sich wie unter Android 8.0.

Die Bildschirmausrichtung kann im Android-Manifest auf Aktivitätsebene oder programmatisch mit setRequestedOrientation() festgelegt werden.

Im Modus „Drehung sperren“ wird die Einstellung für die Nutzerdrehung festgelegt, die der WindowManager beim Bearbeiten der Aktivitätsdrehung verwendet. Die Einstellung für die Nutzerrotation kann in den folgenden Fällen geändert werden. Hinweis: Das Gerät neigt dazu, zur natürlichen Drehung zurückzukehren, die für Geräte im Smartphone-Formfaktor normalerweise das Hochformat ist:

  • Wenn der Nutzer einen Drehvorschlag annimmt, wird die Drehungseinstellung auf den Vorschlag umgestellt.
  • Wenn der Nutzer zu einer App wechselt, die im Hochformat angezeigt wird (z. B. Sperrbildschirm oder Launcher), wird die Drehungseinstellung in „Hochformat“ geändert.

In der folgenden Tabelle wird das Drehungsverhalten für die gängigen Bildschirmausrichtungen zusammengefasst:

Displayausrichtung Verhalten
nicht angegeben, Nutzer Bei automatischer Drehung und Drehungssperre kann die Aktivität im Hoch- oder Querformat gerendert werden (und umgekehrt). Sie sollten sowohl das Hoch- als auch das Querformat unterstützen.
userLandscape Bei automatischer Drehung und Drehungssperre kann die Aktivität im Querformat oder im umgekehrten Querformat gerendert werden. Es werden nur Querformate unterstützt.
userPortrait Bei automatischer Drehung und Drehungssperre kann die Aktivität entweder im Hoch- oder im Querformat gerendert werden. Es werden nur Hochformate unterstützt.
fullUser Bei automatischer Drehung und Drehungssperre kann die Aktivität im Hoch- oder Querformat gerendert werden (und umgekehrt). Es wird sowohl das Hoch- als auch das Querformat unterstützt.

Nutzer mit Drehsperre haben die Möglichkeit, das Display auf das umgekehrte Hochformat zu sperren, oft 180 Grad.
sensor, fullSensor, sensorPortrait, sensorLandscape Die Einstellung für den Sperrmodus wird ignoriert und es wird so behandelt, als wäre die automatische Drehung aktiv. Verwenden Sie diese Option nur in Ausnahmefällen und mit großer Sorgfalt im Hinblick auf die UX.

Einstellung des Apache HTTP-Clients wirkt sich auf Apps mit nicht standardmäßigem ClassLoader aus

Mit Android 6.0 haben wir die Unterstützung für den Apache-HTTP-Client entfernt. Diese Änderung hat keine Auswirkungen auf die überwiegende Mehrheit der Apps, die nicht auf Android 9 oder höher ausgerichtet sind. Die Änderung kann sich jedoch auf bestimmte Apps auswirken, die eine nicht standardmäßige ClassLoader-Struktur verwenden, auch wenn die Apps nicht auf Android 9 oder höher ausgerichtet sind.

Eine App kann betroffen sein, wenn sie eine nicht standardmäßige ClassLoader verwendet, die explizit an die System-ClassLoader delegiert. Diese Apps müssen die Suche nach Klassen in org.apache.http.* an die App ClassLoader delegieren. Wenn sie an das System ClassLoader delegieren, schlagen die Apps unter Android 9 oder höher mit einer NoClassDefFoundError fehl, da diese Klassen dem System ClassLoader nicht mehr bekannt sind. Um ähnliche Probleme in Zukunft zu vermeiden, sollten Klassen in Apps im Allgemeinen über die App ClassLoader geladen werden, anstatt direkt auf das System ClassLoader zuzugreifen.

Kameras auflisten

Apps, die auf Android 9-Geräten ausgeführt werden, können alle verfügbaren Kameras finden, indem sie getCameraIdList() aufrufen. Eine App darf nicht davon ausgehen, dass das Gerät nur eine Rückkamera oder nur eine Frontkamera hat.

Wenn Ihre App beispielsweise eine Schaltfläche zum Wechseln zwischen der Front- und Rückkamera hat, kann es sein, dass Sie zwischen mehreren Front- oder Rückkameras wählen können. Sie sollten die Kameraliste durchgehen, die Eigenschaften der einzelnen Kameras prüfen und entscheiden, welche Kameras für den Nutzer sichtbar sein sollen.