Ä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 beschrieben, die Sie bei Ihren Anwendungen berücksichtigen und verstehen 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 diesem Release wird ein neues Berechtigungsmodell eingeführt, mit dem Nutzer App-Berechtigungen jetzt zur Laufzeit direkt 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üfe bei Apps, die auf Android 6.0 (API-Level 23) oder höher ausgerichtet sind, die Berechtigungen zur Laufzeit 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 Ihre App nicht auf Android 6.0 (API-Level 23) ausgerichtet ist, sollten Sie 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

Mit dieser Version werden neue Verbesserungen beim Energiesparen für inaktive Geräte und Apps eingeführt. Diese Funktionen wirken sich auf alle Apps aus. Testen Sie Ihre Apps daher 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 nehmen Geräte regelmäßig 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 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 Änderungen finden Sie unter Für Stromsparmodus und App-Standby optimieren.

Apache HTTP Client-Entfernung

Unter Android 6.0 wird der Support für den Apache HTTP-Client eingestellt. Wenn Ihre App diesen Client verwendet und auf Android 2.3 (API-Level 9) oder höher ausgerichtet ist, verwenden Sie stattdessen die Klasse HttpURLConnection. Diese API ist effizienter, da sie die Netzwerknutzung durch transparente Komprimierung und Antwort-Caching reduziert und den Energieverbrauch minimiert. Damit Sie die Apache HTTP APIs weiterhin verwenden können, müssen Sie zuerst die folgende Kompilierungszeitabhängigkeit in der Datei build.gradle deklarieren: 

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

BoringSSL

Android wird von OpenSSL in die BoringSSL-Bibliothek verschoben. Wenn Sie das Android NDK in Ihrer App verwenden, dürfen Sie keine Verknüpfungen zu kryptografischen Bibliotheken herstellen, 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 Cryptography APIs über JNI aufgerufen werden oder eine statische Verknüpfung mit einer Kryptografiebibliothek Ihrer Wahl hergestellt wird.

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 einen konstanten Wert von 02:00:00:00:00:00 zurück.

Damit du über Bluetooth- und WLAN-Scans auf die Hardware-IDs externer Geräte in der Nähe zugreifen kannst, muss deine App jetzt die Berechtigung ACCESS_FINE_LOCATION oder ACCESS_COARSE_LOCATION haben:

Hinweis: Wenn ein Gerät mit Android 6.0 (API-Level 23) eine WLAN- oder Bluetooth-Suche im Hintergrund startet, ist der Vorgang für externe Geräte sichtbar, da 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 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 zu drucken.

Änderungen im Audio-Manager

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. Die Methode setStreamMute() wurde eingestellt. Rufen Sie stattdessen die Methode adjustStreamVolume() auf und übergeben Sie den Richtungswert ADJUST_MUTE oder ADJUST_UNMUTE.

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 schwebende Symbolleiste für die Textauswahl implementieren möchten, nehmen Sie in Ihren vorhandenen Apps 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. Dieser Aufruf gibt die Steuerung von ActionMode-Objekten an das Framework zurück. 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 eingestellt. 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 Ihre App auf Android 6.0 (API-Level 23) oder höher ausgerichtet ist, dürfen Sie nicht auf Lesezeichen des globalen Anbieters zugreifen oder die Berechtigungen für Lesezeichen verwenden. 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, für die keine Ruhedatenträgerverschlüsselung erforderlich ist, werden nicht mehr gelöscht, wenn der sichere Sperrbildschirm deaktiviert oder zurückgesetzt wird (z. B. vom Nutzer oder einem 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 Anwendungen können jetzt den Status von WifiConfiguration-Objekten nur dann ä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 dazu zwang, sich über enableNetwork() mit der Einstellung disableAllOthers=true mit einem bestimmten WLAN zu verbinden, wurde die Verbindung zu anderen Netzwerken wie der mobilen Datenverbindung 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 diesem Release wurde das Modell für den Zugriff auf gemeinsam genutzte Ressourcen im Kameradienst vom bisherigen Zugriffsmodell "Wer zuerst kommt, mahlt zuerst" zu einem 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 Kamerasubsystems, einschließlich des Öffnens und Konfigurierens eines Kamerageräts, wird basierend auf der „Priorität“ des Clientanwendungsprozesses gewährt. Anwendungsprozesse mit für den Nutzer sichtbaren Aktivitäten oder Aktivitäten im Vordergrund haben in der Regel eine höhere Priorität, was die Erfassung und Nutzung von Kameraressourcen zuverlässiger macht.
  • Aktive Kamera-Clients für Apps mit niedrigerer Priorität werden möglicherweise „entfernt“, wenn eine App mit höherer Priorität versucht, die Kamera zu verwenden. In der veralteten 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 separate Kamerageräte gleichzeitig öffnen und verwenden. Mehrere Prozesse, bei denen der gleichzeitige Zugriff zu einer erheblichen Leistungsminderung oder Beeinträchtigung der Funktionen eines der geöffneten Kamerageräte führt, werden jedoch jetzt vom Kameradienst erkannt und nicht mehr zugelassen. 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, die dem aktuellen Gerätenutzer gehören. 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 die Zugriffsregeln für die Methode newInstance() ordnungsgemäß. 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 Anwendung die v7-Appcompat-Bibliothek oder die V7-Recyclerview-Bibliothek verwendet, müssen Sie sie aktualisieren, um die neuesten Versionen dieser Bibliotheken verwenden zu können. Achten Sie andernfalls darauf, dass alle benutzerdefinierten Klassen, auf die in XML verwiesen wird, aktualisiert werden, damit ihre Klassenkonstruktoren zugänglich sind.

In dieser Version wird das Verhalten der dynamischen Verknüpfung 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. Hinweis: RTLD_LOCAL ist der Standardwert. Daher sind Aufrufe von dlopen(3), bei denen RTLD_LOCAL nicht explizit verwendet wurde, betroffen (es sei denn, Ihre App verwendet explizit RTLD_GLOBAL). Bei RTLD_LOCAL werden Symbole nicht für Bibliotheken verfügbar gemacht, die durch spätere Aufrufe von dlopen(3) geladen werden (im Gegensatz zu DT_NEEDED-Einträgen, auf die verwiesen wird).

In früheren Android-Versionen wurde bei einer solchen Anfrage des Systems eine Warnung angezeigt, die Bibliothek aber trotzdem geladen. Ab diesem Release wird diese Bibliothek vom System abgelehnt, wenn die Ziel-SDK-Version Ihrer App 23 oder höher ist. Damit Sie besser erkennen können, ob eine Bibliothek nicht geladen werden konnte, sollte Ihre Anwendung den dlopen(3)-Fehler loggen und den Problembeschreibungstext hinzufügen, den der dlerror(3)-Aufruf zurückgibt. Weitere Informationen zum Verschieben von Text finden Sie in dieser Anleitung.

APK-Überprüfung

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-Anschluss

Bei Geräteverbindungen über den USB-Port wird nun standardmäßig der Modus „Nur Laden“ aktiviert. 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 deine App Nutzerinteraktionen mit dem Gerät über einen USB-Port unterstützt, musst du berücksichtigen, dass die Interaktion explizit aktiviert werden muss.

Ä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. Berufliche Kontakte können zusammen mit persönlichen Kontakten über Bluetooth auf Geräten angezeigt werden, wenn Sie setBluetoothContactSharingDisabled() auf false setzen. Standardmäßig ist dies auf true eingestellt.
  • Entfernen von WLAN-Konfigurationen: WLAN-Konfigurationen, die von einem Profilinhaber hinzugefügt wurden (z. B. durch Aufrufe der Methode addNetwork()), 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 seine eigenen WLAN-Konfigurationen erstellen und ändern. Inhaber eines aktiven Geräts können alle WLAN-Konfigurationen bearbeiten oder entfernen, auch solche, die nicht von ihnen erstellt wurden.
  • Device Policy Controller über das Hinzufügen eines Google-Kontos herunterladen:Wenn ein Google-Konto, das über eine Device Policy Controller App (DPC) verwaltet werden muss, einem Gerät außerhalb eines verwalteten Kontexts hinzugefügt wird, wird der Nutzer jetzt im Ablauf zum Hinzufügen von Konten aufgefordert, den entsprechenden WPC 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 Einschränkungen für den Sperrbildschirm festlegen:
    • Die Methoden DevicePolicyManager.createAndInitializeUser() und DevicePolicyManager.createUser() wurden eingestellt.
    • Mit der setScreenCaptureDisabled()-Methode wird die Assist-Struktur jetzt auch blockiert, wenn eine App des jeweiligen Nutzers im Vordergrund ist.
    • EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM ist jetzt standardmäßig 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 EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE verwenden, um während der NFC-Bereitstellung des verwalteten Geräts Daten an die App des Geräteeigentümers zu übergeben.
    • Android for Work APIs sind für M-Laufzeitberechtigungen optimiert, einschließlich Arbeitsprofilen, Unterstützungsebene und andere. Neue DevicePolicyManager-Berechtigungs-APIs wirken sich nicht auf Apps vor der Migration aus.
    • 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: