Änderungen bei Android 6.0

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

Bildschirm mit neuen Funktionen zur Textauswahl in einer unverankerten Symbolleiste

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:

  1. Ändern Sie im View- oder Activity-Objekt die ActionMode-Aufrufe von startActionMode(Callback) in startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Verwenden Sie Ihre bestehende Implementierung von ActionMode.Callback und erweitern Sie sie stattdessen auf ActionMode.Callback2.
  3. Überschreiben Sie die Methode onGetContentRect(), um die Koordinaten des Inhalts-Rect-Objekts (z. B. ein Textauswahlrechteck) in der Ansicht bereitzustellen.
  4. 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 erstellte WifiConfiguration-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 Einstellung disableAllOthers=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 die targetSdkVersion Ihrer App “20” oder niedriger ist, wird sie an das ausgewählte WLAN angepinnt. Wenn die targetSdkVersion Ihrer Anwendung “21” oder höher ist, verwenden Sie die Multinetzwerk-APIs (z. B. openConnection(), bindSocket() und die neue Methode bindProcessToNetwork()), 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 dadurch onError() für den entfernten Client aufgerufen. In der Camera2 API wird dafür onDisconnected() 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() auf true 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 du setBluetoothContactSharingDisabled() auf false gesetzt hast. Die Standardeinstellung ist true.
  • 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:
    • Die Methoden DevicePolicyManager.createAndInitializeUser() und DevicePolicyManager.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- oder ACTION_PROVISION_MANAGED_DEVICE-Intent initiiert wurde, gibt das System jetzt einen RESULT_CANCELED-Ergebniscode zurück.
  • Änderungen an anderen APIs:
    • Datennutzung: Die Klasse android.app.usage.NetworkUsageStats wurde in NetworkStats umbenannt.
  • Änderungen an den globalen Einstellungen: