Änderungen bei Android 6.0

Neben neuen Funktionen beinhaltet Android 6.0 (API-Level 23) eine Vielzahl von Systemänderungen und Änderungen am API-Verhalten. In diesem Dokument werden einige der wichtigsten Änderungen hervorgehoben, die Sie kennen und in Ihren Apps berücksichtigen sollten.

Wenn Sie bereits eine App für Android veröffentlicht haben, wirken sich diese Änderungen an der Plattform auf Ihre App aus.

Laufzeitberechtigungen

Mit dieser Version wird ein neues Berechtigungsmodell eingeführt, mit dem Nutzer App-Berechtigungen jetzt direkt zur Laufzeit verwalten können. Dieses Modell bietet Nutzern eine bessere Sichtbarkeit und Kontrolle über Berechtigungen. Gleichzeitig werden die Prozesse für die Installation und automatische Updates für App-Entwickler optimiert. Nutzer können Berechtigungen für installierte Apps einzeln gewähren oder widerrufen.

Prüfen Sie in Ihren Apps, die auf Android 6.0 (API-Level 23) oder höher ausgerichtet sind, bei Laufzeit auf 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. Rufen Sie die neue Methode requestPermissions() auf, um eine Berechtigung anzufordern. 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 Beurteilung der Auswirkungen auf Ihre App finden Sie in den Hinweisen zur Verwendung von Berechtigungen.

Stromsparmodus und App-Standby

Diese Version enthält neue Energiesparoptionen für inaktive Geräte und Apps. Diese Funktionen betreffen alle Anwendungen. Testen Sie Ihre Anwendungen daher unbedingt in diesen neuen Modi.

  • Ruhemodus: Wenn ein Nutzer ein Gerät vom Stromnetz trennt und es eine Weile stehen lässt, während das Display ausgeschaltet ist, wechselt das Gerät in den Ruhemodus, in dem versucht wird, das System im Ruhezustand zu halten. In diesem Modus wird der normale Betrieb der Geräte für kurze Zeiträume fortgesetzt, damit die App-Synchronisierung erfolgen und das System ausstehende Vorgänge ausführen kann.
  • App Standby: Mit App Standby kann das System erkennen, dass eine App inaktiv ist, wenn der Nutzer sie nicht aktiv verwendet. Das System trifft diese Entscheidung, wenn der Nutzer die App für einen bestimmten Zeitraum nicht berührt. Wenn das Gerät nicht angeschlossen ist, deaktiviert das System den Netzwerkzugriff und unterbricht die Synchronisierungen und Jobs für die Apps, die es als inaktiv betrachtet.

Weitere Informationen zu diesen Energiesparänderungen finden Sie unter Für Doze und App-Standby optimieren.

Entfernung des Apache HTTP-Clients

Mit der Veröffentlichung von Android 6.0 wird die Unterstützung für den Apache HTTP-Client entfernt. 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 Abhängigkeit zur Kompilierzeit in Ihrer build.gradle-Datei deklarieren: 

android {
    useLibrary 'org.apache.http.legacy'
}

BoringSSL

Android wechselt von OpenSSL zur BoringSSL-Bibliothek. Wenn du das Android-NDK in deiner App verwendest, verlinke keine kryptografischen Bibliotheken, die nicht Teil der NDK API sind, z. B. libcrypto.so und libssl.so. Diese Bibliotheken sind keine öffentlichen APIs und können sich ohne vorherige Ankündigung in verschiedenen Releases und auf verschiedenen Geräten ändern oder nicht mehr funktionieren. Darüber hinaus besteht die Gefahr, dass Sie sich Sicherheitslücken aussetzen. Ändern Sie stattdessen Ihren nativen Code so, dass die Java-Kryptografie-APIs über JNI aufgerufen oder statisch mit einer Kryptografiebibliothek Ihrer Wahl verknüpft werden.

Zugriff auf Hardware-ID

Um Nutzern einen besseren Datenschutz zu bieten, entfernt Android ab dieser Version den programmatischen Zugriff auf die lokale Hardwarekennzeichnung des Geräts für Apps, die die Wi-Fi- und Bluetooth-APIs verwenden. Die Methoden WifiInfo.getMacAddress() und BluetoothAdapter.getAddress() geben jetzt den konstanten Wert 02:00:00:00:00:00 zurück.

Damit Ihre App über Bluetooth- und WLAN-Scans auf die Hardware-IDs externer Geräte in der Nähe zugreifen kann, benötigt sie jetzt die Berechtigungen ACCESS_FINE_LOCATION oder ACCESS_COARSE_LOCATION:

Hinweis: Wenn ein Gerät mit Android 6.0 (API-Ebene 23) einen WLAN- oder Bluetooth-Scan im Hintergrund initiiert, wird der Vorgang für externe Geräte als von einer zufälligen MAC-Adresse stammend angezeigt.

Benachrichtigungen

In dieser Version wurde 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 Notification.Builder-Instanz wieder. Rufen Sie die Methode build() auf, um aktualisierte Notification-Instanzen abzurufen.

Der Befehl adb shell dumpsys notification gibt den 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() ist veraltet. Sie sollten stattdessen die Methode requestAudioFocus() aufrufen. Ebenso wird die Methode setStreamMute() nicht mehr unterstützt. Rufen Sie stattdessen die Methode adjustStreamVolume() auf und geben Sie den Richtungswert ADJUST_MUTE oder ADJUST_UNMUTE an.

Textauswahl

Bildschirm mit neuen Funktionen zur Textauswahl in einer schwebenden Symbolleiste

Wenn Nutzer Text in Ihrer App auswählen, können Sie jetzt Aktionen für die Textauswahl wie Ausschneiden, Kopieren und Einfügen in einer schwebenden Symbolleiste anzeigen. Die Implementierung der Nutzerinteraktion ähnelt der für die kontextbezogene 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 Anwendungen die folgenden Änderungen vor:

  1. Ändern Sie im View- oder Activity-Objekt die ActionMode-Aufrufe von startActionMode(Callback) in startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Erweitern Sie Ihre vorhandene Implementierung von ActionMode.Callback stattdessen auf ActionMode.Callback2.
  3. Überschreiben Sie die onGetContentRect()-Methode, um die Koordinaten des Inhalts-Rect-Objekts (z. B. eines Textauswahl-Rechtecks) in der Ansicht anzugeben.
  4. Wenn die Positionierung des Rechtecks nicht mehr gültig ist und dies das einzige Element ist, das ungültig sein soll, rufen Sie die Methode invalidateContentRect() auf.

Wenn Sie die Version 22.2 der Android-Unterstützungsbibliothek verwenden, beachten Sie, dass schwebende Symbolleisten nicht abwärtskompatibel sind und dass die App-Kompatibilitäts-API standardmäßig die Kontrolle über ActionMode-Objekte übernimmt. Dadurch werden keine schwebenden Symbolleisten angezeigt. Wenn du die Unterstützung von ActionMode in einer AppCompatActivity aktivieren möchtest, rufe getDelegate() auf und dann setHandleNativeActionModesEnabled() für das zurückgegebene AppCompatDelegate-Objekt. Lege den Eingabeparameter auf false fest. Mit diesem Aufruf wird die Kontrolle über ActionMode-Objekte an das Framework zurückgegeben. Auf Geräten mit Android 6.0 (API-Level 23) kann das Framework die ActionBar- oder die Modus „Floating Toolbar“ unterstützen. Auf Geräten mit Android 5.1 (API-Level 22) oder niedriger werden nur die ActionBar-Modi unterstützt.

Änderungen an Browserlesezeichen

In dieser Version wird die Unterstützung für globale Lesezeichen entfernt. Die Methoden android.provider.Browser.getAllBookmarks() und android.provider.Browser.saveBookmark() wurden entfernt. Ebenso werden die Berechtigungen READ_HISTORY_BOOKMARKS und WRITE_HISTORY_BOOKMARKS entfernt. Wenn deine App auf Android 6.0 (API-Level 23) oder höher ausgerichtet ist, greife nicht auf Lesezeichen des globalen Anbieters zu und verwende keine Lesezeichenberechtigungen. Stattdessen sollten Ihre Bookmarks intern in der App gespeichert werden.

Änderungen des Android-Schlüsselspeichers

Mit diesem Release wird DSA vom Android Keystore-Anbieter nicht mehr unterstützt. ECDSA wird weiterhin unterstützt.

Schlüssel, die keine Verschlüsselung ruhender Daten 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 eine Verschlüsselung inaktiver Daten erforderlich ist, werden bei diesen Ereignissen gelöscht.

Änderungen bei WLAN und Netzwerken

In dieser Version wurden die folgenden Verhaltensänderungen für die Wi-Fi- und Netzwerk-APIs eingeführt.

  • Ihre Apps können den Status von WifiConfiguration-Objekten jetzt nur noch ändern, wenn Sie diese Objekte erstellt haben. Sie dürfen keine WifiConfiguration-Objekte ändern oder löschen, die vom Nutzer oder von anderen Apps erstellt wurden.
  • Wenn eine App das Gerät bisher mithilfe von enableNetwork() und der Einstellung disableAllOthers=true gezwungen hat, eine Verbindung zu einem bestimmten WLAN herzustellen, wurde es von anderen Netzwerken wie z. B. mobilen Daten getrennt. In dieser Version wird die Verbindung des Geräts zu solchen anderen Netzwerken nicht mehr getrennt. Wenn der targetSdkVersion Ihrer App “20” oder niedriger ist, wird sie an das ausgewählte WLAN angepinnt. Wenn die targetSdkVersion Ihrer App “21” oder höher ist, verwenden Sie die APIs für mehrere Netzwerke (z. B. openConnection(), bindSocket() und die neue Methode bindProcessToNetwork()), damit der Netzwerkverkehr über das ausgewählte Netzwerk gesendet wird.

Änderungen am Kameradienst

In dieser Version wurde das Modell für den Zugriff auf freigegebene Ressourcen im Kameradienst vom bisherigen Modell „Wer zuerst kommt, mahlt zuerst“ in ein Zugriffsmodell geändert, bei dem Prozesse mit hoher Priorität bevorzugt werden. Zu den Änderungen am Dienstverhalten gehören:

  • Der Zugriff auf die Ressourcen des Kamera-Subsystems, einschließlich des Öffnens und Konfigurierens eines Kamerageräts, wird basierend auf der „Priorität“ des Clientanwendungsprozesses gewährt. Anwendungsabläufe mit für den Nutzer sichtbaren Aktivitäten oder Aktivitäten im Vordergrund haben in der Regel eine höhere Priorität, wodurch die Ressourcenakquisition und -nutzung der Kamera zuverlässiger wird.
  • Aktive Kamera-Clients für Apps mit niedrigerer Priorität werden möglicherweise „verdrängt“, wenn eine App mit höherer Priorität versucht, die Kamera zu verwenden. In der verworfenen Camera API führt dies dazu, dass onError() für den entfernten Client aufgerufen wird. In der Camera2 API führt dies dazu, dass onDisconnected() für den entfernten Client aufgerufen wird.
  • Auf Geräten mit geeigneter Kamerahardware können separate Anwendungsprozesse unabhängig voneinander separate Kamerageräte öffnen und gleichzeitig verwenden. Allerdings werden Multiprozessanwendungsfälle, bei denen ein gleichzeitiger Zugriff zu erheblichen Leistungseinbußen oder Funktionalitäten der geöffneten Kamerageräte führt, jetzt vom Kameradienst erkannt und blockiert. Diese Änderung kann dazu führen, dass Clients mit niedrigerer Priorität „verdrängt“ werden, auch wenn keine andere App direkt versucht, auf dasselbe Kameragerät zuzugreifen.
  • Wenn Sie den aktuellen Nutzer ändern, werden aktive Kameraclients in Apps, die dem vorherigen Nutzerkonto gehören, entfernt. Der Zugriff auf die Kamera ist auf Nutzerprofile beschränkt, deren Inhaber der aktuelle Gerätenutzer ist. In der Praxis bedeutet das, dass ein Gastkonto beispielsweise keine laufenden Prozesse, die das Kamera-Subsystem verwenden, beibehalten kann, wenn der Nutzer zu einem anderen Konto gewechselt ist.

Laufzeit

Die ART-Laufzeit implementiert jetzt korrekt Zugriffsregeln für die Methode newInstance(). Durch diese Änderung wird ein Problem behoben, bei dem Dalvik in früheren Versionen Zugriffsregeln falsch überprüft hat. Wenn in Ihrer App die Methode newInstance() verwendet wird und Sie die Zugriffsüberprüfungen überschreiben möchten, rufen Sie die Methode setAccessible() mit dem Eingabeparameter true auf. Wenn Ihre App die v7 AppCompat-Bibliothek oder die v7 RecyclerView-Bibliothek verwendet, müssen Sie Ihre App so aktualisieren, dass sie die neuesten Versionen dieser Bibliotheken verwendet. Andernfalls müssen alle benutzerdefinierten Klassen, auf die aus XML verwiesen wird, aktualisiert werden, damit ihre Klassenkonstruktoren zugänglich sind.

In dieser Version wurde das Verhalten des dynamischen Linker aktualisiert. Der dynamische Linker unterscheidet jetzt zwischen dem soname einer Bibliothek und ihrem Pfad (öffentlicher Fehler 6670) und die Suche nach soname ist jetzt implementiert. Apps, die zuvor funktioniert haben und fehlerhafte DT_NEEDED-Einträge haben (normalerweise absolute Pfade im Dateisystem des Build-Rechners), 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 nicht explizit RTLD_LOCAL verwendet haben, sind davon betroffen, es sei denn, deine App hat RTLD_GLOBAL explizit verwendet. Mit RTLD_LOCAL werden Symbole nicht für Bibliotheken verfügbar, die von späteren Aufrufen von dlopen(3) geladen werden (und nicht durch DT_NEEDED-Einträge referenziert werden).

In früheren Android-Versionen wurde bei einer solchen Anfrage des Systems eine Warnung angezeigt, die Bibliothek aber trotzdem geladen. Ab diesem Release lehnt das System diese Bibliothek ab, wenn die SDK-Zielversion 23 oder höher deiner App ist. Damit Sie erkennen können, ob eine Bibliothek nicht geladen wurde, sollte Ihre App den dlopen(3)-Fehler protokollieren und die Problembeschreibung enthalten, die der dlerror(3)-Aufruf zurückgibt. Weitere Informationen zum Umgang mit Textverschiebungen finden Sie in diesem Leitfaden.

APK-Validierung

Die Plattform führt jetzt eine strengere Validierung von APKs durch. Ein APK gilt als beschädigt, wenn eine Datei im Manifest deklariert, aber nicht im APK selbst vorhanden ist. Ein APK muss neu signiert werden, wenn Inhalte entfernt werden.

USB-Verbindung

Geräteverbindungen über den USB-Anschluss sind jetzt standardmäßig auf den Lademodus eingestellt. Um über eine USB-Verbindung auf das Gerät und seine Inhalte zuzugreifen, müssen Nutzer ausdrücklich die Berechtigung für solche Interaktionen erteilen. Wenn Ihre App Nutzerinteraktionen mit dem Gerät über einen USB-Anschluss unterstützt, muss die Interaktion ausdrücklich aktiviert werden.

Änderungen bei Android for Work

Diese Version enthält die folgenden Verhaltensänderungen für Android for Work:

  • Berufliche Kontakte im privaten Kontext Wenn der Nutzer frühere Anrufe aufruft, werden in der Anrufliste von Google Telefon jetzt geschäftliche Kontakte angezeigt. Wenn Sie setCrossProfileCallerIdDisabled() auf true festlegen, werden die Kontakte des Arbeitsprofils in der Anrufliste von Google Telefon ausgeblendet. geschäftliche Kontakte können nur dann zusammen mit privaten Kontakten auf Geräten über Bluetooth angezeigt werden, wenn Sie setBluetoothContactSharingDisabled() auf false festlegen. Standardmäßig ist dies auf true eingestellt.
  • Entfernung der WLAN-Konfiguration:WLAN-Konfigurationen, die von einem Profilinhaber (z. B. durch Aufrufe der Methode addNetwork()) hinzugefügt wurden, werden jetzt entfernt, wenn das Arbeitsprofil gelöscht wird.
  • Blockierung der WLAN-Konfiguration: Eine WLAN-Konfiguration, die von einem aktiven Geräteeigentümer erstellt wurde, kann vom Nutzer nicht mehr geändert oder gelöscht werden, wenn WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN ungleich 0 ist. Der Nutzer kann weiterhin eigene WLAN-Konfigurationen erstellen und ändern. Aktive Geräteinhaber können WLAN-Konfigurationen bearbeiten oder entfernen, auch die, die nicht von ihnen erstellt wurden.
  • Device Policy Controller über das Hinzufügen eines Google-Kontos herunterladen:Wenn einem Gerät außerhalb eines verwalteten Kontexts ein Google-Konto hinzugefügt wird, das über eine Device Policy Controller App (DPC) verwaltet werden muss, wird der Nutzer beim Hinzufügen des Kontos aufgefordert, den entsprechenden Device Policy Controller zu installieren. Dieses Verhalten gilt auch für Konten, die über Einstellungen > Konten und im Assistenten für die Ersteinrichtung des Geräts hinzugefügt wurden.
  • Änderungen am Verhalten bestimmter DevicePolicyManager API:
    • Das Aufrufen der Methode setCameraDisabled() wirkt sich nur auf die Kamera des aufrufenden Nutzers aus. Wenn sie über das verwaltete Profil aufgerufen wird, hat das keine Auswirkungen auf Kamera-Apps, die für den Hauptnutzer ausgeführt werden.
    • Darüber hinaus ist die Methode setKeyguardDisabledFeatures() jetzt für Profilinhaber und Geräteinhaber verfügbar.
    • Ein Profilinhaber kann die folgenden Keyguard-Einschränkungen festlegen:
    • Die Methoden DevicePolicyManager.createAndInitializeUser() und DevicePolicyManager.createUser() wurden eingestellt.
    • Die Methode setScreenCaptureDisabled() blockiert jetzt auch die unterstützende Struktur, wenn eine App des jeweiligen Nutzers im Vordergrund ausgeführt wird.
    • EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM hat jetzt standardmäßig den Wert „SHA-256“. SHA-1 wird aus Gründen der Abwärtskompatibilität noch unterstützt, wird aber in Zukunft entfernt. EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM akzeptiert jetzt nur noch SHA-256.
    • Die APIs zur Geräteinitialisierung, die in Android 6.0 (API-Level 23) vorhanden waren, wurden entfernt.
    • EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS wird entfernt, damit ein Gerät, das durch den Schutz vor dem Zurücksetzen auf die Werkseinstellungen geschützt ist, nicht programmatisch durch NFC-Bump-Bereitstellung entsperrt werden kann.
    • Sie können jetzt das EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE-Extra verwenden, um während der NFC-Bereitstellung des verwalteten Geräts Daten an die App des Geräteeigentümers weiterzugeben.
    • Android for Work APIs sind für die Laufzeitberechtigungen von Android M optimiert, einschließlich Arbeitsprofilen und der Assistenzebene. Die neuen DevicePolicyManager-Berechtigungs-APIs haben keine Auswirkungen auf Apps, die vor der Version M veröffentlicht wurden.
    • Wenn Nutzer den synchronen Teil des Einrichtungsvorgangs, der über einen ACTION_PROVISION_MANAGED_PROFILE- oder ACTION_PROVISION_MANAGED_DEVICE-Intent gestartet wurde, abbrechen, gibt das System jetzt den Ergebniscode RESULT_CANCELED zurück.
  • Änderungen an anderen APIs:
    • Datennutzung: Die Klasse android.app.usage.NetworkUsageStats wurde in NetworkStats umbenannt.
  • Änderungen an globalen Einstellungen: