Verhaltensänderungen: alle Apps

Mit Android 9 (API-Level 28) werden eine Reihe von Änderungen am Android-System vorgenommen. 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 gegebenenfalls so anpassen, dass sie korrekt unterstützt werden.

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

Energiespareinstellungen

In Android 9 werden neue Funktionen zur Verbesserung des Energieverbrauchs von Geräten eingeführt. Diese Änderungen sowie Funktionen, die bereits vor Android 9 vorhanden waren, tragen dazu bei, dass Systemressourcen für die Apps verfügbar sind, die sie am meisten benötigen.

Weitere Informationen finden Sie unter Energiesparmodus.

Änderungen beim Datenschutz

Um den Datenschutz für Nutzer zu verbessern, wurden in Android 9 verschiedene Verhaltensänderungen eingeführt, z. B. wird der Zugriff von Hintergrund-Apps auf Gerätesensoren eingeschränkt, die aus WLAN-Scans abgerufenen Informationen eingeschränkt und neue Berechtigungsregeln und Berechtigungsgruppen in Bezug auf Telefonanrufe, Telefonstatus und WLAN-Scans zusammengestellt.

Diese Änderungen betreffen alle Apps unter Android 9, unabhängig von der SDK-Zielversion.

Eingeschränkter Zugriff auf Sensoren im Hintergrund

Unter Android 9 wird die Fähigkeit von Hintergrund-Apps eingeschränkt, auf Nutzereingabe- und Sensordaten zuzugreifen. Wenn Ihre App im Hintergrund auf einem Gerät mit Android 9 ausgeführt wird, wendet das System die folgenden Einschränkungen auf Ihre App an:

  • Ihre App kann nicht auf das Mikrofon oder die Kamera zugreifen.
  • Sensoren, die den kontinuierlichen Modus für die Berichterstellung verwenden, z. B. Beschleunigungsmesser und Gyroskope, empfangen keine Ereignisse.
  • Sensoren, die den Berichtsmodus Bei Änderung oder One-Shot verwenden, empfangen keine Ereignisse.

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

Eingeschränkter Zugriff auf Anruflisten

Unter Android 9 wird die Berechtigungsgruppe CALL_LOG eingeführt und die Berechtigungen READ_CALL_LOG, WRITE_CALL_LOG und PROCESS_OUTGOING_CALLS in diese Gruppe verschoben. In früheren Android-Versionen befanden sich diese Berechtigungen in der Berechtigungsgruppe PHONE.

Die Berechtigungsgruppe CALL_LOG bietet Nutzern eine bessere Kontrolle und einen besseren Einblick in Apps, die Zugriff auf vertrauliche Informationen zu Anrufen benötigen. Dazu gehören beispielsweise das Lesen von Anrufaufzeichnungen und die Identifizierung von Telefonnummern.

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

Hinweis : Da sich durch diese Berechtigungen Gruppen geändert haben und diese zur Laufzeit gewährt werden, kann der Nutzer Ihrer App den Zugriff auf Informationen aus Anruflisten verweigern. In diesem Fall sollte Ihre Anwendung in der Lage sein, den Mangel an Zugriff auf Informationen ordnungsgemäß zu bewältigen.

Wenn Ihre App bereits die Best Practices für Laufzeitberechtigungen befolgt, 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 Telefonstatus nicht lesen, ohne zuvor die Berechtigung READ_CALL_LOG zusätzlich zu den anderen Berechtigungen zu erhalten, die für die Anwendungsfälle deiner App erforderlich sind.

Die mit ein- und ausgehenden Anrufen verknüpften Telefonnummern sind in der Sendung des Telefonstatus sichtbar, z. B. für ein- und ausgehende Anrufe, und können über die Klasse PhoneStateListener aufgerufen werden. Ohne die Berechtigung READ_CALL_LOG ist das Telefonnummernfeld in PHONE_STATE_CHANGED-Broadcasts und über PhoneStateListener jedoch leer.

Wenn Sie Telefonnummern aus dem Telefonstatus lesen möchten, aktualisieren Sie Ihre Anwendung, 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 WLAN-Scans einer App strenger als in früheren Versionen. Weitere Informationen finden Sie unter Einschränkungen bei der WLAN-Suche.

Ä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 zum Abrufen von SSID- und BSSID-Werten nur 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).

Informationen aus WLAN-Dienstmethoden entfernt

In Android 9 erhalten die folgenden Ereignisse und Broadcasts keine Informationen zum Standort des Nutzers oder personenidentifizierbare Informationen:

Das NETWORK_STATE_CHANGED_ACTION-System, das aus dem WLAN übertragen wird, enthält keine SSID (früher EXTRA_SSID), BSSID (früher EXTRA_BSSID) oder Verbindungsinformationen (früher EXTRA_NETWORK_INFO). Wenn diese Informationen für Ihre Anwendung erforderlich sind, rufen Sie stattdessen getConnectionInfo() auf.

Telefonieinformationen basieren jetzt auf der Einstellung für den Gerätestandort

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

Einschränkungen für die Verwendung von Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität der App 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 Reflexion oder über JNI auf diese Methoden und Felder zuzugreifen. Unter Android 9 kann Ihre App weiterhin auf diese eingeschränkten Oberflächen zugreifen. Die Plattform verwendet Pop-ups und Logeinträge, um Sie darauf hinzuweisen. Wenn Ihre App einen solchen Toast anzeigt, ist es wichtig, dass Sie eine andere Implementierungsstrategie als die eingeschränkte Schnittstelle verfolgen. Wenn Sie der Meinung sind, dass keine alternative Strategie durchführbar ist, können Sie einen Fehler melden und eine erneute Überprüfung der Einschränkung beantragen.

Unter Einschränkungen für Nicht-SDK-Schnittstellen finden Sie weitere wichtige Informationen. Sie sollten sie überprüfen, um sicherzustellen, dass Ihre App weiterhin ordnungsgemäß funktioniert.

Änderungen des Sicherheitsverhaltens

Änderungen an der Gerätesicherheit

Android 9 bietet verschiedene 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 einige Änderungen vorgenommen:

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

Weitere Informationen zum Stellen sicherer Webanfragen in einer Android-App findest du unter HTTPS-Beispiel.

Strengerer SECCOMP-Filter

Unter Android 9 werden die Systemaufrufe für Apps weiter eingeschränkt. Dieses Verhalten ist eine Erweiterung des SECCOMP-Filters, der unter Android 8.0 (API-Ebene 26) verfügbar ist.

Änderungen in Bezug auf Kryptografie

In Android 9 wurden mehrere Änderungen an der Implementierung und Handhabung von kryptografischen Algorithmen vorgenommen.

Implementierungen von Parametern und Algorithmen durch Conscrypt

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 werden mit Android 9 eingestellt.

Wenn deine App auf Android 8.1 (API-Level 27) oder niedriger ausgerichtet ist, erhältst du eine Warnung, wenn du die Bouncy Castle-Implementierung eines dieser verworfenen Algorithmen anfordert. Wenn die App jedoch auf Android 9 ausgerichtet ist, geben diese Anfragen jeweils einen NoSuchAlgorithmException aus.

Sonstige Änderungen

Android 9 bringt einige weitere Änderungen im Zusammenhang mit Kryptografie mit sich:

  • Wenn Bouncy Castle bei der Verwendung von PBE-Schlüsseln einen Initialisierungsvektor (IV) erwartet, diesen aber nicht 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 Anbieter Crypto Java Cryptography Architecture (JCA) wurde entfernt. Wenn Ihre Anwendung SecureRandom.getInstance("SHA1PRNG", "Crypto") aufruft, wird daher NoSuchProviderException ausgelöst.
  • Wenn Ihre Anwendung RSA-Schlüssel aus Puffern parst, 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.

Mit Android sichere verschlüsselte Dateien nicht mehr unterstützt

Unter Android 9 wird die Unterstützung für Android Secure verschlüsselte Dateien (ASECs) vollständig eingestellt.

In Android 2.2 (API-Level 8) wurden ASECs eingeführt, um Apps auf SD-Karten zu unterstützen. Unter Android 6.0 (API-Level 23) wurde auf der Plattform eine Technologie für akzeptable Speichergeräte eingeführt, die Entwickler anstelle von ASECs verwenden können.

Updates der ICU-Bibliotheken

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

ICU wird verwendet, um öffentliche APIs unter dem android.icu package zur Verfügung zu stellen, und wird intern in der Android-Plattform zur Unterstützung der Internationalisierung verwendet. Es 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, einschließlich der Unterstützung von Emoji 5.0-Daten und verbesserten Datums-/Uhrzeitformaten, wie in den Versionshinweisen zu ICU 59 und ICU 60 dokumentiert.

Wichtige Änderungen in diesem Update:

  • Die Art und Weise, wie die Plattform mit Zeitzonen umgeht, hat sich geändert.
    • GMT und UTC werden auf der Plattform besser verarbeitet, da UTC kein Synonym für GMT mehr ist.

      Die ICU stellt jetzt übersetzte Zonennamen für GMT und UTC bereit. Diese Änderung wirkt sich auf das Formatierungs- und Parsing-Verhalten von android.icu für Zonen wie "GMT", "Etc/GMT", "UTC", "Etc/UTC" und "Zulu" aus.

    • java.text.SimpleDateFormat verwendet jetzt ICU, um Anzeigenamen für UTC /GMT bereitzustellen. Das bedeutet:
      • Wenn Sie zzzz formatieren, wird ein langer lokalisierter String für viele Sprachen generiert. Zuvor 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.
      • Bei Apps können Kompatibilitätsprobleme auftreten, wenn sie davon ausgehen, dass für zzzz in allen Sprachen „UTC“ oder „GMT+00:00“ ausgegeben wird.
    • Das Verhalten von java.text.DateFormatSymbols.getZoneStrings() hat sich geändert:
      • Wie bei SimpleDateFormat haben UTC und GMT jetzt lange Namen. DST-Varianten der Zeitzonennamen für die UTC-Zone, z. B. „UTC“, „Etc/UTC“ und „Zulu“, werden zu GMT+00:00. Dies ist die Standard-Fallback-Version, wenn keine Namen verfügbar sind, anstelle des hartcodierten Strings UTC.
      • Einige Zonen-IDs werden korrekt als Synonyme für andere Zonen erkannt, sodass Android Strings für archaische Zonen-IDs wie Eire findet, die zuvor nicht aufgelöst werden konnten.
    • Asia/Hanoi wird nicht mehr als Zone erkannt. Daher gibt java.util.TimeZones.getAvailableIds() diesen Wert nicht zurück und java.util.TimeZone.getTimeZone() erkennt ihn nicht. Dieses Verhalten entspricht dem bestehenden Verhalten von android.icu.
  • Die Methode android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) kann auch beim Parsen von gültigem Währungstext ein ParseException ausgeben. Du kannst das Problem umgehen, indem du NumberFormat.parseCurrency für Währungstext im PLURALCURRENCYSTYLE-Stil verwendest, der seit Android 7.0 (API-Ebene 24) verfügbar ist.

Änderungen bei Android Test

In Android 9 wurden mehrere Änderungen an der Bibliothek und der Klassenstruktur des Android Test-Frameworks vorgenommen. Diese Änderungen helfen Entwicklern dabei, vom Framework unterstützte öffentliche APIs zu verwenden. Die Änderungen ermöglichen aber auch mehr Flexibilität beim Erstellen und Ausführen von Tests mit Bibliotheken von Drittanbietern oder benutzerdefinierter Logik.

Aus Framework entfernte Bibliotheken

Android 9 organisiert die JUnit-basierten Klassen in drei Bibliotheken: android.test.base, android.test.runner und android.test.mock. Mit dieser Änderung können Sie Tests für eine Version von JUnit ausführen, die am besten mit den Abhängigkeiten Ihres Projekts funktioniert. Diese Version von JUnit unterscheidet sich möglicherweise von der, die android.jar bietet.

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

Test-Suite-Build-Änderungen

Die Methode addRequirements() in der Klasse TestSuiteBuilder wurde entfernt und die Klasse TestSuiteBuilder selbst wurde eingestellt. Entwickler mussten für die Methode addRequirements() Argumente angeben, deren Typen es sich um versteckte APIs handelt. Dadurch war die API ungültig.

Java-UTF-Decoder

UTF-8 ist der Standard-Zeichensatz in Android. Eine UTF-8-Bytesequenz kann von einem String-Konstruktor wie String(byte[] bytes) decodiert werden.

Der UTF-8-Decoder in Android 9 folgt den Unicode-Standards strenger als in früheren Versionen. Folgende Änderungen wurden vorgenommen:

  • Die nicht kürzeste UTF-8-Form, z. B. <C0, AF>, wird als fehlerhaft eingestuft.
  • Die Ersatzform von UTF-8, z. B. U+D800..U+DFFF, wird als fehlerhaft behandelt.
  • Der höchste Teilabschnitt wird durch einen einzelnen U+FFFD ersetzt. In der Bytesequenz „41 C0 AF 41 F4 80 80 41“ sind die höchsten Unterteile beispielsweise „C0“, „AF“ und „F4 80 80“. „F4 80 80“ kann die erste Teilsequenz von „F4 80 80 80“ sein, „C0“ kann jedoch keine anfängliche Teilsequenz einer richtig formatierten Codeeinheitssequenz sein. Daher sollte die Ausgabe „A\ufffd\ufffdA\ufffdA“ sein.
  • Um eine geänderte UTF-8 / CESU-8-Sequenz in Android 9 oder höher zu decodieren, verwenden Sie die Methode DataInputStream.readUTF() oder die JNI-Methode NewStringUTF().

Bestätigung des Hostnamens mithilfe eines Zertifikats

In RFC 2818 werden zwei Methoden beschrieben, um einen Domainnamen mit einem Zertifikat abzugleichen. Dazu werden die verfügbaren Namen in der Erweiterung subjectAltName (SAN) verwendet oder, falls die Erweiterung SAN fehlt, auf commonName (CN).

Das Fallback auf CN wurde jedoch in RFC 2818 eingestellt. Aus diesem Grund verwendet Android nicht mehr die Methode CN. Zur Überprüfung eines Hostnamens muss der Server ein Zertifikat mit einem übereinstimmenden SAN präsentieren. Zertifikate, die kein SAN enthalten, das mit dem Hostnamen übereinstimmt, sind nicht mehr vertrauenswürdig.

Die Suche nach Netzwerkadressen kann zu Netzwerkverstößen führen

Netzwerkadresssuchen, die eine Namensauflösung erfordern, können Netzwerk-E/A-Vorgänge beinhalten und gelten daher als blockierende Vorgänge. Das Blockieren von Vorgängen im Hauptthread kann zu Pausen oder Verzögerungen führen.

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

Unter Android 9 und höher erkennt StrictMode Netzwerkverstöße, die durch Netzwerkadresssuchen verursacht werden, für die eine Namensauflösung erforderlich ist.

Sie sollten Ihre Apps nicht versenden, wenn StrictMode aktiviert ist. Andernfalls können in Ihren Apps Ausnahmen wie NetworkOnMainThreadException auftreten, wenn Sie die Methoden detectNetwork() oder detectAll() verwenden, um eine Richtlinie abzurufen, die Netzwerkverstöße erkennt.

Das Auflösen einer numerischen IP-Adresse wird nicht als blockierender Vorgang betrachtet. Die Auflösung numerischer IP-Adressen funktioniert genauso wie in Versionen vor Android 9.

Socket-Tagging

Wenn ein Socket in Plattformversionen vor Android 9 mit der Methode setThreadStatsTag() getaggt ist, wird der Socket nicht getaggt, wenn er unter Verwendung von Binder IPC mit einem ParcelFileDescriptor-Container an einen anderen Prozess gesendet wird.

Ab Android 9 wird das Socket-Tag beibehalten, wenn es mithilfe von Binder-IPC an einen anderen Prozess gesendet wird. Diese Änderung kann sich auf die Statistiken zum Netzwerktraffic auswirken, z. B. bei Verwendung der Methode queryDetailsForUidTag().

Wenn Sie das Verhalten der vorherigen Versionen beibehalten möchten, bei denen die Kennzeichnung eines Sockets aufgehoben wird, der an einen anderen Prozess gesendet wird, können Sie vor dem Senden des Sockets untagSocket() aufrufen.

Gemeldete Menge der verfügbaren Byte im Socket

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

Detailliertere Berichte zu Netzwerkfunktionen für VPNs

In Android 8.1 (API-Level 27) und niedriger meldete die Klasse NetworkCapabilities nur eine begrenzte Anzahl von Informationen für VPNs, z. B. TRANSPORT_VPN, wobei NET_CAPABILITY_NOT_VPN jedoch weggelassen wurde. Aufgrund dieser begrenzten Informationen war es schwierig zu ermitteln, ob für die Nutzung eines VPN Gebühren für den Nutzer der Anwendung anfallen würden. Wenn Sie beispielsweise NET_CAPABILITY_NOT_METERED prüfen, wird nicht festgestellt, ob die zugrunde liegenden Netzwerke kostenpflichtig sind.

Wenn ein VPN in Android 9 und höher die Methode setUnderlyingNetworks() aufruft, führt das Android-System die Transporte und Funktionen aller zugrunde liegenden Netzwerke zusammen und gibt das Ergebnis als die effektiven Netzwerkfunktionen des VPN-Netzwerks zurück.

Ab Android 9 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 haben. Der Grund besteht darin, für Konsistenz mit einigen Geräten zu sorgen, auf denen diese Dateien überhaupt 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 auf verschiedenen Geräten jedoch möglicherweise nicht wie erwartet oder überhaupt nicht.

Die Anforderung FLAG_ACTIVITY_NEW_TASK wird jetzt erzwungen

Unter Android 9 können Sie nur dann eine Aktivität aus einem Kontext ohne Aktivität 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 gibt eine Meldung im Log aus.

Änderungen bei der Bildschirmdrehung

Ab Android 9 gibt es erhebliche Änderungen am Hochformat. Unter Android 8.0 (API-Ebene 26) konnten Nutzer über eine Quicksettings-Kachel oder die Anzeigeeinstellungen zwischen den Modi Automatisch drehen und Hochformat wechseln. Das Hochformat wurde in Drehsperre umbenannt und ist aktiv, wenn das automatische Drehen deaktiviert ist. Der Modus für das automatische Drehen bleibt unverändert.

Wenn sich das Gerät im Rotationssperrmodus befindet, können Nutzer ihren Bildschirm auf eine beliebige Rotation festlegen, die von der oberen, sichtbaren Aktivität unterstützt wird. Bei einer Aktivität sollte nicht davon ausgegangen werden, dass sie immer im Hochformat gerendert wird. Wenn die Top-Aktivität in mehreren Rotationen im automatischen Drehmodus gerendert werden kann, sollten im Rotationssperrmodus die gleichen Optionen verfügbar sein. Ausnahmen basieren auf der Einstellung screenOrientation der Aktivität (siehe Tabelle unten).

