Verhaltensänderungen unter Android 5.0

API-Level: 21

Neben neuen Funktionen und Möglichkeiten beinhaltet Android 5.0 eine Reihe 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 deine App von diesen Änderungen in Android 5.0 betroffen sein könnte.

Einen groben Überblick über die neuen Plattformfunktionen erhalten Sie in den Highlights von Android Lollipop.

Videos

Dev Byte: What's New in Android 5.0 (Entwickler-Byte: Was ist neu in Android 5.0)

Dev Byte: Benachrichtigungen

Android Runtime ("ART")

In Android 5.0 ersetzt die ART-Laufzeit Dalvik als Plattformstandard. Die ART-Laufzeit wurde in Android 4.4 experimentell eingeführt.

Eine Übersicht über die neuen Funktionen von ART finden Sie unter Einführung in ART. Einige der wichtigsten neuen Funktionen sind:

  • AOT-Kompilierung (Ahead-of-Time)
  • Verbesserte automatische Speicherbereinigung
  • Verbesserte Unterstützung bei der Fehlerbehebung

Die meisten Android-Apps sollten ganz ohne Änderungen gemäß ART funktionieren. Einige Techniken, die bei Dalvik funktionieren, funktionieren jedoch nicht bei ART. Informationen zu den wichtigsten Problemen finden Sie unter App-Verhalten in Android Runtime (ART) überprüfen. Seien Sie in folgenden Fällen besonders aufmerksam:

  • Ihre App verwendet die Java Native Interface (JNI), um C/C++-Code auszuführen.
  • Sie verwenden Entwicklungstools, die nicht standardmäßigen Code generieren, z. B. einige Obfuscators.
  • Sie verwenden Verfahren, die mit der Komprimierung der automatischen Speicherbereinigung nicht kompatibel sind.

Benachrichtigungen

Achten Sie darauf, dass Ihre Benachrichtigungen die folgenden Änderungen unter Android 5.0 berücksichtigen. Weitere Informationen zum Entwerfen von Benachrichtigungen für Android 5.0 und höher findest du im Designleitfaden für Benachrichtigungen.

Material Design-Stil

Benachrichtigungen werden mit dunklem Text auf weißem (oder sehr hellem) Hintergrund gezeichnet, um sie an die neuen Material Design-Widgets anzupassen. Achte darauf, dass alle Benachrichtigungen mit dem neuen Farbschema korrekt dargestellt werden. Wenn Ihre Benachrichtigungen falsch aussehen, beheben Sie sie:

  • Mit setColor() können Sie eine Akzentfarbe in einem Kreis hinter Ihrem Symbolbild festlegen.
  • Aktualisieren oder entfernen Sie Assets, die Farben enthalten. Das System ignoriert alle Nicht-Alphakanäle in Aktionssymbolen und im Hauptbenachrichtigungssymbol. Sie sollten davon ausgehen, dass diese Symbole nur Alpha-Elemente sind. Benachrichtigungssymbole werden weiß und Aktionssymbole in Dunkelgrau dargestellt.

Töne und Vibration

Wenn Sie Ihren Benachrichtigungen derzeit Töne und Vibrationen hinzufügen, indem Sie die Klassen Ringtone, MediaPlayer oder Vibrator verwenden, entfernen Sie diesen Code, damit das System Benachrichtigungen im Prioritätsmodus korrekt präsentieren kann. Verwenden Sie stattdessen Notification.Builder-Methoden, um Töne und Vibration hinzuzufügen.

Wenn Sie das Gerät auf RINGER_MODE_SILENT setzen, wechselt es in den neuen Prioritätsmodus. Das Gerät beendet den Prioritätsmodus, wenn Sie ihn auf RINGER_MODE_NORMAL oder RINGER_MODE_VIBRATE festlegen.

Früher wurde STREAM_MUSIC als Masterstream verwendet, um die Lautstärke auf Tablets zu steuern. In Android 5.0 ist der Master-Lautstärkestream für Smartphones und Tablets jetzt einheitlich und wird von STREAM_RING oder STREAM_NOTIFICATION gesteuert.

Sichtbarkeit des Sperrbildschirms

Unter Android 5.0 werden Benachrichtigungen jetzt standardmäßig auf dem Sperrbildschirm des Nutzers angezeigt. Nutzer können festlegen, dass vertrauliche Informationen nicht offengelegt werden. In diesem Fall entfernt das System automatisch den in der Benachrichtigung angezeigten Text. Verwenden Sie setPublicVersion(), um diese Benachrichtigung nach Datenentfernung anzupassen.

