Verhaltensänderungen unter Android 7.0

Neben den neuen Funktionen bietet Android 7.0 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.

Wenn Sie bereits eine App für Android veröffentlicht haben, von diesen Änderungen auf der Plattform betroffen sein können.

Akku und Arbeitsspeicher

Unter Android 7.0 wurde das Systemverhalten geändert, um die Akkulaufzeit zu verbessern und die RAM-Nutzung reduzieren. Diese Änderungen können sich auf den Zugriff Ihrer App auf Systemressourcen und die Art und Weise, wie Ihre App über bestimmte implizite Intents.

Stromsparmodus

Der Stromsparmodus wurde mit Android 6.0 (API-Level 23) eingeführt und verbessert die Akkulaufzeit um CPU- und Netzwerkaktivitäten verzögern, wenn ein Nutzer ein Gerät vom Stromnetz getrennt lässt, stehen fest und der Bildschirm ist ausgeschaltet. Android 7.0 Verbesserungen am Stromsparmodus durch Anwendung eines Teils der CPU- und Netzwerkbeschränkungen wenn das Gerät bei ausgeschaltetem Bildschirm vom Stromnetz getrennt ist, aber nicht unbedingt unbeweglich bleiben, z. B. wenn ein Mobiltelefon in der Tasche eines Nutzers getragen wird.

Illustration, die zeigt, wie der Stromsparmodus eine erste Einschränkungen der Systemaktivität zur Verbesserung der Akkulaufzeit

Abbildung 1: Illustration, die zeigt, wie der Stromsparmodus eine erste Systemaktivität einschränken, um die Akkulaufzeit zu verlängern.

Wenn ein Gerät im Akkubetrieb ist und das Display für eine bestimmte Zeit wechselt das Gerät in den Stromsparmodus und wendet die erste Teilmenge der Einschränkungen an: bricht den Netzwerkzugriff der App ab und verschiebt Jobs und Synchronisierungen. Wenn das Gerät eine bestimmte Zeit nach dem Einschalten des Stromsparmodus nicht aktiv ist, wendet das System Rest der Stromsparbeschränkungen für PowerManager.WakeLock, AlarmManager Alarme, GPS- und WLAN-Scans. Unabhängig von unabhängig davon, ob einige oder alle Stromsparbeschränkungen gelten, aktiviert das System den Gerät für kurze Wartungsfenster, in denen Anwendungen erlaubt sind Netzwerkzugriff und kann ausgesetzte Jobs/Synchronisierungen ausführen.

Illustration, die zeigt, wie der Stromsparmodus eine zweite Einschränkungen der Systemaktivität, nachdem das Gerät eine bestimmte Zeit lang nicht verwendet wurde

Abbildung 2: Illustration, die zeigt, wie der Stromsparmodus eine zweite Einschränkungen der Systemaktivität, nachdem das Gerät eine bestimmte Zeit lang nicht verwendet wurde.

Beachte, dass durch das Aktivieren des Bildschirms oder durch Einstecken des Geräts der Stromsparmodus beendet und diese Verarbeitungsbeschränkungen entfernt. Das zusätzliche Verhalten Empfehlungen und Best Practices bei der Anpassung Ihrer App an die bisherigen in Android 6.0 (API-Level 23) eingeführt, wie in den <ph type="x-smartling-placeholder"></ph> Optimierung für Stromsparmodus und App-Stand-by Sie sollten trotzdem Folgen Sie diesen Empfehlungen, um z. B. Firebase Cloud Messaging (FCM) zu verwenden, Nachrichten zu senden und zu empfangen, und beginnen Sie mit der Planung von Aktualisierungen, um die zusätzlichem Stromsparmodus.

Projekt Svelte: Hintergrundoptimierungen

Unter Android 7.0 werden drei implizite Broadcasts entfernt, um beide zu optimieren. die Arbeitsspeichernutzung und den Stromverbrauch. Diese Änderung ist notwendig, da implizite Broadcast-Nachrichten starten häufig Apps, die für das Abhören registriert sind. im Hintergrund. Wenn du diese Nachrichten entfernst, kann das Gerät erheblich davon profitieren und Nutzererfahrung zu verbessern.