Aktivitäten, die eine bestimmte Ausrichtung anfordern (z. B. screenOrientation=landscape), ignorieren die Einstellung für die Nutzersperre und verhalten sich genauso wie unter Android 8.0.

Die Einstellung für die Bildschirmausrichtung kann im Android-Manifest auf der Aktivitätsebene oder programmatisch mit setRequestedOrientation() festgelegt werden.

Im Rotationssperrmodus wird die Einstellung für die Nutzerrotation festgelegt, die WindowManager bei der Aktivitätsrotation verwendet. Die Einstellung für die Nutzerrotation kann in den folgenden Fällen geändert werden. Beachten Sie, dass die Rückkehr zur natürlichen Rotation des Geräts erfolgt, die bei Geräten mit Smartphone-Formfaktor normalerweise im Hochformat ist:

  • Wenn der Nutzer einen Rotationsvorschlag annimmt, ändert sich die Rotationseinstellung in den Vorschlag.
  • Wenn der Nutzer zu einer App im Hochformat wechselt (einschließlich Sperrbildschirm oder Launcher), ändert sich die Einstellung für die Drehung in das Hochformat.

In der folgenden Tabelle ist das Rotationsverhalten für die gängigen Bildschirmausrichtungen zusammengefasst:

Displayausrichtung Verhalten
nicht angegeben, Nutzer Wenn die Sperre für das automatische Drehen und die Drehung aktiviert ist, kann die Aktivität im Hoch- oder Querformat (und umgekehrt) gerendert werden. werden sowohl das Hoch- als auch das Querformat unterstützen.
Nutzerlandschaft Bei einer Sperre für automatisches Drehen und Drehen kann die Aktivität entweder im Quer- oder im umgekehrten Querformat gerendert werden. Nur Layouts im Querformat werden unterstützt.
Benutzerfoto Bei einer Sperre für automatisches Drehen und Drehen kann die Aktivität entweder im Hochformat oder im umgekehrten Hochformat gerendert werden. Normalerweise werden nur Layouts im Hochformat unterstützt.
FullUser Wenn die Sperre für das automatische Drehen und die Drehung aktiviert ist, kann die Aktivität im Hoch- oder Querformat (und umgekehrt) gerendert werden. Diese sollten sowohl das Hoch- als auch das Querformat unterstützen.

Nutzer mit Rotationssperre haben die Möglichkeit, das Hochformat für 180° festzulegen.
Sensor, FullSensor, sensorPortrait, sensorLandscape Die Einstellung für den Modus für die Rotationssperre wird ignoriert und so behandelt, als wäre das automatische Drehen aktiv. Verwenden Sie dies nur in Ausnahmefällen und unter sehr sorgfältiger UX-Abwägung.

Die 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 eingestellt. Diese Änderung hat keine Auswirkungen auf die meisten Apps, die nicht auf Android 9 oder höher ausgerichtet sind. Die Änderung kann jedoch bestimmte Apps betreffen, die eine nicht standardmäßige ClassLoader-Struktur verwenden, auch wenn die Apps nicht auf Android 9 oder höher ausgerichtet sind.

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

Kameras auflisten

Apps, die auf Geräten mit Android 9 ausgeführt werden, können durch Aufrufen von getCameraIdList() alle verfügbaren Kameras erkennen. Eine App sollte nicht davon ausgehen, dass das Gerät nur eine einzige Rückkamera oder nur eine Frontkamera hat.

Wenn Ihre App beispielsweise eine Schaltfläche zum Wechseln zwischen der Front- und Rückkamera enthält, stehen möglicherweise mehrere Front- oder Rückkameras zur Auswahl. Gehen Sie die Kameraliste durch, untersuchen Sie die Eigenschaften der einzelnen Kameras und entscheiden Sie, welche Kameras dem Nutzer angezeigt werden sollen.