Wenn die Benachrichtigung keine personenbezogenen Daten enthält oder Sie die Steuerung der Medienwiedergabe für die Benachrichtigung zulassen möchten, rufen Sie die Methode setVisibility() auf und legen Sie die Sichtbarkeitsstufe der Benachrichtigung auf VISIBILITY_PUBLIC fest.

Medienwiedergabe

Wenn du Benachrichtigungen implementierst, die den Wiedergabestatus von Medien oder die Übertragungssteuerung anzeigen, solltest du die neue Notification.MediaStyle-Vorlage anstelle eines benutzerdefinierten RemoteViews.RemoteView-Objekts verwenden. Unabhängig von der ausgewählten Methode müssen Sie die Sichtbarkeit der Benachrichtigung auf VISIBILITY_PUBLIC setzen, damit Ihre Steuerelemente über den Sperrbildschirm zugänglich sind. Ab Android 5.0 zeigt das System keine RemoteControlClient-Objekte mehr auf dem Sperrbildschirm an. Weitere Informationen finden Sie unter Wenn Ihre Anwendung RemoteControlClient verwendet.

Vorabbenachrichtigung

Benachrichtigungen können jetzt in einem kleinen unverankerten Fenster (auch Vorabbenachrichtigung genannt) angezeigt werden, wenn das Gerät aktiv ist (d. h. es entsperrt und der Bildschirm eingeschaltet ist). Diese Benachrichtigungen sehen ähnlich aus wie die kompakte Form Ihrer Benachrichtigung, mit der Ausnahme, dass die Vorabbenachrichtigung auch Aktionsschaltflächen enthält. Nutzer können auf eine Vorabbenachrichtigung reagieren oder sie schließen, ohne die aktuelle App zu verlassen.

Beispiele für Bedingungen, die Vorabbenachrichtigungen auslösen können:

  • Die Aktivität des Nutzers wird im Vollbildmodus ausgeführt (die App verwendet fullScreenIntent)
  • Die Benachrichtigung hat eine hohe Priorität und verwendet Klingeltöne oder Vibrationen.

Wenn in Ihrer App Benachrichtigungen in einem dieser Szenarien implementiert sind, müssen Sie darauf achten, dass Vorabbenachrichtigungen richtig dargestellt werden.

Mediensteuerung und RemoteControlClient

Die Klasse RemoteControlClient wurde eingestellt. Stellen Sie so bald wie möglich auf die neue MediaSession API um.

Auf Sperrbildschirmen in Android 5.0 werden keine Steuerelemente für MediaSession oder RemoteControlClient angezeigt. Stattdessen kann Ihre App die Steuerung der Medienwiedergabe vom Sperrbildschirm aus über eine Benachrichtigung bereitstellen. Dadurch erhält Ihre App mehr Kontrolle über die Darstellung von Medienschaltflächen und bietet Nutzern auf gesperrten und entsperrten Geräten eine einheitliche Nutzung.

Zu diesem Zweck wird in Android 5.0 eine neue Notification.MediaStyle-Vorlage eingeführt. Notification.MediaStyle wandelt Benachrichtigungsaktionen, die Sie mit Notification.Builder.addAction() hinzugefügt haben, in kompakte Schaltflächen um, die in die Benachrichtigungen zur Medienwiedergabe Ihrer App eingebettet sind. Übergeben Sie Ihr Sitzungstoken an die Methode setSession(), um das System darüber zu informieren, dass diese Benachrichtigung eine laufende Mediensitzung steuert.

Achte darauf, die Sichtbarkeit der Benachrichtigung auf VISIBILITY_PUBLIC zu setzen, um die Benachrichtigung als sicher zu markieren, damit sie auf jedem Sperrbildschirm (sicher oder anderweitig) angezeigt werden kann. Weitere Informationen findest du unter Sperrbildschirm-Benachrichtigungen.

Wenn du die Steuerelemente für die Medienwiedergabe verwenden möchtest, wenn deine App auf der Android TV- oder Wear-Plattform ausgeführt wird, implementiere die Klasse MediaSession. Du solltest auch MediaSession implementieren, wenn deine App Medienschaltflächenereignisse auf Android-Geräten empfangen muss.

getRecentTasks()