Bei Mobilgeräten ändert sich die Verbindung häufig, z. B. wenn Sie umziehen. zwischen WLAN und mobilen Daten. Derzeit können Apps Änderungen in durch Registrieren eines Empfängers für den impliziten CONNECTIVITY_ACTION-Broadcast in der Manifests. Da sich viele Apps für den Empfang dieser Übertragung registrieren, wird eine einzelne Ein Netzwerkwechsel kann dazu führen, dass alle Geräte aufgeweckt werden und die Übertragung einmal.

In früheren Android-Versionen konnten Apps auch so registriert werden, dass sie implizite ACTION_NEW_PICTURE- und ACTION_NEW_VIDEO-Broadcasts von anderen Apps empfangen, darunter: Kamera. Wenn ein Nutzer ein Bild mit der Kamera App aufnimmt, wird der Ruhemodus dieser Apps beendet die Übertragung zu verarbeiten.

Um diese Probleme zu beheben, wird in Android 7.0 Folgendes angewendet: Optimierungen:

Wenn Ihre App einen dieser Intents verwendet, sollten Sie Abhängigkeiten entfernen , damit Sie Ihre Anzeigen auf Geräte mit Android 7.0 ausrichten können. Das Android-Framework bietet mehrere Lösungen, um die Notwendigkeit impliziten Broadcasts. Die JobScheduler API bietet beispielsweise einen robusten Mechanismus zum Planen unter bestimmten Bedingungen, wie z. B. die Verbindung zu einem kostenlosen WLANs erfüllt sind. Du kannst sogar JobScheduler verwenden, um auf Änderungen von Contentanbietern zu reagieren.

Weitere Informationen zu Hintergrundoptimierungen in Android 7.0 (API-Ebene) 24) und wie Sie Ihre App anpassen können, siehe Hintergrund Optimierungen:

Berechtigungsänderungen

Unter Android 7.0 wurden Änderungen an Berechtigungen vorgenommen, die sich auf deine App auswirken können.

Änderungen der Berechtigungen des Dateisystems

Um die Sicherheit privater Dateien zu erhöhen, ist das private Verzeichnis Für Apps, die auf Android 7.0 oder höher ausgerichtet sind, ist der Zugriff eingeschränkt (0700). Diese Einstellung verhindert Datenlecks von privaten Dateien, z. B. ihre Größe. oder Existenz. Diese Änderung der Berechtigung hat mehrere Auswirkungen:

Dateien zwischen Apps teilen

Für Apps, die auf Android 7.0 ausgerichtet sind, erzwingt das Android-Framework Die API-Richtlinie StrictMode, die die Offenlegung von file://-URIs unterbindet außerhalb Ihrer App. Wenn ein Intent mit einem Datei-URI die Anwendung verlässt, schlägt die Anwendung fehl mit der Ausnahme FileUriExposedException.

Wenn du Dateien zwischen Anwendungen teilen möchtest, musst du einen content://-URI senden und gewähren Sie eine temporäre Zugriffsberechtigung für den URI. Am einfachsten erteilen Sie diese Berechtigung, indem Sie mithilfe der Klasse FileProvider. Weitere Informationen zu Berechtigungen und zur Dateifreigabe, Weitere Informationen finden Sie unter Dateien freigeben.

Verbesserte Bedienungshilfen

Unter Android 7.0 wurden Änderungen vorgenommen, um die Nutzerfreundlichkeit der für Nutzende mit eingeschränkter Sehfähigkeit. Diese Änderungen sollten sind in der Regel keine Codeänderungen in Ihrer App erforderlich. Sie sollten sich jedoch und testen Sie sie mit Ihrer App, um potenzielle Auswirkungen auf die Nutzererfahrung.

Bildschirmzoom

Unter Android 7.0 können Nutzer die Anzeigegröße festlegen, oder verkleinert alle Elemente auf dem Bildschirm, wodurch die Barrierefreiheit des Geräts verbessert wird. mit eingeschränktem Sehvermögen. Nutzer können den Bildschirm nicht über die minimale Bildschirmgröße hinaus zoomen. Breite von sw320dp: Dies ist die Breite eines Nexus 4, einem gebräuchlichen mittelgroßen Smartphone.

Bildschirm, auf dem ein Gerät mit einem Android 7.0-Systemimage ohne Zoomen angezeigt wird
Bildschirm, auf dem ein Gerät mit einem Android 7.0-Systemimage angezeigt wird, wenn sich die Anzeigegröße erhöht

Abbildung 3: Auf dem Bildschirm rechts sehen Sie, Die Anzeigegröße eines Geräts mit einem Android 7.0-System-Image erhöhen

Wenn sich die Gerätedichte ändert, benachrichtigt das System laufende Apps im auf folgende Arten:

  • Wenn eine App auf API-Level 23 oder niedriger ausgerichtet ist, beendet das System automatisch all der Hintergrundprozesse. Das bedeutet, wenn Nutzende über eine solche App den Bildschirm Einstellungen öffnen und die Anzeigegröße eingestellt haben, beendet das System die App im selben wie in einer Situation mit wenig Arbeitsspeicher. Wenn die App einen Vordergrund hat verarbeitet das System diese Prozesse über die Konfigurationsänderung wie unter Handhabung der Laufzeitänderungen angezeigt wird, als ob sich die Ausrichtung des Geräts geändert hätte.
  • Wenn eine App auf Android 7.0 ausgerichtet ist, (Vorder- und Hintergrund) werden wie folgt über die Konfigurationsänderung informiert, wie unter Handhabung der Laufzeitänderungen.

Bei den meisten Apps sind zur Unterstützung dieser Funktion keine Änderungen erforderlich, sofern dass die Apps den Best Practices für Android entsprechen. Überprüfen Sie Folgendes:

  • App auf einem Gerät mit einer Bildschirmbreite von sw320dp testen und sicherzustellen, dass sie eine angemessene Leistung erbringen.
  • Wenn sich die Gerätekonfiguration ändert, dichteabhängige Änderungen Informationen wie im Cache gespeicherte Bitmaps oder Ressourcen, die vom Netzwerk. Prüfen Sie, ob sich Konfigurationsänderungen ergeben, wenn die App über die pausierte App fortgesetzt wird. Bundesstaat.

    Hinweis:Wenn Sie konfigurationsabhängige Daten im Cache speichern, ist es eine sollten Sie relevante Metadaten wie den Bildschirm Größe oder Pixeldichte dieser Daten. Das Speichern dieser Metadaten ermöglicht dir Folgendes: Entscheiden, ob die im Cache gespeicherten Daten nach einer Konfiguration aktualisiert werden müssen ändern können.

  • Vermeiden Sie die Angabe von Abmessungen mit Pixel-Einheiten, da diese nicht mit skaliert werden. Bildschirmdichte. Legen Sie stattdessen Dimensionen mit dichteunabhängigen Pixel (dp) Einheiten.

Vision-Einstellungen im Einrichtungsassistenten

Unter Android 7.0 finden Nutzer auf dem Begrüßungsbildschirm Einstellungen für Sehbehinderte, die folgenden Einstellungen für Bedienungshilfen auf einem neuen Gerät einrichten: Vergrößerungsbewegung, Schriftgröße, Anzeigegröße und TalkBack Diese Änderung erhöht die Sichtbarkeit von Fehlern im Zusammenhang mit verschiedenen Bildschirmeinstellungen. Bis um die Auswirkungen dieser Funktion zu bewerten, sollten Sie Ihre Apps aktiviert sind. Du findest die Einstellungen unter Einstellungen > Bedienungshilfen:

Verknüpfung von NDK-Apps mit Plattformbibliotheken

Ab Android 7.0 verhindert das System, dass Apps dynamisch verknüpft werden für Bibliotheken ohne NDK, was zum Absturz deiner App führen kann. Diese Änderung bei Ziel des Nutzerverhaltens ist es, bei allen Plattformupdates ein einheitliches App-Erlebnis zu schaffen. und verschiedenen Geräten. Auch wenn Ihr Code möglicherweise keine privaten Bibliotheken gibt, ist es möglich, dass die statische Bibliothek eines Drittanbieters die App nutzen könnte. Daher sollten alle Entwickler prüfen, dass ihre Apps auf Geräten mit Android 7.0 nicht abstürzen. Wenn Ihre App nativem Code verwenden, sollten Sie nur öffentliche NDK APIs verwenden.

