Neben neuen Funktionen und Möglichkeiten bietet Android 6.0 (API-Level 23) eine Vielzahl von Systemänderungen und Änderungen des API-Verhaltens. In diesem Dokument werden einige der wichtigsten Änderungen beschrieben, die Sie in Ihren Apps verstehen und berücksichtigen sollten.
Wenn du bereits eine App für Android veröffentlicht hast, solltest du beachten, dass sich diese Änderungen auf der Plattform auf deine App auswirken.
Laufzeitberechtigungen
Mit diesem Release wird ein neues Berechtigungsmodell eingeführt, mit dem Nutzer App-Berechtigungen jetzt direkt zur Laufzeit verwalten können. Dieses Modell bietet Nutzern eine bessere Transparenz und Kontrolle über Berechtigungen und vereinfacht gleichzeitig die Installations- und Aktualisierungsprozesse für App-Entwickler. Nutzer können Berechtigungen für installierte Apps einzeln erteilen oder widerrufen.
Prüfen Sie bei Ihren Apps, die auf Android 6.0 (API-Level 23) oder höher ausgerichtet sind, zur Laufzeit Berechtigungen und fordern Sie diese an. Wenn Sie feststellen möchten, ob Ihrer App eine Berechtigung gewährt wurde, rufen Sie die neue Methode checkSelfPermission()
auf. Wenn Sie eine Berechtigung anfordern möchten, rufen Sie die neue Methode requestPermissions()
auf. Auch wenn deine App nicht auf Android 6.0 (API-Level 23) ausgerichtet ist, solltest du sie mit dem neuen Berechtigungsmodell testen.
Weitere Informationen zur Unterstützung des neuen Berechtigungsmodells in Ihrer App finden Sie unter Mit Systemberechtigungen arbeiten. Tipps zur Bewertung der Auswirkungen auf Ihre App finden Sie unter Hinweise zur Nutzung von Berechtigungen.
Stromsparmodus und App-Standby
Dieser Release enthält neue Optimierungen zum Energiesparen für inaktive Geräte und Apps. Diese Funktionen gelten für alle Anwendungen. Testen Sie Ihre Anwendungen daher unbedingt in diesen neuen Modi.
- Stromsparmodus: Wenn ein Nutzer ein Gerät vom Stromnetz trennt und es bei ausgeschaltetem Display für eine bestimmte Zeit nicht bewegt, wird das Gerät in den Stromsparmodus versetzt. Dort wird versucht, das System in den Ruhemodus zu versetzen. In diesem Modus nehmen die Geräte für kurze Zeit den normalen Betrieb wieder auf, damit die App synchronisiert werden kann und das System alle ausstehenden Vorgänge ausführen kann.
- App-Standby: Mit App-Standby kann das System feststellen, dass eine App inaktiv ist, wenn der Nutzer sie nicht aktiv verwendet. Das System trifft dies zu, wenn der Nutzer die App über einen bestimmten Zeitraum nicht verwendet. Wenn das Gerät vom Stromnetz getrennt ist, deaktiviert das System den Netzwerkzugriff und hält Synchronisierungen und Jobs für die Apps an, die als inaktiv eingestuft werden.
Weitere Informationen zu diesen Änderungen zum Energiesparen finden Sie unter Optimierung für Stromsparmodus und App-Standby.
Entfernung von Apache HTTP-Clients
Android 6.0-Version entfernt die Unterstützung für den Apache HTTP-Client. Wenn deine App diesen Client verwendet und auf Android 2.3 (API-Level 9) oder höher ausgerichtet ist, verwende stattdessen die Klasse HttpURLConnection
. Diese API ist effizienter, da sie die Netzwerknutzung durch transparente Komprimierung und Antwort-Caching reduziert und den Energieverbrauch minimiert. Wenn Sie die Apache HTTP APIs weiterhin verwenden möchten, müssen Sie zuerst die folgende Kompilierungszeitabhängigkeit in der Datei build.gradle
deklarieren:
android { useLibrary 'org.apache.http.legacy' }
BoringSSL
Android wechselt von OpenSSL zur BoringSSL-Bibliothek. Wenn du das Android-NDK in deiner App verwendest, solltest du keine Verknüpfungen mit Kryptografiebibliotheken herstellen, die nicht Teil der NDK API sind, z. B. libcrypto.so
und libssl.so
. Diese Bibliotheken sind keine öffentlichen APIs und können über Releases und Geräte hinweg ohne vorherige Ankündigung geändert oder nicht mehr funktionieren.
Außerdem besteht die Gefahr, dass du Sicherheitslücken aussetzt. Ändern Sie stattdessen Ihren nativen Code so, dass die Java Cryptography APIs über JNI aufgerufen oder eine statische Verknüpfung mit einer Kryptografiebibliothek Ihrer Wahl hergestellt wird.
Zugriff auf Hardware-ID
Um den Datenschutz für Nutzer zu verbessern, entfernt Android ab dieser Version den programmatischen Zugriff auf die lokale Hardware-ID des Geräts für Apps, die die Wi-Fi und Bluetooth API verwenden. Die Methoden WifiInfo.getMacAddress()
und BluetoothAdapter.getAddress()
geben jetzt den konstanten Wert 02:00:00:00:00:00
zurück.
Damit deine App über Bluetooth und WLAN-Scans auf die Hardwarekennungen externer Geräte in der Nähe zugreifen kann, muss deine App jetzt die Berechtigungen ACCESS_FINE_LOCATION
oder ACCESS_COARSE_LOCATION
haben:
Hinweis: Wenn ein Gerät mit Android 6.0 (API-Level 23) einen WLAN- oder Bluetooth-Scan im Hintergrund startet, ist der Vorgang für externe Geräte sichtbar, als er von einer zufälligen MAC-Adresse stammt.
Benachrichtigungen
In diesem Release wird die Methode Notification.setLatestEventInfo()
entfernt. Verwenden Sie stattdessen die Klasse Notification.Builder
, um Benachrichtigungen zu erstellen. Wenn Sie eine Benachrichtigung wiederholt aktualisieren möchten, verwenden Sie die Instanz Notification.Builder
noch einmal. Rufen Sie die Methode build()
auf, um aktualisierte Notification
-Instanzen zu erhalten.
Der Befehl adb shell dumpsys notification
druckt Ihren Benachrichtigungstext nicht mehr aus.
Verwenden Sie stattdessen den Befehl adb shell dumpsys notification --noredact
, um den Text in einem Benachrichtigungsobjekt auszugeben.
Änderungen am AudioManager
Das direkte Festlegen der Lautstärke oder das Stummschalten bestimmter Streams über die Klasse AudioManager
wird nicht mehr unterstützt. Die Methode setStreamSolo()
wurde eingestellt. Rufen Sie stattdessen die Methode requestAudioFocus()
auf. Die Methode setStreamMute()
wurde ebenfalls verworfen. Rufen Sie stattdessen die Methode adjustStreamVolume()
auf und übergeben Sie den Richtungswert ADJUST_MUTE
oder ADJUST_UNMUTE
.
Textauswahl
Wenn Nutzer in Ihrer App Text auswählen, können Sie jetzt Aktionen zur Textauswahl wie Ausschneiden, Kopieren und Einfügen in einer unverankerten Symbolleiste anzeigen lassen. Die Implementierung der Nutzerinteraktion ähnelt der Implementierung der kontextbezogenen Aktionsleiste, wie unter Modus für kontextbezogene Aktionen für einzelne Ansichten aktivieren beschrieben.
Wenn Sie eine unverankerte Symbolleiste für die Textauswahl implementieren möchten, nehmen Sie in Ihren vorhandenen Apps die folgenden Änderungen vor:
- Ändern Sie im
View
- oderActivity
-Objekt dieActionMode
-Aufrufe vonstartActionMode(Callback)
instartActionMode(Callback, ActionMode.TYPE_FLOATING)
. - Verwenden Sie Ihre bestehende Implementierung von
ActionMode.Callback
und erweitern Sie sie stattdessen aufActionMode.Callback2
. - Überschreiben Sie die Methode
onGetContentRect()
, um die Koordinaten des Inhalts-Rect
-Objekts (z. B. ein Textauswahlrechteck) in der Ansicht bereitzustellen. - Wenn die Rechteckpositionierung nicht mehr gültig ist und dies das einzige Element ist, das entwertet werden muss, rufen Sie die Methode
invalidateContentRect()
auf.
Wenn Sie Version 22.2 der
Android Support Library verwenden, beachten Sie, dass unverankerte Symbolleisten nicht abwärtskompatibel sind und appcompat standardmäßig die Kontrolle über ActionMode
-Objekte übernimmt. Dadurch wird verhindert, dass unverankerte Symbolleisten angezeigt werden. Zum Aktivieren der ActionMode
-Unterstützung in einem AppCompatActivity
rufen Sie getDelegate()
auf, rufen dann setHandleNativeActionModesEnabled()
für das zurückgegebene AppCompatDelegate
-Objekt auf und legen den Eingabeparameter auf false
fest. Durch diesen Aufruf wird die Steuerung von ActionMode
-Objekten an das Framework zurückgegeben. Auf Geräten mit Android 6.0 (API-Level 23), auf denen das Framework ActionBar
oder unverankerte Symbolleisten unterstützt, werden auf Geräten mit Android 5.1 (API-Level 22) oder niedriger nur die ActionBar
-Modi unterstützt.
Änderungen an Lesezeichen im Browser
In dieser Version werden globale Lesezeichen nicht mehr unterstützt. Die Methoden android.provider.Browser.getAllBookmarks()
und android.provider.Browser.saveBookmark()
wurden entfernt. Außerdem werden die Berechtigungen READ_HISTORY_BOOKMARKS
und WRITE_HISTORY_BOOKMARKS
entfernt. Wenn Ihre App auf Android 6.0 (API-Level 23) oder höher ausgerichtet ist, dürfen Sie nicht auf Lesezeichen vom globalen Anbieter zugreifen und auch nicht die Berechtigungen für Lesezeichen verwenden. Stattdessen sollte Ihre App Lesezeichendaten intern speichern.
Änderungen an Android-Schlüsselspeicher
Ab diesem Release unterstützt der Android-Schlüsselspeicheranbieter DSA nicht mehr. ECDSA wird weiterhin unterstützt.
Schlüssel, die keine Verschlüsselung im Ruhezustand erfordern, werden nicht mehr gelöscht, wenn der sichere Sperrbildschirm deaktiviert oder zurückgesetzt wird (z. B. durch den Nutzer oder einen Geräteadministrator). Schlüssel, für die die Verschlüsselung inaktiver Daten erforderlich ist, werden während dieser Ereignisse gelöscht.
Änderungen bei WLAN und Netzwerk
Mit dieser Version werden die folgenden Änderungen beim Verhalten der WLAN- und Netzwerk-APIs eingeführt.
- Ihre Anwendungen können jetzt den Status von
WifiConfiguration
-Objekten nur dann ändern, wenn Sie diese Objekte erstellt haben. Sie sind nicht berechtigt, vom Nutzer oder von anderen Apps erstellteWifiConfiguration
-Objekte zu ändern oder zu löschen. -
Wenn eine App das Gerät bisher gezwungen hat, eine Verbindung zu einem bestimmten WLAN mithilfe von
enableNetwork()
mit der EinstellungdisableAllOthers=true
herzustellen, wurde das Gerät von anderen Netzwerken, z. B. mobiler Daten, getrennt. In dieser Version wird die Verbindung des Geräts zu diesen Netzwerken nicht mehr getrennt. Wenn dietargetSdkVersion
Ihrer App“20”
oder niedriger ist, wird sie an das ausgewählte WLAN angepinnt. Wenn dietargetSdkVersion
Ihrer Anwendung“21”
oder höher ist, verwenden Sie die Multinetzwerk-APIs (z. B.openConnection()
,bindSocket()
und die neue MethodebindProcessToNetwork()
), damit der Netzwerktraffic über das ausgewählte Netzwerk gesendet wird.
Änderungen beim Kameradienst
In diesem Release wurde das Modell für den Zugriff auf freigegebene Ressourcen im Kameradienst vom vorherigen Zugriffsmodell „First-com-first-serve“-Zugriff durch ein Zugriffsmodell ersetzt, bei dem Prozesse mit hoher Priorität bevorzugt werden. Zu den Änderungen am Dienstverhalten gehören:
- Der Zugriff auf Ressourcen des Kamerasubsystems, einschließlich des Öffnens und Konfigurierens eines Kamerageräts, wird basierend auf der „Priorität“ des Clientanwendungsprozesses gewährt. Anwendungsprozesse, bei denen für Nutzer sichtbare Aktivitäten oder Aktivitäten im Vordergrund ausgeführt werden, erhalten im Allgemeinen eine höhere Priorität, wodurch die Erfassung und Nutzung von Kameraressourcen zuverlässiger wird.
- Aktive Kamera-Clients für Apps mit niedrigerer Priorität können entfernt werden, wenn eine Anwendung mit höherer Priorität versucht, die Kamera zu verwenden. In der verworfenen
Camera
API wird dadurchonError()
für den entfernten Client aufgerufen. In derCamera2
API wird dafüronDisconnected()
für den entfernten Client aufgerufen. - Auf Geräten mit geeigneter Kamerahardware können separate Anwendungsprozesse unabhängig voneinander separate Kamerageräte gleichzeitig öffnen und verwenden. Multi-Prozess-Anwendungsfälle, bei denen gleichzeitiger Zugriff zu erheblichen Leistungseinbußen oder Leistungseinbußen bei geöffneten Kamerageräten führt, werden jetzt vom Kameradienst erkannt und nicht zugelassen. Diese Änderung kann zu „Bereinigungen“ von Clients mit niedrigerer Priorität führen, auch wenn keine andere App direkt versucht, auf dasselbe Kameragerät zuzugreifen.
- Wenn Sie den aktuellen Nutzer ändern, werden aktive Kamera-Clients in Apps entfernt, die zum vorherigen Nutzerkonto gehören. Der Zugriff auf die Kamera ist auf Nutzerprofile beschränkt, die dem aktuellen Gerätenutzer gehören. In der Praxis bedeutet dies, dass beispielsweise mit einem Gastkonto keine laufenden Prozesse ausgeführt werden können, die das Kamerasubsystem verwenden, wenn der Nutzer zu einem anderen Konto gewechselt ist.
Laufzeit
Die ART-Laufzeit implementiert jetzt ordnungsgemäß die Zugriffsregeln für die Methode newInstance()
. Durch diese Änderung wurde ein Problem behoben, bei dem Dalvik die Zugriffsregeln in früheren Versionen falsch überprüfte.
Wenn Ihre App die Methode newInstance()
verwendet und Sie Zugriffsprüfungen überschreiben möchten, rufen Sie die Methode setAccessible()
auf und setzen Sie den Eingabeparameter auf true
. Wenn Ihre Anwendung die Appcompat-Bibliothek (Version 7) oder die Bibliothek „recyclerview“ (Version 7) verwendet, müssen Sie sie aktualisieren, um die neuesten Versionen dieser Bibliotheken zu verwenden. Andernfalls müssen alle benutzerdefinierten Klassen, auf die in XML verwiesen wird, aktualisiert werden, damit auf ihre Klassenkonstruktoren zugegriffen werden kann.
In dieser Version wird das Verhalten der dynamischen Verknüpfung aktualisiert. Die dynamische Verknüpfung versteht jetzt den Unterschied zwischen der soname
einer Bibliothek und ihrem Pfad (
öffentlicher Bug 6670). Die Suche nach soname
ist jetzt implementiert. Anwendungen, die bisher funktioniert haben und fehlerhafte DT_NEEDED
-Einträge enthalten (in der Regel absolute Pfade im Dateisystem des Build-Computers), können beim Laden fehlschlagen.
Das Flag dlopen(3) RTLD_LOCAL
ist jetzt korrekt implementiert. RTLD_LOCAL
ist die Standardeinstellung. Aufrufe von dlopen(3)
, die RTLD_LOCAL
nicht explizit verwendet haben, sind davon betroffen (es sei denn, Ihre Anwendung hat RTLD_GLOBAL
explizit verwendet). Mit RTLD_LOCAL
werden Symbole nicht für Bibliotheken verfügbar gemacht, die bei späteren Aufrufen von dlopen(3)
geladen werden (im Gegensatz zu Symbolen, auf die in DT_NEEDED
-Einträgen verwiesen wird).
Wenn Ihre App in früheren Android-Versionen das System anforderte, eine gemeinsam genutzte Bibliothek mit Textverschiebungen zu laden, zeigt das System eine Warnung an, hat das Laden der Bibliothek aber dennoch zugelassen.
Ab diesem Release lehnt das System diese Bibliothek ab, wenn die SDK-Zielversion 23 oder höher Ihrer App ist. Damit Sie feststellen können, ob eine Bibliothek nicht geladen werden konnte, sollte Ihre Anwendung den Fehler dlopen(3)
protokollieren und den Beschreibungstext des Problems einfügen, der vom dlerror(3)
-Aufruf zurückgegeben wird. Weitere Informationen zum Umgang mit Textverschiebungen finden Sie in dieser Anleitung.
APK-Validierung
Die Plattform führt nun eine strengere Validierung von APKs durch. Ein APK gilt als beschädigt, wenn eine Datei im Manifest deklariert ist, aber nicht im APK selbst vorhanden ist. Wenn Inhalte entfernt werden, muss ein APK neu signiert werden.
USB-Anschluss
Bei Geräteverbindungen über den USB-Port ist jetzt standardmäßig der Modus „Nur Laden“ aktiviert. Für den Zugriff auf das Gerät und seine Inhalte über eine USB-Verbindung müssen Nutzer die entsprechende Berechtigung ausdrücklich erteilen. Wenn Ihre App Nutzerinteraktionen mit dem Gerät über einen USB-Port unterstützt, beachten Sie, dass die Interaktion explizit aktiviert werden muss.
Änderungen bei Android for Work
Diese Version umfasst die folgenden Verhaltensänderungen für Android for Work:
- Berufliche Kontakte im privaten Kontext Google Telefon
Anrufliste zeigt jetzt geschäftliche Kontakte, wenn der Nutzer frühere Anrufe sieht.
Wenn du
setCrossProfileCallerIdDisabled()
auftrue
setzt, werden die Kontakte des Arbeitsprofils aus der Google-Telefon-Anrufliste ausgeblendet. Geschäftliche Kontakte können nur dann zusammen mit persönlichen Kontakten auf Geräten über Bluetooth angezeigt werden, wenn dusetBluetoothContactSharingDisabled()
auffalse
gesetzt hast. Die Standardeinstellung isttrue
. - WLAN-Konfiguration entfernen:WLAN-Konfigurationen, die von einem Profilinhaber hinzugefügt wurden (z. B. durch Aufrufe der
addNetwork()
-Methode), werden jetzt entfernt, wenn das Arbeitsprofil gelöscht wird. - WLAN-Konfigurationssperrung:WLAN-Konfigurationen, die von einem aktiven Geräteinhaber erstellt wurden, können vom Nutzer nicht mehr geändert oder gelöscht werden, wenn
WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN
ungleich null ist. Der Nutzer kann weiterhin seine eigenen WLAN-Konfigurationen erstellen und ändern. Aktive Geräteinhaber haben das Recht, WLAN-Konfigurationen zu bearbeiten oder zu entfernen, auch die, die nicht von ihnen erstellt wurden. - Device Policy Controller über Hinzufügen des Google-Kontos herunterladen:Wenn ein Google-Konto, das die Verwaltung über eine Device Policy Controller-App (DPC) erfordert, einem Gerät außerhalb eines verwalteten Kontexts hinzugefügt wird, wird der Nutzer beim Hinzufügen von Konten jetzt aufgefordert, den entsprechenden WPC zu installieren. Dies gilt auch für Konten, die über Einstellungen > Konten und im Assistenten für die Ersteinrichtung des Geräts hinzugefügt wurden.
- Änderungen an bestimmten Verhaltensweisen der
DevicePolicyManager
API:- Der Aufruf der Methode
setCameraDisabled()
wirkt sich nur für den aufrufenden Nutzer auf die Kamera aus. Ein Aufruf der Methode über das verwaltete Profil hat keine Auswirkungen auf Kamera-Apps, die auf dem Hauptnutzer ausgeführt werden. - Darüber hinaus ist die Methode
setKeyguardDisabledFeatures()
jetzt sowohl für Profilinhaber als auch für Geräteinhaber verfügbar. - Ein Profilinhaber kann die folgenden Keyguard-Einschränkungen festlegen:
KEYGUARD_DISABLE_TRUST_AGENTS
undKEYGUARD_DISABLE_FINGERPRINT
, die sich auf die Keyguard-Einstellungen für den übergeordneten Nutzer des Profils auswirken.KEYGUARD_DISABLE_UNREDACTED_NOTIFICATIONS
, die sich nur auf Benachrichtigungen auswirkt, die von Anwendungen im verwalteten Profil generiert werden.
- Die Methoden
DevicePolicyManager.createAndInitializeUser()
undDevicePolicyManager.createUser()
wurden eingestellt. - Die Methode
setScreenCaptureDisabled()
blockiert jetzt auch die Unterstützungsstruktur, wenn eine App des jeweiligen Nutzers im Vordergrund ausgeführt wird. EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM
verwendet jetzt standardmäßig SHA-256. SHA-1 wird aus Gründen der Abwärtskompatibilität weiterhin unterstützt, wird aber in Zukunft entfernt.EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM
akzeptiert jetzt nur noch SHA-256.- Geräteinitialisierungs-APIs, die in Android 6.0 (API-Level 23) vorhanden waren, werden jetzt entfernt.
EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS
wurde entfernt, damit die NFC-Bump-Bereitstellung ein geschütztes Gerät, das auf die Werkseinstellungen zurückgesetzt wurde, nicht programmatisch entsperren kann.- Sie können jetzt das zusätzliche
EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
verwenden, um während der NFC-Bereitstellung des verwalteten Geräts Daten an die App des Geräteinhabers zu übergeben. - Android for Work APIs sind für M-Laufzeitberechtigungen optimiert, einschließlich Arbeitsprofilen, Unterstützungsebene und mehr. Neue Berechtigungs-APIs vom Typ
DevicePolicyManager
haben keine Auswirkungen auf Apps aus der Zeit vor der Umstellung. - Wenn Nutzer aus dem synchronen Teil des Einrichtungsvorgangs zurückkehren, der über einen
ACTION_PROVISION_MANAGED_PROFILE
- oderACTION_PROVISION_MANAGED_DEVICE
-Intent initiiert wurde, gibt das System jetzt einenRESULT_CANCELED
-Ergebniscode zurück.
- Der Aufruf der Methode
- Änderungen an anderen APIs:
- Datennutzung: Die Klasse
android.app.usage.NetworkUsageStats
wurde inNetworkStats
umbenannt.
- Datennutzung: Die Klasse
- Änderungen an den globalen Einstellungen:
- Diese Einstellungen können nicht mehr über
setGlobalSettings()
festgelegt werden:BLUETOOTH_ON
DEVELOPMENT_SETTINGS_ENABLED
MODE_RINGER
NETWORK_PREFERENCE
WIFI_ON
- Diese globalen Einstellungen können jetzt über
setGlobalSettings()
festgelegt werden:
- Diese Einstellungen können nicht mehr über