Mit Einführung der neuen Funktion für gleichzeitige Dokumente und Aktivitäten in Android 5.0 (siehe Gleichzeitige Dokumente und Aktivitäten auf dem Bildschirm „Letzte“ unten) wurde die Methode ActivityManager.getRecentTasks() eingestellt, um den Datenschutz für Nutzer zu verbessern. Aus Gründen der Abwärtskompatibilität gibt diese Methode immer noch eine kleine Teilmenge ihrer Daten zurück, einschließlich der eigenen Aufgaben der aufrufenden Anwendung und möglicherweise einiger anderer nicht vertraulicher Aufgaben (z. B. Home). Wenn Ihre Anwendung diese Methode zum Abrufen eigener Aufgaben verwendet, verwenden Sie stattdessen getAppTasks(), um diese Informationen abzurufen.

64-Bit-Unterstützung im Android NDK

Mit Android 5.0 werden 64-Bit-Systeme unterstützt. Die 64-Bit-Erweiterung erweitert den Adressraum und verbessert die Leistung. Vorhandene 32-Bit-Anwendungen werden weiterhin vollständig unterstützt. Durch die 64-Bit-Unterstützung wird auch die Leistung von OpenSSL für die Kryptografie verbessert. Darüber hinaus werden mit diesem Release neue native Medien-NDK APIs sowie native Unterstützung von OpenGL ES (GLES) 3.1 eingeführt.

Damit Sie die in Android 5.0 bereitgestellte 64-Bit-Unterstützung nutzen können, müssen Sie NDK Revision 10c von der Android-NDK-Seite herunterladen und installieren. Weitere Informationen zu wichtigen Änderungen und Fehlerkorrekturen für das NDK finden Sie in den Versionshinweisen zu Überarbeitung 10c.

An einen Dienst binden

Die Methode Context.bindService() erfordert jetzt ein explizites Intent und gibt bei einem impliziten Intent eine Ausnahme aus. Damit Ihre Anwendung sicher ist, sollten Sie beim Starten oder Binden von Service einen expliziten Intent verwenden und keine Intent-Filter für den Dienst deklarieren.

WebView

Unter Android 5.0 wird das Standardverhalten für Ihre App geändert.

  • Wenn Ihre App auf API-Level 21 oder höher ausgerichtet ist:
    • Das System blockiert standardmäßig gemischte Inhalte und Cookies von Drittanbietern. Verwenden Sie die Methoden setMixedContentMode() bzw. setAcceptThirdPartyCookies(), um gemischte Inhalte und Cookies von Drittanbietern zuzulassen.
    • Das System wählt nun intelligent Teile des HTML-Dokuments zum Zeichnen aus. Dieses neue Standardverhalten hilft, den Arbeitsspeicherbedarf zu reduzieren und die Leistung zu steigern. Wenn Sie das gesamte Dokument auf einmal rendern möchten, deaktivieren Sie diese Optimierung, indem Sie enableSlowWholeDocumentDraw() aufrufen.
  • Wenn Ihre App auf API-Level unter 21 ausgerichtet ist:Das System lässt gemischte Inhalte und Drittanbieter-Cookies zu und rendert immer das gesamte Dokument auf einmal.

Eindeutigkeitsanforderung für benutzerdefinierte Berechtigungen

Wie in der Übersicht über Berechtigungen dokumentiert, können Android-Apps benutzerdefinierte Berechtigungen zur Verwaltung des Zugriffs auf Komponenten proprietär definieren, ohne die vordefinierten Systemberechtigungen der Plattform zu verwenden. Apps definieren benutzerdefinierte Berechtigungen in <permission>-Elementen, die in ihren Manifestdateien deklariert sind.

Es gibt nur wenige Szenarien, in denen das Definieren benutzerdefinierter Berechtigungen ein legitimer und sicherer Ansatz ist. Benutzerdefinierte Berechtigungen müssen jedoch manchmal nicht erstellt werden. Je nach dem Schutzniveau, das den Berechtigungen zugewiesen ist, kann dies sogar ein potenzielles Risiko für eine Anwendung bergen.

In Android 5.0 wurde das Verhalten geändert, damit nur eine App eine bestimmte benutzerdefinierte Berechtigung definieren kann, es sei denn, sie ist mit demselben Schlüssel wie andere Apps signiert, die die Berechtigung definieren.

Apps mit doppelten benutzerdefinierten Berechtigungen

Für jede App kann eine beliebige benutzerdefinierte Berechtigung definiert werden. Es kann also vorkommen, dass mehrere Apps dieselbe benutzerdefinierte Berechtigung definieren. Wenn beispielsweise zwei Anwendungen eine ähnliche Funktion bieten, können sie denselben logischen Namen für ihre benutzerdefinierten Berechtigungen ableiten. Anwendungen können auch allgemeine öffentliche Bibliotheken oder Codebeispiele enthalten, die dieselben benutzerdefinierten Berechtigungsdefinitionen enthalten.

In Android 4.4 und früheren Versionen konnten Nutzer mehrere solcher Apps auf einem bestimmten Gerät installieren, obwohl das System das von der zuerst installierte App vorgegebene Schutzniveau zuweist.

Ab Android 5.0 erzwingt das System eine neue Eindeutigkeitseinschränkung für benutzerdefinierte Berechtigungen für Apps, die mit anderen Schlüsseln signiert sind. Jetzt kann nur eine App auf einem Gerät eine bestimmte benutzerdefinierte Berechtigung (basierend auf ihrem Namen) definieren, es sei denn, die andere App, die die Berechtigung definiert, ist mit demselben Schlüssel signiert. Wenn der Nutzer versucht, eine App mit einer doppelten benutzerdefinierten Berechtigung zu installieren, und nicht mit demselben Schlüssel signiert ist wie die residente App, die die Berechtigung definiert, blockiert das System die Installation.

Überlegungen zu Ihrer App

Unter Android 5.0 und höher können Apps weiterhin wie zuvor eigene benutzerdefinierte Berechtigungen definieren und über den Mechanismus <uses-permission> benutzerdefinierte Berechtigungen von anderen Apps anfordern. Mit der neuen Anforderung in Android 5.0 solltest du jedoch mögliche Auswirkungen auf deine App sorgfältig abwägen.

Hier sind einige Punkte, die Sie berücksichtigen sollten:

  • Deklariert deine App in ihrem Manifest irgendwelche <permission>-Elemente? Wenn ja, sind sie für die ordnungsgemäße Funktion Ihrer App oder Ihres Dienstes wirklich erforderlich? Oder könnten Sie stattdessen eine Standardberechtigung des Systems verwenden?
  • Wenn deine App <permission>-Elemente enthält, weißt du, woher sie stammen?
  • Möchten Sie Ihre benutzerdefinierten Berechtigungen von anderen Apps über <uses-permission> anfordern?
  • Verwenden Sie Boilerplate- oder Beispielcode in Ihrer App, die <permission>-Elemente enthält? Sind diese Berechtigungselemente wirklich erforderlich?
  • Verwenden Ihre benutzerdefinierten Berechtigungen einfache Namen oder beruhen sie auf gängigen Begriffen, die von anderen Apps häufig verwendet werden?

Neue Installationen und Updates

Wie bereits erwähnt, sind neue Installationen und Updates deiner App auf Geräten mit Android 4.4 oder niedriger nicht betroffen und auch das Verhalten bleibt unverändert. Bei Neuinstallationen und Updates auf Geräten mit Android 5.0 oder höher verhindert das System die Installation deiner App, wenn eine benutzerdefinierte Berechtigung definiert wurde, die bereits von einer vorhandenen residenten App definiert wurde.

Vorhandene Installationen mit Android 5.0-Systemupdate

Wenn deine App benutzerdefinierte Berechtigungen verwendet und weit verbreitet und installiert ist, besteht die Möglichkeit, dass sie betroffen ist, wenn Nutzer ein Update ihrer Geräte auf Android 5.0 erhalten. Nach der Installation des Systemupdates werden die installierten Apps noch einmal validiert. Dabei werden auch ihre benutzerdefinierten Berechtigungen geprüft. Wenn Ihre App eine benutzerdefinierte Berechtigung definiert, die bereits von einer anderen App definiert ist, die bereits validiert wurde, und Ihre App nicht mit demselben Schlüssel wie die andere App signiert ist, wird die App vom System nicht neu installiert.

Empfehlungen

