Verhaltensänderungen unter Android 8.0

Neben den neuen Funktionen bietet Android 8.0 (API-Level 26) umfasst eine Vielzahl von System- und API-Verhaltensänderungen. Dieses Dokument hebt einige der wichtigsten Änderungen hervor, die Sie verstehen und berücksichtigen sollten in deinen Apps.

Die meisten dieser Änderungen betreffen alle Apps, unabhängig von der Android, auf das sie ausgerichtet sind. Einige Änderungen wirken sich jedoch nur auf das App-Targeting aus. Android 8.0 Um für mehr Klarheit zu sorgen, ist in zwei Abschnitte unterteilt: Änderungen für alle Apps und Änderungen beim App-Targeting Android 8.0

Änderungen für alle Apps

Diese Verhaltensänderungen gelten für alle Apps, wenn sie auf der Plattform Android 8.0 (API-Level 26) ausgeführt werden, API-Level, auf das sie ausgerichtet sind. Alle Entwickler sollten und ihre Apps anpassen, um sie korrekt zu unterstützen, wenn dies für die App relevant ist.

Ausführungslimits im Hintergrund

Eine der Änderungen, die mit Android 8.0 (API-Level 26) um die Akkulaufzeit zu verlängern, im Cache gespeichert Status, ohne aktive Komponenten, gibt das System alle in der App gespeicherten Wakelocks frei.

Um die Geräteleistung zu verbessern, schränkt das System außerdem bestimmte von Apps, die nicht im Vordergrund ausgeführt werden. Im Detail:

  • Für Apps, die im Hintergrund ausgeführt werden, gibt es jetzt Einschränkungen können sie auf Hintergrunddienste zugreifen.
  • Apps können ihre Manifeste nicht verwenden, um sich für die meisten impliziten Broadcasts zu registrieren (d. h. Broadcasts, die nicht speziell auf die App ausgerichtet sind).

Standardmäßig gelten diese Einschränkungen nur für Apps, die auf das Betriebssystem O ausgerichtet sind. Sie können jedoch Nutzer können diese Einschränkungen für jede App auf dem Bildschirm Einstellungen aktivieren. auch wenn die App nicht auf O ausgerichtet ist.

Unter Android 8.0 (API-Level 26) wurden außerdem bestimmte Methoden geändert:

  • Die Methode startService() gibt jetzt IllegalStateException, wenn eine App auf Android 8.0 ausgerichtet ist, wird diese Methode wenn es nicht erlaubt ist, Hintergrunddienste zu erstellen.
  • Die neue Methode Context.startForegroundService() startet eine Dienst im Vordergrund. Das System lässt Apps zu, um Context.startForegroundService() aufzurufen, auch wenn die App im Hintergrund. Die App muss jedoch die Methode startForeground() dieses Dienstes innerhalb von fünf Sekunden nach der Diensterstellung.

Weitere Informationen finden Sie unter Beschränkungen der Hintergrundausführung.

Einschränkungen für die Standortermittlung im Hintergrund unter Android

Zur Schonung des Akkus, der Nutzererfahrung und des Systemzustands Hintergrund-Apps erhalten Standortupdates seltener, wenn sie auf einem Gerät verwendet werden mit Android 8.0. Diese Verhaltensänderung betrifft alle Apps die Standortaktualisierungen erhalten, z. B. Google Play-Dienste.

Diese Änderungen betreffen die folgenden APIs:

  • Anbieter für kombinierte Standortbestimmung (Fused Location Provider, FLP)
  • Geofencing
  • GNSS-Messungen
  • Standortverwaltung
  • WLAN-Manager

Führen Sie die folgenden Schritte aus, damit Ihre App wie erwartet ausgeführt wird:

  • Prüfen Sie die Logik Ihrer App und achten Sie darauf, dass Sie den neuesten Standort verwenden. APIs
  • Testen, ob Ihre App das Verhalten aufweist, das Sie bei jeder Verwendung erwarten Fall.
  • Erwägen Sie die Verwendung des Kombiniert Location Provider (FLP) oder Geofencing, um die Anwendungsfälle zu bewältigen, die von dem aktuellen Standort des Nutzers.

Weitere Informationen zu diesen Änderungen finden Sie unter Hintergrundstandort Limits.

App-Verknüpfungen

Unter Android 8.0 (API-Level 26) wurden die folgenden Änderungen an App-Verknüpfungen vorgenommen:

  • Die com.android.launcher.action.INSTALL_SHORTCUT-Übertragungsnr. Auswirkungen auf Ihre App hat, da sie jetzt eine private, implizite Nachricht an alle. Stattdessen solltest du eine App-Verknüpfung erstellen, indem du die requestPinShortcut() aus der Klasse ShortcutManager.
  • Das ACTION_CREATE_SHORTCUT kann Intent jetzt App-Verknüpfungen erstellen, die du über die Klasse ShortcutManager. Dieser Intent kann auch alten Launcher-Tastenkombinationen, die nicht mit ShortcutManager Bisher konnte dieser Intent nur Legacy-Launcher-Verknüpfungen erstellen.
  • Verknüpfungen erstellt mit requestPinShortcut() und Verknüpfungen, die in einer Aktivität erstellt wurden, ACTION_CREATE_SHORTCUT Intents sind jetzt vollwertige App-Verknüpfungen. Dadurch können sie von Apps jetzt aktualisiert werden. mithilfe der Methoden in ShortcutManager.
  • Ältere Tastenkombinationen haben ihre Funktionalität aus früheren Versionen von Android, du musst sie aber in deiner App manuell in App-Verknüpfungen konvertieren.

Weitere Informationen zu Änderungen an App-Verknüpfungen findest du in der Durch Anpinnen von Verknüpfungen und Funktionsübersicht für Widgets.

Lokalisierung und Internationalisierung

Mit Android 7.0 (API-Level 24) wurde das Konzept eingeführt, ein standardmäßiges Gebietsschema für die Kategorie angeben. Einige APIs verwenden jedoch weiterhin die Methode Allgemein Locale.getDefault() ohne Argumente, obwohl stattdessen die Standardeinstellung der Kategorie DISPLAY verwendet werden sollte. In Android 8.0 (API-Level 26) folgende Methoden verwenden jetzt Locale.getDefault(Category.DISPLAY) statt Locale.getDefault():

Locale.getDisplayScript(Locale) wird auf Locale.getDefault() zurückgesetzt, wenn der displayScript-Wert für Locale angegeben Argument ist nicht verfügbar.

Weitere Änderungen im Zusammenhang mit der Region und der Internationalisierung sind wie folgt: folgt:

  • Der Aufruf von Currency.getDisplayName(null) löst eine NullPointerException aus, dem dokumentierten Verhalten entsprechen.
  • Das Parsen des Zeitzonennamens hat sich geändert. Bisher Android-Geräte haben den beim Booten erfassten Systemuhrwert verwendet Zeit zum Zwischenspeichern der Zeitzonennamen, die zum Parsen des Datums verwendet werden Mal. Infolgedessen könnte das Parsing negativ beeinflusst werden, wenn das System oder in seltenen Fällen, dass die Uhrzeit beim Starten falsch war.

    Häufig verwendet die Parsing-Logik ICU und die Aktuellen Wert der Systemuhr beim Parsen von Zeitzonennamen. Dieses Änderung liefert korrektere Ergebnisse, die sich von den vorherigen unterscheiden können. Android-Versionen, wenn Ihre App Klassen wie SimpleDateFormat

  • Mit Android 8.0 (API-Level 26) wird die ITS-Version auf Version 58 aktualisiert.

Benachrichtigungsfenster

Wenn eine App das SYSTEM_ALERT_WINDOW und versucht einen der folgenden Fenstertypen, Warnfenster über anderen Apps und Systemfenstern:

...dann erscheinen diese Fenster immer unter den Fenstern, die die Funktion TYPE_APPLICATION_OVERLAY Fenster Typ. Wenn eine App auf Android 8.0 (API-Level 26) ausgerichtet ist, verwendet sie die TYPE_APPLICATION_OVERLAY Fenstertyp, um Warnfenster anzuzeigen.

Weitere Informationen finden Sie unter Gängige Fenstertypen für Benachrichtigungsfenster in den Verhaltensänderungen für Apps auf Android 8.0 ausgerichtet.

Eingabe und Navigation

Mit der Einführung von Android-Apps unter ChromeOS und anderen großen Formfaktoren wie Tablets eingesetzt werden, setzen wir die Tastaturnavigation in Android-Apps. Unter Android 8.0 (API-Level 26) haben wir mithilfe von die Tastatur als Navigationseingabegerät nutzen, was zu einer zuverlässigeren, vorhersehbares Modell für Pfeil- und Tab-basierte Navigation.

Insbesondere folgende Änderungen am Elementfokus Verhalten:

  • Wenn Sie keine Farben für den Fokusstatus für eine View-Objekt (Vor- oder Hintergrund) Drawable-Element), legt das Framework jetzt eine standardmäßige Fokushervorhebungsfarbe für das View. Diese Hervorhebung ist ein Wellen-Drawable, das basierend auf dem Thema der Aktivität.

    Wenn ein View-Objekt diese Standardeinstellung nicht verwenden soll hervorheben, wenn der Fokus darauf liegt, Attribut „android:defaultFocusHighlightEnabled“ für false in der Layout-XML-Datei mit den View oder false übergeben an setDefaultFocusHighlightEnabled() in der UI-Logik deiner App fest.

  • Um zu testen, wie sich die Tastatureingabe auf den Fokus von UI-Elementen auswirkt, können Sie die Funktion Zeichnung > Entwickleroption „Layoutgrenzen anzeigen“. In Android 8.0 enthält, wird bei dieser Option ein "X" über dem Element, das derzeit fokussiert.

Außerdem werden in Android 8.0 alle Symbolleistenelemente Tastaturnavigations-Cluster was es Nutzenden erleichtert, als als Ganzes.

Weitere Informationen zur Verbesserung der Unterstützung der Tastaturnavigation in finden Sie im Abschnitt Unterstützende Leitfaden zur Tastaturnavigation.

Autofill für Webformulare

Da die Android-Funktion Autofill bietet integrierte Unterstützung für die Funktion zum automatischen Ausfüllen, die folgende Methoden im Zusammenhang mit WebView-Objekten wurden geändert für Apps, die auf Geräten mit Android 8.0 (API-Level 26) installiert sind:

WebSettings
WebViewDatabase
  • Anrufen clearFormData() Absage(n) keine Wirkung mehr hat.
  • Die hasFormData()-Methode gibt jetzt false zurück. Bisher hat diese Methode true, wenn das Formular Daten enthielt.

Bedienungshilfen

Unter Android 8.0 (API-Level 26) wurden die folgenden Änderungen bei der Barrierefreiheit vorgenommen:

  • Das Bedienungshilfen-Framework konvertiert jetzt alle Doppeltipp-Gesten in ACTION_CLICK Aktionen. Durch diese Änderung funktioniert TalkBack nun ähnlich wie andere Bedienungshilfen.

    Wenn die View-Objekte deiner App die benutzerdefinierte Touch-Option verwenden sollten Sie überprüfen, ob sie weiterhin mit TalkBack funktionieren. Möglicherweise Sie müssen nur den Klick-Handler registrieren, mit dem Ihr View verwenden. Wenn TalkBack immer noch keine Gesten erkennt, die auf diesen Geräten ausgeführt werden View Objekte, überschreiben performAccessibilityAction().

  • Bedienungshilfen kennen jetzt alle ClickableSpan Instanzen innerhalb der TextView-Objekte.

Weitere Informationen zur Verbesserung der Barrierefreiheit deiner App findest du unter Bedienungshilfen:

Netzwerk und HTTP(S)-Konnektivität

Unter Android 8.0 (API-Level 26) gibt es die folgenden Verhaltensänderungen für Netzwerk- und HTTP(S)-Konnektivität:

  • OPTIONS-Anfragen ohne Text haben einen Content-Length: 0 Header. Bisher hatten sie keinen Content-Length-Header.
  • HttpURLConnection normalisiert URLs mit leeren Pfaden durch Anfügen von den Namen des Hosts oder der Zertifizierungsstelle gefolgt von einem Schrägstrich. Zum Beispiel konvertiert http://example.com in http://example.com/.
  • Einen benutzerdefinierten Proxy-Selektor, der über ProxySelector.setDefault() festgelegt wurde Die Ausrichtung erfolgt nur auf die Adresse (Schema, Host und Port) einer angeforderten URL. Daher basiert die Proxy-Auswahl möglicherweise nur auf diesen Werten. Eine URL an einen benutzerdefinierten Proxy-Selektor übergebene URL nicht Pfad, Abfrageparameter oder Fragmente.
  • URIs dürfen keine leeren Labels enthalten.

    Bisher hat die Plattform eine Problemumgehung unterstützt, um leere Labels in Hostnamen. Dies ist eine unzulässige Verwendung von URIs. Diese Problemumgehung bezog sich auf Kompatibilität mit älteren Libcore-Releases. Entwickler, die die API verwenden würde fälschlicherweise die ADB-Meldung angezeigt: „URI example.com has empty labels in den Hostnamen. Dieses Format ist fehlerhaft und wird in Zukunft unter Android nicht mehr akzeptiert. Veröffentlichungen.“ Unter Android 8.0 wird diese Behelfslösung entfernt: gibt das System null für fehlerhafte URIs.

  • Implementierung von HttpsURLConnection in Android 8.0 kein Fallback auf unsichere Versionen des TLS/SSL-Protokolls durchführt.
  • Die Verarbeitung von Tunneling-HTTP(S)-Verbindungen wurde wie folgt geändert: <ph type="x-smartling-placeholder">
      </ph>
    • Beim Tunneling einer HTTPS-Verbindung über eine Verbindung setzt die Portnummer (:443) beim Senden von Nachrichten an die an einen zwischengeschalteten Server senden. Bisher wurde der Port -Nummer nur in der CONNECT-Zeile vor.
    • Das System sendet keine User-Agent- und Proxy-Autorisierung mehr. von einer getunnelten Anfrage an den Proxyserver zu senden.

      Das System sendet keinen Proxy-Autorisierungs-Header mehr an eine getunnelte Http(s)URLConnection zum Proxy beim Einrichten der Tunnel. Stattdessen generiert das System einen Proxy-Autorisierungs-Header, und sendet sie an den Proxy, wenn dieser HTTP 407-Fehler als Antwort auf die ursprüngliche Anfrage.

      Ebenso wird der User-Agent-Header nicht mehr vom System kopiert. von der getunnelten Anfrage zur Proxy-Anfrage, Tunnel. Stattdessen generiert die Bibliothek einen User-Agent-Header für diesen

  • Das send(java.net.DatagramPacket) löst eine SocketException aus, wenn die zuvor ausgeführte Connect()-Methode konnte nicht ausgeführt werden.
    • DatagramSocket.connect() legt eine pendingSocketException fest, wenn eine interner Fehler. Vor Android 8.0 wurde eine nachfolgende recv()-Anweisung -Aufruf löste eine SocketException aus, obwohl ein send()-Aufruf erfolgreich gewesen wäre. Aus Konsistenzgründen lösen beide Aufrufe jetzt eine SocketException aus.
  • InetAddress.isReachable() versucht ICMP, bevor auf TCP Echo zurückgegriffen wird Protokoll.
    • Einige Hosts, die Port 7 (TCP Echo) blockieren, wie google.com, sind jetzt erreichbar, wenn sie das ICMP Echo-Protokoll akzeptieren.
    • Für wirklich nicht erreichbare Hosts bedeutet diese Änderung, Zeit aufgewendet wird, bevor der Aufruf zurückkehrt.

Bluetooth

Unter Android 8.0 (API-Level 26) werden folgende Änderungen an der Länge des die Daten, die ScanRecord.getBytes() abgerufen:

  • Für die Methode getBytes() werden keine Annahmen in Bezug auf Anzahl der empfangenen Bytes. Daher sollten Anwendungen nicht auf Mindest- oder Höchstanzahl zurückgegebener Byte. Stattdessen sollten sie Länge des resultierenden Arrays.
  • Daten, die mit Bluetooth 5 kompatibel sind, können Daten zurückgeben, die die vorheriges Maximum von ~60 Byte.
  • Wenn ein Remote-Gerät keine Scanantwort zurückgibt, sind weniger als 60 Byte groß ebenfalls zurückgegeben werden.

Nahtlose Konnektivität

Unter Android 8.0 (API-Level 26) wurden einige Verbesserungen an den WLAN-Einstellungen vorgenommen, um die Auswahl der WLAN-Einstellungen zu erleichtern das WLAN aus, das die beste Nutzererfahrung bietet. Zu den Änderungen gehören:

  • Verbesserte Stabilität und Zuverlässigkeit
  • Eine intuitivere Benutzeroberfläche.
  • Ein einzelnes, konsolidiertes WLAN-Einstellungsmenü.
  • Auf kompatiblen Geräten: automatische Aktivierung des WLANs bei einem gespeicherten Netzwerk mit hoher Qualität ist in der Nähe.

Sicherheit

Android 8.0 umfasst die folgenden sicherheitsbezogenen Änderungen:

  • SSLv3 wird von dieser Plattform nicht mehr unterstützt.
  • Beim Herstellen einer HTTPS-Verbindung zu einem Server, der falsch die Verhandlung der TLS-Protokollversion implementiert, HttpsURLConnection versucht nicht mehr, die Problemumgehung zu verwenden auf frühere Versionen des TLS-Protokolls zurückzugreifen und es erneut zu versuchen.
  • Android 8.0 (API-Level 26) wendet ein Secure Computing (SECCOMP) an nach allen Apps filtern. Die Liste der zulässigen Systemaufrufe ist beschränkt auf durch Bionik ausgesetzt. Es gibt zwar mehrere andere Systemaufrufe, aus Gründen der Abwärtskompatibilität.
  • Die WebView-Objekte Ihrer App werden jetzt in Multiprozess ausgeführt . Webinhalte werden in einem separaten, isolierten Prozess vom die den Prozess für erhöhte Sicherheit enthält.
  • Du kannst nicht mehr davon ausgehen, dass sich APKs in Verzeichnissen befinden, deren Namen enden in -1 oder -2. Apps sollten sourceDir, um die und verlassen sich nicht direkt auf das Verzeichnisformat.
  • Informationen zu Sicherheitsverbesserungen bei der Verwendung von nativen Anzeigen Native Libraries.

Außerdem werden mit Android 8.0 (API-Level 26) die folgenden Änderungen an der Installation vorgenommen unbekannten Apps aus unbekannten Quellen:

Weitere Informationen zur Installation unbekannter Apps findest du in der Unbekannte App Installationsberechtigungen.

Weitere Richtlinien zur Erhöhung der Sicherheit Ihrer App finden Sie unter Sicherheit für Android-Entwickler

Datenschutz

Unter Android 8.0 (API-Level 26) werden die folgenden Änderungen an der Plattform.

  • Die Plattform behandelt Kennungen jetzt anders.
    • Für Apps, die vor einem OTA-Update oder einer Version von Android 8.0 (API-Level 26) (API-Ebene 26), wird der Wert von ANDROID_ID bleibt gleich es sei denn, die App wurde deinstalliert und nach dem OTA-Update neu installiert. Um die Werte in der Deinstallationen nach dem OTA-Update möglich, können Entwickler die alten und neuen Werte <ph type="x-smartling-placeholder"></ph> Schlüssel/Wert-Sicherung.
    • Bei Apps, die auf einem Gerät mit Android 8.0 installiert sind, wird der Wert ANDROID_ID ist jetzt zugeordnet pro App-Signaturschlüssel und Nutzer. Der Wert von ANDROID_ID ist eindeutig für jede Kombination aus App-Signaturschlüssel, Nutzer und Gerät. Dadurch werden Apps mit unterschiedlichen Signaturschlüsseln auf demselben Gerät ausgeführt nicht mehr dieselbe Android-ID sehen (auch nicht für denselben Nutzer).
    • Wert von ANDROID_ID ändert sich bei der Deinstallation oder Neuinstallation des Pakets nicht, der Signaturschlüssel identisch ist (und die App wurde nicht vor einem OTA-Update Version von Android 8.0).
    • Wert von ANDROID_ID ändert sich auch dann nicht, wenn ein Systemupdate dazu führt, dass sich der Paketsignaturschlüssel ändert.
    • Auf Geräten, die mit Google Play-Diensten und der Werbe-ID ausgeliefert werden, müssen Sie <ph type="x-smartling-placeholder"></ph> Werbe-ID. Ein einfaches Standardsystem zur Monetarisierung von Apps, Die Werbe-ID ist eine eindeutige ID für Werbezwecke, die vom Nutzer zurückgesetzt werden kann. Wird bereitgestellt von Google Play-Diensten.

      Andere Gerätehersteller sollten fortfahren um ANDROID_ID bereitzustellen.

  • Das Abfragen der Systemeigenschaft net.hostname erzeugt einen NULL-Wert. Ergebnis.

Logging von nicht abgefangenen Ausnahmen

Wenn eine App ein Thread.UncaughtExceptionHandler installiert, nicht zum standardmäßigen Thread.UncaughtExceptionHandler, macht das System Die App wird nicht beendet, wenn eine nicht abgefangene Ausnahme auftritt. Ab Unter Android 8.0 (API-Level 26) protokolliert das System den Ausnahme-Stacktrace Situation; in früheren Versionen der Plattform hätte das System den Ausnahme-Stacktrace protokolliert.

Wir empfehlen, benutzerdefinierte Thread.UncaughtExceptionHandler Implementierungen immer an den Standard-Handler; Apps, die dieser Empfehlung folgen, sind vom über die Änderung bei Android 8.0.

findViewById()-Signaturänderung

Alle Instanzen der Methode findViewById() geben jetzt <T extends View> T anstelle von View zurück. Diese Änderung hat folgende Auswirkungen:

  • Dies kann dazu führen, dass vorhandener Code jetzt einen mehrdeutigen Rückgabetyp hat, Wenn z. B. sowohl someMethod(View) als auch someMethod(TextView), die das Ergebnis eines Aufrufs von findViewById()
  • Bei Verwendung der Java 8-Quellsprache ist eine explizite Umwandlung in View, wenn der Rückgabetyp nicht eingeschränkt ist (z. B. assertNotNull(findViewById(...)).someViewMethod()).
  • Überschreibungen nicht finaler findViewById()-Methoden (für Beispiel: Activity.findViewById()) eine Rückgabe Typ aktualisiert.

Änderung der Nutzungsstatistiken des Anbieters für Kontakte

In früheren Versionen von Android war die Komponente „Contact Provider“ ermöglicht es Entwicklern, Nutzungsdaten für jeden Kontakt abzurufen. Diese Nutzungsdaten enthält Informationen zu jeder E-Mail-Adresse und jeder verknüpften Telefonnummer mit einem Kontakt, einschließlich der Häufigkeit, mit der dieser Kontakt kontaktiert wurde und wann der Kontakt zuletzt kontaktiert wurde. Apps, die den READ_CONTACTS Berechtigung kann diese Daten lesen.

Apps können diese Daten weiterhin lesen, wenn sie dies anfordern READ_CONTACTS Berechtigung. Ab Android 8.0 (API-Level 26) werden bei Abfragen nach Nutzungsdaten und nicht um exakte Werte. Das Android-System verwaltet exakte Werte intern. Diese Änderung wirkt sich also nicht auf die Auto-complete API.

Diese Verhaltensänderung betrifft die folgenden Abfrageparameter:

Handhabung der Abholung

AbstractCollection.removeAll() und AbstractCollection.retainAll() geben jetzt immer NullPointerException aus. zuvor die Funktion NullPointerException wurde nicht ausgegeben, als die Sammlung erstellt wurde. leer. Durch diese Änderung wird das Verhalten an die Dokumentation angepasst.

Android Enterprise

Android 8.0 (API-Level 26) ändert die Verhalten einiger APIs und Funktionen für Unternehmens-Apps, einschließlich des Geräts, Policy Controller (DPCs). Zu den Änderungen gehören:

  • Neue Verhaltensweisen, damit Apps Arbeitsprofile auf vollständig verwalteten Geräten unterstützen.
  • Änderungen an der Verarbeitung von Systemupdates, der App-Überprüfung und der Authentifizierung die Geräte- und Systemintegrität erhöhen.
  • Verbesserungen bei der Nutzerverwaltung, bei Benachrichtigungen, beim „Letzte“ und durchgehend aktives VPN.

Hier findest du alle Änderungen für Unternehmen in Android 8.0 (API-Level 26) und erfährst, wie sie sich auf Ihre App auswirkt, lesen Sie Android im Unternehmen

Apps für Android 8.0

Diese Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 8.0 (API-Level 26) oder höher Apps, die für Android 8.0 kompiliert sind, oder targetSdkVersion auf Android 8.0 oder höher festlegen, Apps so, dass diese Verhaltensweisen ordnungsgemäß unterstützt werden, sofern dies für die App erforderlich ist.

Benachrichtigungsfenster

Apps, die SYSTEM_ALERT_WINDOW verwenden Berechtigung darf die folgenden Fenstertypen nicht mehr zum Anzeigen von Benachrichtigungsfenstern verwenden über anderen Apps und Systemfenstern befindet:

Stattdessen müssen Apps einen neuen Fenstertyp namens TYPE_APPLICATION_OVERLAY

Bei Verwendung des TYPE_APPLICATION_OVERLAY Fenster eingeben, um Benachrichtigungsfenster für Ihre App anzuzeigen, behalten Sie die folgenden Eigenschaften bei des neuen Fenstertyps bedenken:

  • Die Warnfenster einer App werden immer unter kritischen Systemfenstern angezeigt, z. B. als Statusleiste und IMEs.
  • Das System kann Fenster verschieben oder ihre Größe anpassen, TYPE_APPLICATION_OVERLAY Fenstertyp, um die Bildschirmpräsentation zu verbessern.
  • Durch Öffnen der Benachrichtigungsleiste können Nutzer auf Einstellungen zugreifen, um die über die Funktion TYPE_APPLICATION_OVERLAY Fenstertyp.

Benachrichtigungen zu Inhaltsänderungen

Unter Android 8.0 (API-Level 26) ändert sich ContentResolver.notifyChange() und registerContentObserver(Uri, boolean, ContentObserver) verhalten sich bei Apps für Android 8.0.

Für diese APIs ist jetzt ein gültiger ContentProvider erforderlich für die Autorität in allen URIs definiert. Das Definieren eines gültigen ContentProvider mit relevanten Berechtigungen deine App vor Inhaltsänderungen durch schädliche Apps schützen und dich potenziell private Daten an schädliche Apps übertragen.

Fokus ansehen

Anklickbare View-Objekte können jetzt auch von Standardeinstellung. Wenn ein View-Objekt anklickbar sein soll, fokussierbar, legen Sie <ph type="x-smartling-placeholder"></ph> android:focusable-Attribut im Layout auf false XML-Datei mit View oder übergeben Sie false in der Benutzeroberfläche deiner App an setFocusable() Logik.

User-Agent-Abgleich bei der Browsererkennung

Android 8.0 (API-Level 26) und höher enthalten die Build-ID-String OPR. Einige Musterübereinstimmungen können können dazu führen, dass die Browsererkennungslogik einen Nicht-Opera-Browser fälschlicherweise als Opera identifiziert. Hier ist ein Beispiel für eine solche Musterübereinstimmung:

if(p.match(/OPR/)){k="Opera";c=p.match(/OPR\/(\d+.\d+)/);n=new Ext.Version(c[1])}

Um Probleme aufgrund einer solchen Fehlidentifizierung zu vermeiden, verwenden Sie eine andere Zeichenfolge als OPR als Musterabgleich für den Opera-Browser.

Sicherheit

Die folgenden Änderungen wirken sich auf die Sicherheit unter Android 8.0 (API-Level 26) aus:

  • Wenn die Netzwerksicherheitskonfiguration Ihrer App Opt-ins Klartextzugriffe erzielen, WebView-Objekte können nicht über HTTP auf Websites zugreifen. Jedes Für das WebView-Objekt muss stattdessen HTTPS verwendet werden.
  • Die Systemeinstellung Unbekannte Quellen zulassen wurde entfernt. in seiner werden über die Berechtigung Unbekannte Apps installieren unbekannte App-Installationen verwaltet. aus unbekannten Quellen stammen. Weitere Informationen zu dieser neuen Berechtigung findest du in der Unbekannte App Installationsberechtigungen.

Weitere Richtlinien zur Erhöhung der Sicherheit Ihrer App finden Sie unter Sicherheit für Android-Entwickler

Kontozugriff und Sichtbarkeit

Unter Android 8.0 (API-Level 26) können Apps keinen Zugriff mehr erhalten es sei denn, der Authenticator ist Inhaber der Konten oder der -Nutzer gewährt diesen Zugriff. Die Berechtigung „GET_ACCOUNTS“ ist nicht mehr ausreichend. Damit Apps Zugriff auf ein Konto erhalten, müssen sie entweder AccountManager.newChooseAccountIntent() verwenden oder ein Authenticator-spezifisches . Nachdem eine App Zugriff auf Konten erhalten hat, kann sie AccountManager.getAccounts() um darauf zuzugreifen.

Einstellung von Android 8.0 LOGIN_ACCOUNTS_CHANGED_ACTION Apps sollten Sie stattdessen addOnAccountsUpdatedListener() , um während der Laufzeit Updates zu Konten zu erhalten.

Informationen zu neuen APIs und Methoden für den Kontozugriff und finden Sie unter Kontozugriff und Sichtbarkeit im Abschnitt „Neue APIs“ dieses Dokuments.

Datenschutz

Die folgenden Änderungen wirken sich auf den Datenschutz in Android 8.0 (API-Level 26) aus.

  • Die Systemattribute net.dns1, net.dns2 net.dns3 und net.dns4 wurden entfernt eine Änderung zur Verbesserung des Datenschutzes auf der Plattform.
  • Um Netzwerkinformationen wie DNS-Server zu erhalten, werden Anwendungen mit ACCESS_NETWORK_STATE Berechtigung können NetworkRequest oder NetworkCallback-Objekt. Diese Klassen sind ab Android 5.0 (API-Level 21) verfügbar.
  • Build.SERIAL wurde eingestellt. Apps, die die Seriennummer der Hardware kennen müssen, sollten stattdessen verwenden Sie die neue Methode Build.getSerial(), erfordert die READ_PHONE_STATE Berechtigung.
  • Die LauncherApps API lässt kein Arbeitsprofil mehr zu Apps, um Informationen zum primären Profil abzurufen. Wenn Nutzende in einem Profil verwenden, verhält sich die LauncherApps API so, als gäbe es keine Apps, werden in anderen Profilen derselben Profilgruppe installiert. Wie zuvor versucht, auf nicht verwandte Profile zuzugreifen, führt zu SecurityExceptions.

Berechtigungen

Vor Android 8.0 (API-Level 26), wenn eine App eine Berechtigung angefordert hat und die Berechtigung erteilt wurde, hat das System fälschlicherweise hat der App die restlichen Berechtigungen zugewiesen, die zur selben und im Manifest registriert wurden.

Bei Apps, die auf Android 8.0 ausgerichtet sind, ist dieses Verhalten korrigiert. Der App werden nur die Berechtigungen gewährt, die sie explizit hat angefordert. Sobald der Nutzer der App eine Berechtigung erteilt hat, werden jedoch alle Nachfolgende Berechtigungsanfragen in dieser Berechtigungsgruppe sind automatisch gewährt.

Beispiel: In einer App werden sowohl READ_EXTERNAL_STORAGE als auch WRITE_EXTERNAL_STORAGE. Die Anwendung fordert READ_EXTERNAL_STORAGE und vom Nutzer gewährt wird. Wenn die App auf API-Level 25 oder niedriger ausgerichtet ist, gewährt WRITE_EXTERNAL_STORAGE gleichzeitig da es zur selben STORAGE-Berechtigungsgruppe gehört die im Manifest registriert sind. Wenn die App auf Android 8.0 (API-Level 26) ausgerichtet ist, gewährt das System zu diesem Zeitpunkt nur READ_EXTERNAL_STORAGE; Fordert die App jedoch später WRITE_EXTERNAL_STORAGE an, wird das System sofort gewährt diese Berechtigung, ohne dass der Nutzer dazu aufgefordert wird.

Medien

  • Das Framework kann automatisches Audio-Ducking für sich allein. Wenn eine andere Anwendung den Fokus auf AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK, die Anwendung mit Fokus das Volumen reduziert, normalerweise aber keine onAudioFocusChange() zurückgerufen und keine Audiofokus verlieren. Es sind neue APIs verfügbar, um dieses Verhalten für die pausieren müssen.
  • Nimmt der Nutzer einen Anruf entgegen, werden aktive Medienstreams für die Dauer des aufrufen.
  • Für alle audiobezogenen APIs sollte AudioAttributes verwendet werden. anstelle von Audiostreamtypen, um den Anwendungsfall der Audiowiedergabe zu beschreiben. Audiostreamtypen sollten weiterhin nur für die Lautstärkeregelung verwendet werden. Andere Verwendungen von Streamtypen funktionieren weiterhin (z. B. das Argument streamType für das verworfene AudioTrack-Konstruktor) aber das System protokolliert dies als Fehler.
  • Wenn AudioTrack verwendet wird und die Anwendung einen ausreichend großen Audiopuffer anfordert, verwendet das Framework, falls verfügbar, die Zwischenspeicherausgabe zu verwenden.
  • In Android 8.0 (API-Level 26) werden Medienschaltflächenereignisse anders verarbeitet: <ph type="x-smartling-placeholder">
      </ph>
    1. Umgang mit Medienschaltflächen in einer UI-Aktivität hat sich nicht geändert: Vordergrundaktivitäten haben bei der Verarbeitung weiterhin Priorität. Medienschaltflächenereignisse.
    2. Wenn das Medienschaltflächenereignis bei der Vordergrundaktivität nicht verarbeitet wird, leitet das System das Ereignis weiter. mit der App verknüpfen, die zuletzt lokal Audioinhalte wiedergegeben hat. Status „Aktiv“, Markierungen und Wiedergabe Der Status einer Mediensitzung wird bei der Bestimmung, welche App Medien empfängt, nicht berücksichtigt. Button-Ereignissen.
    3. Wenn die Mediensitzung der App veröffentlicht wurde, sendet das System das Medienschaltflächenereignis an den MediaButtonReceiver, falls vorhanden.
    4. In allen anderen Fällen verwirft das System das Medienschaltflächenereignis.

Native Bibliotheken

In Apps, die auf Android 8.0 (API-Level 26) ausgerichtet sind, sind native Bibliotheken nicht länger, wenn sie ein Ladesegment enthalten, das sowohl beschreibbar ausführbar sein. Einige Apps funktionieren aufgrund dieser Änderung möglicherweise nicht mehr, wenn sie native Bibliotheken mit falschen Ladesegmenten. Dies ist ein sicherheitshärtende Maßnahme.

Weitere Informationen finden Sie unter Beschreibbare und ausführbare Segmente.

Änderungen an der Verknüpfung sind an das API-Level gebunden, auf das eine App abzielt. Wenn es ist eine Verknüpfungsänderung Ziel-API-Level ist, kann die App die Bibliothek nicht laden. Wenn Sie eine Ausrichtung auf eine niedrigere API-Ebene als die API-Ebene, Logcat zeigt eine Warnung an.

Handhabung der Abholung

Unter Android 8.0 (API-Level 26) Collections.sort() ist implementiert am List.sort(). Umgekehrt trifft auf Android 7.x (API-Level 24 und 25) zu: Die Standardimplementierung von List.sort() namens Collections.sort().

Durch diese Änderung kann Collections.sort() um die Vorteile der optimierten List.sort() Implementierungen, es gelten jedoch folgende Einschränkungen:

  • Implementierungen von List.sort() darf Collections.sort() nicht aufrufen, da dies zu einem Stacküberlauf aufgrund unendlicher Rekursion. Wenn Sie das Standardverhalten in Ihrer List-Implementierung sollten Sie das Überschreiben sort().

    Wenn eine übergeordnete Klasse sort() auf unangemessene Weise implementiert, in der Regel in Ordnung, List.sort() mit einer Implementierung, die auf List.toArray(), Arrays.sort() und ListIterator.set() Beispiel: 

    @Override
public void sort(Comparator<? super E> c) {
  Object[] elements = toArray();
  Arrays.sort(elements, c);
  ListIterator<E> iterator = (ListIterator<Object>) listIterator();
  for (Object element : elements) {
    iterator.next();
    iterator.set((E) element);
  }
}

    In den meisten Fällen können Sie auch List.sort() mit einem Implementierung, bei der verschiedene Standard- Implementierung abhängig vom API-Level. Beispiel: 

    @Override
public void sort(Comparator<? super E> comparator) {
  if (Build.VERSION.SDK_INT <= 25) {
    Collections.sort(this);
  } else {
    super.sort(comparator);
  }
}

    Wenn Sie Letzteres nur tun, weil Sie eine sort() haben möchten, auf allen API-Ebenen verfügbar ist, sollten Sie ihr einen eindeutigen Namen geben, wie sortCompat(), anstatt sort()

  • Collections.sort() zählt jetzt als eine strukturelle Änderung Listen Sie Implementierungen auf, die sort() aufrufen. In Versionen von der Plattform vor Android 8.0 (API-Level 26), ArrayList und ruft sort() darauf auf nach der Hälfte der Iteration hätte ConcurrentModificationException geworfen ob die Sortierung bereits erfolgt ist, indem du List.sort() anrufst. Collections.sort() keine Ausnahme ausgelöst.

    Durch diese Änderung wird das Plattformverhalten einheitlicher: Entweder führt jetzt zu einem ConcurrentModificationException.

Verhalten beim Laden von Klassen

Unter Android 8.0 (API-Level 26) wird geprüft, ob Klassenladeprogramme die Annahmen der Laufzeit beim Laden neuer Klassen außer Acht lassen. Diese Prüfungen sind wird ausgeführt, ob in Java auf die Klasse (von forName()) Dalvik-Bytecode oder JNI. Die Plattform fängt keine direkten Aufrufe von Java an den loadClass() und wird auch nicht geprüft die Ergebnisse solcher Anrufe. Dieses Verhalten sollte sich nicht auf die Funktionsweise Klassenladeprogrammen.

Die Plattform prüft, ob der Deskriptor der Klasse, die vom Klassenladeprogramm zurückgegeben wird, zurückgegeben wird. entspricht dem erwarteten Deskriptor. Wenn der zurückgegebene Deskriptor nicht übereinstimmt, gibt die Plattform den Fehler NoClassDefFoundError aus und speichert für die Ausnahme eine detaillierte Meldung, in der die Diskrepanz angegeben ist.

Die Plattform prüft auch, ob die Deskriptoren der angeforderten Klassen gültig sind. Dieses check fängt JNI-Aufrufe ab, die Klassen wie GetFieldID(), ungültige Deskriptoren an diese Klassen übergeben. Ein Feld mit einer Signatur java/lang/String wurde nicht gefunden, da diese Signatur ungültig ist. sollte Ljava/lang/String; lauten.

Dies unterscheidet sich von einem JNI-Aufruf an FindClass(). Dabei ist java/lang/String ein gültiger, voll qualifizierter Name.

Android 8.0 (API-Level 26) unterstützt nicht, dass mehrere Klassenladeprogramme versuchen, Klassen zu definieren mit demselben DexFile-Objekt. Bei einem entsprechenden Versuch löst die Android-Laufzeit InternalError Fehlermeldung "Versuch, DEX-Datei <filename> zu registrieren" mit mehreren Klassenladern“.

Die DexFile API wurde eingestellt. Wir empfehlen Ihnen dringend, die DexFile API zu verwenden. einem der Plattform-Classloader, einschließlich PathClassLoader oder BaseDexClassLoader.

Hinweis: Sie können mehrere Klassenladeprogramme erstellen, die auf die denselben APK- oder JAR-Datei-Container aus dem Dateisystem. Dies führt normalerweise nicht dazu, zu viel Arbeitsspeicher-Overhead führen: Wenn DEX-Dateien im Container komprimiert kann die Plattform einen mmap-Vorgang an ihnen ausführen, anstatt bei der die Daten direkt extrahiert werden. Wenn die Plattform jedoch die DEX-Datei aus dem Container extrahieren muss, auf eine solche Weise auf eine DEX-Datei verweisen.

In Android gelten alle Klassenladeprogramme als parallel-fähig. Wenn mehrere Threads dieselbe Klasse mit derselben Klasse laden Der erste Thread zum Abschließen des Vorgangs gewinnt und das Ergebnis wird für den anderen Threads. Dieses Verhalten tritt unabhängig davon auf, ob das Klassenladeprogramm dieselbe Klasse zurückgegeben, eine andere Klasse zurückgegeben oder eine Ausnahme ausgelöst hat. Solche Ausnahmen werden von der Plattform ignoriert.

Achtung : In Versionen der Plattform als Android 8.0 (API-Level 26). Wenn diese Annahmen nicht erfüllt sind, kann das dazu führen, und Heap-Beschädigungen durch Klassenverwirrungen, und andere unerwünschte Effekte.