Es gibt drei Möglichkeiten, wie Ihre App versucht, auf eine private Plattform zuzugreifen APIs:

  • Ihre App greift direkt auf Bibliotheken der privaten Plattform zu. Sie sollten Ihre App, um eine eigene Kopie dieser Bibliotheken hinzuzufügen, oder verwenden Sie die öffentlichen NDK APIs.
  • Deine App verwendet eine Drittanbieterbibliothek, die auf eine private Plattform zugreift Bibliotheken. Selbst wenn Sie sicher sind, dass Ihre App nicht auf private Bibliotheken zugreift sollten Sie Ihre App trotzdem für dieses Szenario testen.
  • Deine App verweist auf eine Bibliothek, die nicht in ihrem APK enthalten ist. Für Beispiel: Sie versuchen, Ihre eigene OpenSSL-Version zu verwenden, das Paket mit dem APK Ihrer App zu bündeln. Die App funktioniert möglicherweise unter Versionen ganz normal. der Android-Plattform, zu der libcrypto.so gehört. Die App kann bei neueren Android-Versionen, die diese Bibliothek nicht enthalten, abstürzen. (z. B. Android 6.0 und höher). Um das Problem zu beheben, bündeln Sie mit Ihrem APK aus Ihren Nicht-NDK-Bibliotheken entfernen.

Anwendungen sollten keine nativen Bibliotheken verwenden, die nicht im NDK enthalten sind. Sie können bei verschiedenen Android-Versionen geändert oder entfernt werden. Die der Wechsel von OpenSSL zu BoringSSL ist ein Beispiel für eine solche Änderung. Außerdem da es keine Kompatibilitätsanforderungen für Plattformbibliotheken gibt, im NDK enthalten sind, können verschiedene Geräte unterschiedliche Kompatibilität.

Um die Auswirkungen dieser Einschränkung veröffentlichter Apps, einer Reihe von Bibliotheken, die häufig verwendet werden, z. B. libandroid_runtime.so, libcutils.so, libcrypto.so und libssl.so werden vorübergehend verfügbar unter Android 7.0 (API-Level 24) für Apps, die auf API-Level 23 oder darunter. Wenn Ihre App eine dieser Bibliotheken lädt, generiert Logcat eine Warnung und auf dem Zielgerät erscheint ein Toast, um Sie zu benachrichtigen. Wenn Sie diese Warnungen enthält, sollten Sie Ihre App so aktualisieren, dass entweder eine eigene Kopie dieser Bibliotheken verwenden oder nur die öffentlichen NDK APIs verwenden. Künftige Releases von Android die Nutzung privater Bibliotheken komplett einschränken und dazu führen, App abgestürzt.

Alle Anwendungen generieren einen Laufzeitfehler, wenn sie eine API aufrufen, die weder oder vorübergehend zugänglich sind. Das Ergebnis ist, dass System.loadLibrary und dlopen(3) kehren beide zurück NULL und kann zum Absturz deiner App führen. Sie sollten Ihre App-Code, um die Verwendung von APIs der privaten Plattform zu unterbinden und deine Apps gründlich zu testen über ein Gerät oder einen Emulator mit Android 7.0 (API-Level 24). Wenn Sie Wenn Sie sich nicht sicher sind, ob Ihre Anwendung private Bibliotheken verwendet, können Sie logcat prüfen, um den Laufzeitfehler zu ermitteln.

In der folgenden Tabelle wird das Verhalten beschrieben, das Sie bei einer App abhängig von ihrer Verwendung privater nativer Bibliotheken und ihrer Ziel-API Stufe (android:targetSdkVersion).

Bibliotheken Ziel-API-Level Laufzeitzugriff über dynamische Verknüpfung Verhalten von Android 7.0 (API-Level 24) Zukünftiges Verhalten der Android-Plattform
NDK Public Zugänglich Funktioniert wie erwartet Funktioniert wie erwartet
Private (vorübergehend zugängliche private Bibliotheken) 23 oder niedriger Vorübergehend zugänglich Funktioniert wie erwartet, Sie erhalten jedoch eine Logcat-Warnung. Laufzeitfehler
Private (vorübergehend zugängliche private Bibliotheken) 24 oder höher Eingeschränkt Laufzeitfehler Laufzeitfehler
Privat (Sonstiges) Eingeschränkt Laufzeitfehler Laufzeitfehler

Prüfen, ob Ihre App private Bibliotheken verwendet

Zur Unterstützung bei der Identifizierung von Problemen beim Laden privater Bibliotheken Warnung oder Laufzeitfehler. Wenn Ihre App beispielsweise auf API-Level 23 oder und versucht auf einem Gerät mit Android 7.0, auf eine private Bibliothek zuzugreifen, wird eine Warnung wie diese angezeigt: 

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Diese Logcat-Warnungen informieren Sie darüber, welche Bibliothek versucht, auf eine Private Platform API, führt aber nicht zum Absturz Ihrer App. Wenn die App auf API-Level 24 oder höher ausgerichtet. Logcat generiert jedoch Folgendes: Laufzeitfehler und deine App kann abstürzen: 

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

Diese Logcat-Ausgaben können auch angezeigt werden, wenn in Ihrer App Bibliotheken von Drittanbietern verwendet werden die dynamisch mit den APIs der privaten Plattform verknüpft sind. Das Readelf-Tool in der Mit Android 7.0DK können Sie eine Liste aller dynamisch verknüpften freigegebenen einer bestimmten .so-Datei durch Ausführen des folgenden Befehls: 

aarch64-linux-android-readelf -dW libMyLibrary.so

App aktualisieren

Mit den folgenden Schritten können Sie diese Fehler beheben und dafür sorgen, dass Ihre App bei zukünftigen Plattformupdates nicht abstürzt:

  • Wenn Ihre App private Plattformbibliotheken verwendet, sollten Sie sie aktualisieren, um eine eigene Kopie dieser Bibliotheken erstellen oder die öffentlichen NDK APIs verwenden.
  • Wenn in Ihrer App eine Bibliothek eines Drittanbieters auf private Symbole zugegriffen wird, wenden Sie sich an um die Bibliothek zu aktualisieren.
  • Achten Sie darauf, dass Sie alle Nicht-NDK-Bibliotheken mit Ihrem APK verpacken.
  • Verwenden Sie Standard-JNI-Funktionen anstelle von getJavaVM und getJNIEnv von libandroid_runtime.so: 
    AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.
  • __system_property_get anstelle des privaten property_get verwenden Symbol von libcutils.so. Verwenden Sie dazu __system_property_get. Dazu gehören: 
    #include <sys/system_properties.h>

    Hinweis: Die Verfügbarkeit und der Inhalt der Systemeigenschaften nicht durch CTS getestet. Eine bessere Lösung wäre, diese Propertys insgesamt.

  • Verwende eine lokale Version des SSL_ctrl-Symbols von libcrypto.so. Beispielsweise sollten Sie libcyrpto.a statisch verknüpfen in deine .so-Datei an oder füge eine dynamisch verknüpfte Version von libcrypto.so von BoringSSL/OpenSSL ein und verpacke sie in dein APK.

Android for Work

Android 7.0 enthält Änderungen für Apps, die auf Android for Work ausgerichtet sind, darunter Änderungen an Zertifikatinstallation, Passwortzurücksetzung, sekundärer Nutzer Verwaltung und Zugriff auf Gerätekennungen. Wenn Sie Apps für Android for Work-Umgebungen überprüfen und anpassen Ihre App entsprechend anpassen.

  • Sie müssen ein delegiertes Zertifikat-Installationsprogramm installieren, bevor der DPC festlegen kann . Für Apps von Profil- und Geräteeigentümern, die auf Android 7.0 (API-Level 24) ausgerichtet sind, sollten Sie das Installationsprogramm für delegierte Zertifikate vor den Geräterichtlinien installieren. Controller-Aufrufe (DPC-Aufrufe) DevicePolicyManager.setCertInstallerPackage() Wenn der Installateur nicht bereits installiert ist, gibt das System eine IllegalArgumentException
  • Passwortbeschränkungen für Geräteadministratoren zurücksetzen, gelten jetzt auch für Profile Verantwortlichen. Geräteadministratoren können DevicePolicyManager.resetPassword(), um Passwörter zu löschen oder zu ändern bereits festgelegte. Geräteadministratoren können weiterhin ein Passwort festlegen, wenn das Gerät kein Passwort, keine PIN und kein Muster hat.
  • Geräte- und Profilinhaber können Konten auch dann verwalten, wenn dies beschränkt ist festgelegt. Geräte- und Profilinhaber können die Account Management APIs aufrufen auch wenn DISALLOW_MODIFY_ACCOUNTS-Nutzerbeschränkungen gelten.
  • Geräteeigentümer können sekundäre Nutzer einfacher verwalten. Wenn ein Gerät wird im Modus „Geräteeigentümer“ ausgeführt, die Einschränkung „DISALLOW_ADD_USER“ automatisch festgelegt. Dadurch wird verhindert, dass Nutzer eine nicht verwaltete sekundäre Gruppe erstellen Nutzenden. Außerdem werden die CreateUser() und createAndInitializeUser()-Methoden wurden verworfen. das neue Sie werden durch die Methode DevicePolicyManager.createAndManageUser() ersetzt.
  • Geräteeigentümer können auf Geräte-IDs zugreifen. Ein Geräteeigentümer kann auf WLAN-MAC-Adresse eines Geräts, mit DevicePolicyManager.getWifiMacAddress() Wenn das WLAN noch nie aktiviert wurde, gibt diese Methode den Wert null zurück.
  • Mit der Einstellung „Arbeitsmodus“ wird der Zugriff auf geschäftliche Apps gesteuert. Wenn der Arbeitsmodus deaktiviert ist, System Launcher zeigt an, dass geschäftliche Apps nicht verfügbar sind, indem sie ausgegraut sind. Wird aktiviert stellt den Arbeitsmodus wieder das normale Verhalten wieder her.
  • Wenn Sie eine PKCS #12-Datei mit einer Clientzertifikatskette und den entsprechenden privaten Schlüssel aus der UI für Einstellungen, das CA-Zertifikat im nicht mehr im Speicher für vertrauenswürdige Anmeldedaten installiert. Das bedeutet, wirken sich nicht auf das Ergebnis von KeyChain.getCertificateChain() aus, wenn Apps versuchen, den Client abzurufen Zertifikatkette ein. Falls erforderlich, sollte das CA-Zertifikat installiert werden über die Einstellungsbenutzeroberfläche auf den Speicher für vertrauenswürdige Anmeldedaten, DER-codiertes Format mit der Dateiendung CRT oder CER.
  • Ab Android 7.0 werden die Registrierung und Speicherung per Fingerabdruck verwaltet pro Nutzer*in. Wenn der Device Policy Client (DPC) eines Profilinhabers auf das API-Level ausgerichtet ist 23 (oder niedriger) auf einem Gerät mit Android 7.0 (API-Level 24) ist, hat der Nutzer Ich kann immer noch den Fingerabdruck auf dem Gerät einrichten, geschäftliche Apps jedoch nicht auf den Fingerabdruck des Geräts zugreifen. Wenn der DPC auf API-Level 24 und höher ausgerichtet ist, kann der Nutzer Folgendes festlegen: speziell für das Arbeitsprofil. Rufen Sie dazu Einstellungen > Sicherheit > Sicherheit des Arbeitsprofils.
  • Der neue Verschlüsselungsstatus ENCRYPTION_STATUS_ACTIVE_PER_USER ist zurückgegeben von DevicePolicyManager.getStorageEncryptionStatus() an dass die Verschlüsselung aktiv und der Verschlüsselungsschlüssel an die Nutzer. Der neue Status wird nur zurückgegeben, wenn DPC auf API-Level 24 und höher ausgerichtet ist. Für Apps, die auf frühere API-Level ausgerichtet sind, ENCRYPTION_STATUS_ACTIVE zurückgegeben, auch wenn der Verschlüsselungsschlüssel nutzer- oder profilspezifisch ist.
  • In Android 7.0 gibt es mehrere Methoden, die normalerweise die gesamte wie das Gerät funktioniert, wenn auf dem Gerät ein Arbeitsprofil mit einer separate Work-Challenge. Diese wirken sich nicht auf das gesamte Gerät aus, nur für das Arbeitsprofil gelten. (Die vollständige Liste dieser Methoden finden Sie in der DevicePolicyManager.getParentProfileInstance()-Dokumentation. Beispiel: DevicePolicyManager.lockNow() sperrt nur das Arbeitsprofil das gesamte Gerät zu sperren. Für jede dieser Methoden können Sie das alte durch Aufrufen der -Methode für die übergeordnete Instanz der DevicePolicyManager; Sie erhalten dieses übergeordnete Element, indem Sie DevicePolicyManager.getParentProfileInstance() wird angerufen. Wenn Sie beispielsweise lockNow() der übergeordneten Instanz wird das gesamte Gerät gesperrt.

Aufbewahrung von Anmerkungen

In Android 7.0 wurde ein Fehler behoben, bei dem die Sichtbarkeit von Anmerkungen ignoriert wurde. Durch dieses Problem konnte die Laufzeit auf Anmerkungen zugreifen, die nicht hätte sein sollen Zu diesen Annotationen gehörten:

  • VISIBILITY_BUILD: Soll nur während der Build-Erstellung sichtbar sein.
  • VISIBILITY_SYSTEM: Soll zur Laufzeit sichtbar sein, aber nur für den zugrunde liegendes System.

Wenn sich deine App auf dieses Verhalten stützt, füge den Anmerkungen bitte eine Aufbewahrungsrichtlinie hinzu, die während der Laufzeit verfügbar sein. Verwenden Sie dazu @Retention(RetentionPolicy.RUNTIME).

Änderungen der TLS/SSL-Standardkonfiguration

Android 7.0 nimmt folgende Änderungen an der TLS/SSL-Standardkonfiguration vor Wird von Apps für HTTPS- und anderen TLS/SSL-Traffic verwendet:

  • RC4-Cipher Suites sind jetzt deaktiviert.
  • CHACHA20-POLY1305-Cipher Suites sind jetzt aktiviert.

Die standardmäßige Deaktivierung von RC4 kann zu Fehlern bei HTTPS oder TLS/SSL führen. Konnektivität, wenn der Server keine modernen Cipher Suites aushandelt. Die bevorzugte Lösung besteht darin, die Konfiguration des Servers zu verbessern, um eine stärkere und modernere Cipher Suites und Protokolle. Idealerweise sollten TLSv1.2 und AES-GCM aktiviert sein und Forward Secrecy Cipher Suites (ECDHE) sollte aktiviert und bevorzugt werden.

Alternativ können Sie die Anwendung so ändern, dass sie eine benutzerdefinierte SSLSocketFactory für die Kommunikation mit dem Server verwendet. Die sollte so konzipiert sein, dass SSLSocket Instanzen mit einigen der vom Server benötigten Chiffresammlungen neben den Standard-Cipher Suites aktiviert.

Hinweis: Diese Änderungen betreffen nicht WebView.

Apps für Android 7.0

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

Änderungen der Serialisierung

Unter Android 7.0 (API-Level 24) wurde ein Fehler bei der Berechnung des Standardwerts behoben. serialVersionUID, wenn sie nicht der Spezifikation entsprach.

Klassen, die Serializable implementieren und kein explizites serialVersionUID-Feld angeben, eine Änderung ihrer Standard-serialVersionUID sehen, was zu einer Ausnahme ausgegeben werden, wenn versucht wird, Instanzen der Klasse zu deserialisieren, die oder einer App, die auf eine frühere Version ausgerichtet ist, Version. Die Fehlermeldung sieht in etwa so aus: 

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Um diese Probleme zu beheben, muss ein serialVersionUID-Feld alle betroffenen Klassen mit dem Wert stream classdesc serialVersionUID aus der Fehlermeldung, z.B. 1234 Zoll in diesem Fall. Diese Änderung entspricht allen Best Practices-Empfehlungen für Serialisierungscode schreiben und funktioniert auf allen Android-Versionen.

Der spezifische Fehler, der behoben wurde, betraf statische Initialisierungsmethoden, z.B. <clinit>. Gemäß den gibt an, ob eine statische Initialisierungsmethode im hat Einfluss auf den für diese Klasse berechneten Standardwert serialVersionUID. Vor der Fehlerbehebung würde die Berechnung auch die Super-Klasse auf eine statischer Initialisierer, wenn es für eine Klasse keinen gibt.

Zur Klarstellung: Diese Änderung hat keine Auswirkungen auf Apps, die auf API-Level 23 oder niedrigere, Klassen mit einem serialVersionUID-Feld oder Klassen statische Initialisierungsmethode.

Weitere wichtige Punkte

  • Wenn eine App unter Android 7.0 läuft, aber auf eine niedrigere API-Ebene abzielt, und der Nutzer die Anzeigegröße ändert, wird der App-Prozess beendet. Die App mit diesem Szenario umgehen können. Andernfalls stürzt es ab. Der Nutzer stellt sie aus „Recents“ (Zuletzt verwendet) wieder her.

    Sie sollten Ihre App testen, dass dieses Verhalten nicht auftritt. Sie können einen identischen Absturz verursachen, wenn die App manuell über DDMS beendet wird.

    Apps, die auf Android 7.0 (API-Level 24) und höher ausgerichtet sind, werden nicht automatisch bei Dichteänderungen abgebremst, Allerdings reagieren sie möglicherweise immer noch schlecht auf Konfigurationsänderungen.

  • Apps unter Android 7.0 sollten Konfigurationsänderungen problemlos verarbeiten können, und sollte bei nachfolgenden Starts nicht abstürzen. Sie können das App-Verhalten prüfen indem Sie die Schriftgröße (Einstellungen > Displaynetzwerk > Schriftgröße) und stellen Sie dann die die App unter „Letzte“.
  • Aufgrund eines Fehlers in früheren Android-Versionen hat das System das Schreiben als Verstoß im strikten Modus zu einem TCP-Socket im Hauptthread hinzu. Android 7.0 behebt diesen Fehler. Apps mit diesem Verhalten geben jetzt eine android.os.NetworkOnMainThreadException aus. Im Allgemeinen ist die Durchführung von Netzwerkvorgängen auf dem Hauptthread keine gute Idee, da diese Vorgänge haben in der Regel eine hohe Latenz, die zu ANR-Fehlern und Verzögerungen führt.
  • Für die Methodenfamilie Debug.startMethodTracing() wird jetzt standardmäßig Folgendes verwendet: Speichern der Ausgabe in Ihrem paketspezifischen Verzeichnis im freigegebenen Speicher statt auf oberster Ebene, der SD-Karte ein. Das bedeutet, dass Apps die Berechtigung WRITE_EXTERNAL_STORAGE nicht mehr anfordern müssen, um diese APIs zu verwenden.
  • Viele Plattform-APIs haben jetzt damit begonnen, zu prüfen, ob große Nutzlasten gesendet werden für Binder-Transaktionen gibt das System jetzt TransactionTooLargeExceptions als RuntimeExceptions, anstatt sie automatisch zu protokollieren oder zu unterdrücken. Eins ist beispielsweise das Speichern von zu vielen Daten Activity.onSaveInstanceState(), wodurch ActivityThread.StopInfo den Fehler RuntimeException, wenn deine App auf Android 7.0 ausgerichtet ist.
  • Wenn eine App Runnable Aufgaben an eine View postet und View nicht an einem Fenster angebracht ist, stellt die Aufgabe Runnable mit View in eine Warteschlange. wird die Aufgabe Runnable erst ausgeführt, View ist angehängt in einem Fenster. Dadurch werden folgende Fehler behoben: <ph type="x-smartling-placeholder">
      </ph>
    • Wenn eine App in einem View aus einem anderen Thread als der beabsichtigten gepostet wurde des UI-Threads ist, wird Runnable daher möglicherweise im falschen Thread ausgeführt.
    • Wenn die Aufgabe „Runnable“ in einem anderen Thread gepostet wurde als einen Looper-Thread enthält, könnte die Anwendung die Runnable-Aufgabe freigeben.
  • Wenn eine App unter Android 7.0 mit DELETE_PACKAGES versucht, ein Paket zu löschen, obwohl das Paket von einer anderen App installiert wurde, erfordert das System eine Nutzerbestätigung. In diesem Szenario sollten Apps STATUS_PENDING_USER_ACTION als Rückgabestatus festlegen, wenn sie PackageInstaller.uninstall().
  • Der JCA-Anbieter Crypto wurde eingestellt, da er SHA1PRNG kryptografisch schwach ist. Apps dürfen nicht mehr verwenden SHA1PRNG zum (unsicheren) Ableiten von Schlüsseln verwenden, da dieser Anbieter verfügbar. Weitere Informationen findest du im Blog Post Sicherheit „Crypto“ Anbieter in Android eingestellt N.