Auf Geräten mit Android 5.0 oder höher empfehlen wir, dass Sie Ihre App sofort prüfen, gegebenenfalls Anpassungen vornehmen und die aktualisierte Version so schnell wie möglich für Ihre Nutzer veröffentlichen.

  • Wenn du in deiner App benutzerdefinierte Berechtigungen verwendest, solltest du deren Ursprung berücksichtigen und prüfen, ob du sie wirklich benötigst. Entferne alle <permission>-Elemente aus deiner App, es sei denn, sie sind für die ordnungsgemäße Funktion deiner App erforderlich.
  • Ersetzen Sie Ihre benutzerdefinierten Berechtigungen nach Möglichkeit durch Standardberechtigungen des Systems.
  • Wenn für Ihre App benutzerdefinierte Berechtigungen erforderlich sind, benennen Sie die benutzerdefinierten Berechtigungen so um, dass sie eindeutig sind. Fügen Sie sie beispielsweise an den vollständigen Paketnamen der App an.
  • Wenn Sie mehrere Anwendungen haben, die mit unterschiedlichen Schlüsseln signiert sind und die Anwendungen über eine benutzerdefinierte Berechtigung auf eine gemeinsam genutzte Komponente zugreifen, muss die benutzerdefinierte Berechtigung in der gemeinsam genutzten Komponente nur einmal definiert sein. Anwendungen, die die gemeinsam genutzte Komponente verwenden, sollten die benutzerdefinierte Berechtigung nicht selbst definieren, sondern den Zugriff über den Mechanismus <uses-permission> anfordern.
  • Wenn Sie mehrere Anwendungen haben, die mit demselben Schlüssel signiert sind, kann jede App dieselben benutzerdefinierten Berechtigungen wie erforderlich definieren. Das System ermöglicht die Installation der Apps auf die übliche Weise.

Änderungen der TLS/SSL-Standardkonfiguration

In Android 5.0 werden Änderungen an der TLS/SSL-Standardkonfiguration vorgenommen, die von Apps für HTTPS- und anderen TLS/SSL-Traffic verwendet wird:

  • Die Protokolle TLSv1.2 und TLSv1.1 sind jetzt aktiviert.
  • Die Cipher Suites von AES-GCM (AEAD) sind jetzt aktiviert.
  • MD5-, 3DES-, Export- und ECDH-Cipher Suites für statische Schlüssel sind jetzt deaktiviert.
  • Forward Secrecy Cipher Suites (ECDHE und DHE) werden bevorzugt.

In wenigen der unten aufgeführten Fälle können diese Änderungen zu Ausfällen bei HTTPS- oder TLS/SSL-Verbindungen führen.

Hinweis: Das Sicherheitsprogramm „ProviderInstaller“ aus den Google Play-Diensten bietet diese Änderungen für alle Android-Plattformversionen bis zu Android 2.3 zurück.

Der Server unterstützt keine der aktivierten Chiffresammlungen

Beispielsweise kann ein Server nur Cipher Suites von 3DES oder MD5 unterstützen. Die bevorzugte Lösung besteht darin, die Konfiguration des Servers zu verbessern, um stärkere und modernere Cipher Suites und Protokolle zu ermöglichen. Idealerweise sollten TLSv1.2 und AES-GCM aktiviert und Forward Secrecy Cipher Suites (ECDHE, DHE) aktiviert und bevorzugt sein.

Alternativ können Sie die Anwendung so ändern, dass für die Kommunikation mit dem Server eine benutzerdefinierte SSLSocketFactory verwendet wird. Die Factory sollte so konzipiert sein, dass SSLSocket-Instanzen erstellt werden, für die einige der für den Server erforderlichen Cipher Suites zusätzlich zu den standardmäßigen Cipher Suites aktiviert sind.

Die App trifft falsche Annahmen zu Cipher Suites, die für die Verbindung mit dem Server verwendet werden

Einige Anwendungen enthalten beispielsweise einen benutzerdefinierten X509TrustManager, der nicht funktioniert, da er erwartet, dass der Parameter „authType“ RSA ist, er aber auf ECDHE_RSA oder DHE_RSA stößt.

Der Server ist intoleranz gegenüber TLSv1.1, TLSv1.2 oder neuen TLS-Erweiterungen

Beispielsweise wird der TLS/SSL-Handshake mit einem Server fälschlicherweise abgelehnt oder blockiert. Die bevorzugte Lösung besteht darin, den Server so zu aktualisieren, dass er dem TLS/SSL-Protokoll entspricht. Dadurch kann der Server diese neueren Protokolle erfolgreich aushandeln oder TLSv1- oder ältere Protokolle aushandeln. TLS-Erweiterungen, die er nicht versteht, werden ignoriert. In einigen Fällen kann das Deaktivieren von TLSv1.1 und TLSv1.2 auf dem Server als Zwischenlösung funktionieren, bis die Serversoftware aktualisiert wird.

Alternativ können Sie die Anwendung so ändern, dass für die Kommunikation mit dem Server eine benutzerdefinierte SSLSocketFactory verwendet wird. Die Factory sollte so konzipiert sein, dass SSLSocket-Instanzen erstellt werden, bei denen nur die Protokolle aktiviert sind, die vom Server korrekt unterstützt werden.

Unterstützung verwalteter Profile

Geräteadministratoren können einem Gerät ein verwaltetes Profil hinzufügen. Der Inhaber dieses Profils ist der Administrator. Der Administrator hat dadurch die Kontrolle über das verwaltete Profil, während das private Profil des Nutzers und sein Speicherplatz weiterhin der Kontrolle des Nutzers unterliegen. Diese Änderung kann sich auf folgende Weise auf das Verhalten Ihrer vorhandenen Anwendung auswirken.

Intents verarbeiten

Geräteadministratoren können den Zugriff auf Systemanwendungen über das verwaltete Profil einschränken. Wenn eine App in diesem Fall einen Intent über das verwaltete Profil auslöst, der normalerweise von dieser Anwendung verarbeitet wird, und für den Intent im verwalteten Profil kein geeigneter Handler vorhanden ist, löst der Intent eine Ausnahme aus. Beispielsweise kann der Geräteadministrator verhindern, dass Apps auf dem verwalteten Profil auf die Kamera-App des Systems zugreifen. Wenn Ihre Anwendung im verwalteten Profil ausgeführt wird und startActivityForResult() für MediaStore.ACTION_IMAGE_CAPTURE aufruft und es im verwalteten Profil keine App gibt, die den Intent verarbeiten kann, wird der Fehler ActivityNotFoundException ausgegeben.

Sie können dies verhindern, indem Sie prüfen, ob für jeden Intent mindestens ein Handler vorhanden ist, bevor Sie ihn auslösen. Rufen Sie Intent.resolveActivity() auf, um nach einem gültigen Handler zu suchen. Ein Beispiel dafür finden Sie unter Fotos einfach aufnehmen: Foto mit der Kamera App aufnehmen.

Dateien für mehrere Profile freigeben

Jedes Profil hat einen eigenen Dateispeicher. Da sich ein Datei-URI auf einen bestimmten Speicherort im Dateispeicher bezieht, bedeutet dies, dass ein Datei-URI, der für ein Profil gültig ist, für das andere nicht gültig ist. Dies ist normalerweise kein Problem für eine Anwendung, die normalerweise nur auf die von ihr erstellten Dateien zugreift. Wenn eine Anwendung jedoch eine Datei an einen Intent anhängt, ist das Anhängen eines Datei-URI nicht sicher, da der Intent unter Umständen in einem anderen Profil verarbeitet wird. Ein Geräteadministrator kann beispielsweise festlegen, dass Bildaufnahmeereignisse von der Kamera-App im privaten Profil verarbeitet werden sollen. Wenn der Intent von einer App im verwalteten Profil ausgelöst wird, muss die Kamera das Bild an einen Speicherort schreiben können, an dem die Apps des verwalteten Profils es lesen können.

Wenn Sie eine Datei an einen Intent anhängen müssen, der möglicherweise von einem Profil zum anderen übergeht, sollten Sie zur Sicherheit einen Inhalts-URI für die Datei erstellen und verwenden. Weitere Informationen zur Freigabe von Dateien für Inhalts-URIs finden Sie unter Dateien freigeben. Beispielsweise kann der Geräteadministrator zulassen, dass ACTION_IMAGE_CAPTURE von der Kamera im privaten Profil verwaltet wird. Der EXTRA_OUTPUT des auslösenden Intents sollte einen Inhalts-URI enthalten, der angibt, wo das Foto gespeichert werden soll. Die Kamera-App kann das Bild an den durch diesen URI angegebenen Ort schreiben. Die App, die den Intent ausgelöst hat, kann diese Datei lesen, auch wenn sich die App in dem anderen Profil befindet.

Unterstützung für Sperrbildschirm-Widget entfernt

Unter Android 5.0 werden keine Sperrbildschirm-Widgets mehr unterstützt. Widgets auf dem Startbildschirm werden jedoch weiterhin unterstützt.