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](https://developer.android.com/static/images/android-7.0/doze-diagram-1.png?authuser=9&hl=de)
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](https://developer.android.com/static/images/android-7.0/doze-diagram-2.png?authuser=9&hl=de)
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:
- Apps, die auf Android 7.0 (API-Level 24) und höher ausgerichtet sind, erhalten keine
CONNECTIVITY_ACTION
sendet eine Nachricht, wenn sie den Empfänger im Manifest deklarieren. Apps werden weiterhinCONNECTIVITY_ACTION
Broadcasts empfangen, wenn sie sich registrierenBroadcastReceiver
mitContext.registerReceiver()
und dieser Kontext ist immer noch gültig. - Das System sendet keine
ACTION_NEW_PICTURE
- oderACTION_NEW_VIDEO
-Nachrichten mehr. Diese Optimierung betrifft alle Apps, nicht nur die für Android 7.0.
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:
-
Die Berechtigungen für private Dateien sollten nicht mehr vom Eigentümer aufgehoben werden.
und versuchen, dies mit
MODE_WORLD_READABLE
und/oderMODE_WORLD_WRITEABLE
, löst einenSecurityException
Hinweis:Diese Einschränkung wurde noch nicht vollständig erzwungen. Apps können die Berechtigungen für ihr privates Verzeichnis weiterhin mit native APIs oder die
File
API. Wir empfehlen Ihnen jedoch, Sie raten davon ab, die Berechtigungen für das private Verzeichnis zu lockern. -
Bei der Übergabe von
file://
-URIs außerhalb der Paketdomain kann das Attribut Empfänger mit einem unzugänglichen Pfad. Daher wird versucht, einefile://
-URI löst einen ausFileUriExposedException
. Die empfohlene Methode zum Teilen Inhalt einer privaten Datei verwendetFileProvider
. -
DownloadManager
kann keine private Freigabe mehr vornehmen Dateien nach Dateinamen sortiert. Legacy-Anwendungen können am Ende ein Pfad beim Zugriff aufCOLUMN_LOCAL_FILENAME
nicht zugänglich App-Targeting Android 7.0 oder höher lösen einSecurityException
aus, wenn versuchen, aufCOLUMN_LOCAL_FILENAME
. Legacy-Anwendungen, bei denen als Downloadpfad ein öffentlicher Speicherort festgelegt wurde. mitDownloadManager.Request.setDestinationInExternalFilesDir()
oderDownloadManager.Request.setDestinationInExternalPublicDir()
weiterhin auf den Pfad inCOLUMN_LOCAL_FILENAME
jedoch, wird dringend davon abgeraten. Die bevorzugte Methode für den Zugriff auf eine Datei vonDownloadManager
bereitgestelltContentResolver.openFileDescriptor()
.
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](https://developer.android.com/static/images/android-7.0/screen-zoom-1.png?authuser=9&hl=de)
![Bildschirm, auf dem ein Gerät mit einem Android 7.0-Systemimage angezeigt wird, wenn sich die Anzeigegröße erhöht](https://developer.android.com/static/images/android-7.0/screen-zoom-2.png?authuser=9&hl=de)
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
undgetJNIEnv
vonlibandroid_runtime.so
:AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h> AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or JavaVM::AttachCurrentThread from <jni.h>.
__system_property_get
anstelle des privatenproperty_get
verwenden Symbol vonlibcutils.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 vonlibcrypto.so
. Beispielsweise sollten Sielibcyrpto.a
statisch verknüpfen in deine.so
-Datei an oder füge eine dynamisch verknüpfte Version vonlibcrypto.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 eineIllegalArgumentException
- 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 dieCreateUser()
undcreateAndInitializeUser()
-Methoden wurden verworfen. das neue Sie werden durch die MethodeDevicePolicyManager.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 Wertnull
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 vonDevicePolicyManager.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 derDevicePolicyManager
; Sie erhalten dieses übergeordnete Element, indem SieDevicePolicyManager.getParentProfileInstance()
wird angerufen. Wenn Sie beispielsweiselockNow()
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 BerechtigungWRITE_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 jetztTransactionTooLargeExceptions
alsRuntimeExceptions
, anstatt sie automatisch zu protokollieren oder zu unterdrücken. Eins ist beispielsweise das Speichern von zu vielen DatenActivity.onSaveInstanceState()
, wodurchActivityThread.StopInfo
den FehlerRuntimeException
, wenn deine App auf Android 7.0 ausgerichtet ist. -
Wenn eine App
Runnable
Aufgaben an eineView
postet undView
nicht an einem Fenster angebracht ist, stellt die AufgabeRunnable
mitView
in eine Warteschlange. wird die AufgabeRunnable
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, wirdRunnable
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 dieRunnable
-Aufgabe freigeben.
- Wenn eine App in einem
-
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 AppsSTATUS_PENDING_USER_ACTION
als Rückgabestatus festlegen, wenn siePackageInstaller.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.