Diese Seite wurde von der Cloud Translation API übersetzt.

Verhaltensänderungen unter Android 5.0

API-Ebene: 21

Neben neuen Funktionen und Fähigkeiten enthält Android 5.0 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, kann diese von den Änderungen in Android 5.0 betroffen sein.

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

Videos

Dev Byte: Das ist neu in Android 5.0

Dev Byte: Benachrichtigungen

Android Runtime ("ART")

In Android 5.0 ersetzt die ART-Laufzeit Dalvik als Standardplattform. Die ART-Laufzeit wurde in Android 4.4 auf experimenteller Basis eingeführt.

Einen Überblick über die neuen Funktionen von ART finden Sie unter ART – Einführung. Zu den wichtigsten neuen Funktionen gehören:

Vorabkompilierung (AOT)
Verbesserte automatische Speicherbereinigung
Verbesserte Unterstützung bei der Fehlerbehebung

Die meisten Android-Apps sollten unter ART ohne Änderungen funktionieren. Einige Techniken, die unter Dalvik funktionieren, funktionieren unter ART jedoch nicht. Informationen zu den wichtigsten Problemen finden Sie unter App-Verhalten in Android Runtime (ART) überprüfen. Achten Sie besonders darauf, wenn:

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

Benachrichtigungen

Berücksichtigen Sie diese Änderungen bei Android 5.0 bei Ihren Benachrichtigungen. Weitere Informationen zum Entwerfen von Benachrichtigungen für Android 5.0 und höher finden Sie im Leitfaden zur Gestaltung von Benachrichtigungen.

Material Design-Stil

Benachrichtigungen werden mit dunklem Text auf weißem (oder sehr hellem) Hintergrund dargestellt, um den neuen Material Design-Widgets zu entsprechen. Prüfen Sie, ob alle Benachrichtigungen im neuen Farbschema richtig aussehen. Wenn Ihre Benachrichtigungen falsch aussehen, können Sie das Problem so beheben:

Mit setColor() können Sie eine Akzentfarbe in einem Kreis hinter dem Symbolbild festlegen.
Aktualisieren oder entfernen Sie Assets mit Farben. Alle nicht alphanumerischen Kanäle in Aktionssymbolen und im Hauptsymbol für Benachrichtigungen werden vom System ignoriert. Sie sollten davon ausgehen, dass diese Symbole nur aus Buchstaben bestehen. Das System zeichnet Benachrichtigungssymbole weiß und Aktionssymbole dunkelgrau.

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 Modus Priority korrekt anzeigen kann. Verwenden Sie stattdessen Notification.Builder-Methoden, um Töne und Vibrationen hinzuzufügen.

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

Bisher wurde STREAM_MUSIC unter Android als Masterstream verwendet, um die Lautstärke auf Tablets zu regeln. In Android 5.0 ist der Master-Lautstärkestream jetzt für Smartphones und Tablets einheitlich und wird über 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 angezeigt werden. In diesem Fall entfernt das System automatisch den in der Benachrichtigung angezeigten Text. Verwenden Sie setPublicVersion(), um diese gekürzte Benachrichtigung anzupassen.

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

Medienwiedergabe

Wenn Sie Benachrichtigungen implementieren, die den Status der Medienwiedergabe oder die Transportsteuerung anzeigen, sollten Sie die neue Notification.MediaStyle-Vorlage anstelle eines benutzerdefinierten RemoteViews.RemoteView-Objekts verwenden. Unabhängig von der gewählten Methode müssen Sie die Sichtbarkeit der Benachrichtigung auf VISIBILITY_PUBLIC festlegen, damit die Steuerelemente über den Sperrbildschirm zugänglich sind. Hinweis: Ab Android 5.0 zeigt das System keine RemoteControlClient-Objekte mehr auf dem Sperrbildschirm an. Weitere Informationen finden Sie unter Wenn Ihre App RemoteControlClient verwendet.

Vorabbenachrichtigung

Benachrichtigungen können jetzt in einem kleinen schwebenden Fenster (auch als „Vorab-Benachrichtigung“ bezeichnet) angezeigt werden, wenn das Gerät aktiv ist, d. h. entsperrt und der Bildschirm eingeschaltet ist. Diese Benachrichtigungen ähneln der kompakten Form Ihrer Benachrichtigung, mit dem Unterschied, dass die Vorabbenachrichtigung auch Aktionsschaltflächen enthält. Nutzer können eine Push-Benachrichtigung beantworten oder schließen, ohne die aktuelle App zu verlassen.

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

Der Nutzer ist im Vollbildmodus aktiv (die App verwendet fullScreenIntent).
Die Benachrichtigung hat eine hohe Priorität und löst Klingeltöne oder Vibrationen aus.

Wenn in Ihrer App Benachrichtigungen in einem dieser Szenarien implementiert sind, achten Sie darauf, dass wichtige Benachrichtigungen korrekt angezeigt werden.

Mediensteuerung und RemoteControlClient

Die Klasse RemoteControlClient wurde eingestellt. Wechseln Sie so bald wie möglich zur neuen MediaSession API.

Auf Sperrbildschirmen unter Android 5.0 werden keine Transportsteuerungen für MediaSession oder RemoteControlClient angezeigt. Stattdessen kann Ihre App die Medienwiedergabe über eine Benachrichtigung auf dem Sperrbildschirm steuern. So haben Sie mehr Kontrolle über die Darstellung der Medienschaltflächen und bieten Nutzern auf gesperrten und entsperrten Geräten eine einheitliche Benutzeroberfläche.

Android 5.0 führt zu diesem Zweck eine neue Notification.MediaStyle-Vorlage ein. 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. Übergebe dein Sitzungstoken an die Methode setSession(), um das System darüber zu informieren, dass diese Benachrichtigung eine laufende Mediensitzung steuert.

Legen Sie die Sichtbarkeit der Benachrichtigung auf VISIBILITY_PUBLIC fest, um sie als sicher für die Anzeige auf jedem Sperrbildschirm (gesichert oder nicht) zu kennzeichnen. Weitere Informationen finden Sie unter Benachrichtigungen auf dem Sperrbildschirm.

Wenn Sie Steuerelemente für die Medienwiedergabe anzeigen möchten, wenn Ihre App auf der Plattform Android TV oder Wear ausgeführt wird, implementieren Sie die Klasse MediaSession. Sie sollten MediaSession auch implementieren, wenn Ihre App Medienschalter-Ereignisse auf Android-Geräten empfangen muss.

getRecentTasks()

Mit der Einführung der neuen Funktion Gleichzeitige Dokumente und Aktivitäten in Android 5.0 (siehe unten Gleichzeitige Dokumente und Aktivitäten auf dem Bildschirm „Letzte“) wird die Methode ActivityManager.getRecentTasks() eingestellt, um die Datensicherheit für Nutzer zu verbessern. Aus Gründen der Abwärtskompatibilität gibt diese Methode weiterhin einen kleinen Teil der Daten zurück, einschließlich der Aufgaben der aufrufenden Anwendung und möglicherweise einiger anderer nicht sensibler Aufgaben (z. B. „Zuhause“). Wenn Ihre App diese Methode verwendet, um eigene Aufgaben abzurufen, verwenden Sie stattdessen getAppTasks(), um diese Informationen abzurufen.

64-Bit-Unterstützung im Android NDK

Android 5.0 unterstützt 64-Bit-Systeme. Die 64‑Bit-Erweiterung erhöht den Adressraum und verbessert die Leistung, während vorhandene 32‑Bit-Apps weiterhin vollständig unterstützt werden. Die 64-Bit-Unterstützung verbessert auch die Leistung von OpenSSL für die Kryptografie. Außerdem werden in dieser Version neue native NDK-Medien-APIs sowie native OpenGL ES 3.1-Unterstützung eingeführt.

Wenn Sie die 64‑Bit-Unterstützung von Android 5.0 verwenden möchten, laden Sie NDK Revision 10c von der Android NDK-Seite herunter und installieren Sie es. Weitere Informationen zu wichtigen Änderungen und Fehlerkorrekturen am NDK finden Sie in den Versionshinweisen zu Revision 10c.

An einen Dienst binden

Für die Methode Context.bindService() ist jetzt ein explizites Intent erforderlich. Bei einer impliziten Intent-Anfrage wird eine Ausnahme ausgelöst. Verwenden Sie zum Schutz Ihrer App eine explizite Absicht, wenn Sie Ihren Service starten oder binden, und deklarieren Sie keine Intent-Filter für den Dienst.

WebView

Unter Android 5.0 ändert sich das Standardverhalten Ihrer App.

Wenn Ihre App auf API-Level 21 oder höher ausgerichtet ist:
- Das System blockiert standardmäßig gemischte Inhalte und Drittanbieter-Cookies. Wenn Sie gemischte Inhalte und Drittanbieter-Cookies zulassen möchten, verwenden Sie die Methoden setMixedContentMode() und setAcceptThirdPartyCookies().
- Das System wählt jetzt intelligent Teile des HTML-Dokuments aus, die gezeichnet werden sollen. Dieses neue Standardverhalten trägt dazu bei, 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-Ebenen unter 21 ausgerichtet ist:Das System erlaubt gemischte Inhalte und Drittanbieter-Cookies und rendert das gesamte Dokument immer auf einmal.

Eindeutigkeitsanforderung für benutzerdefinierte Berechtigungen

Wie in der Übersicht zu Berechtigungen beschrieben, können Android-Apps benutzerdefinierte Berechtigungen definieren, um den Zugriff auf Komponenten auf proprietäre Weise zu verwalten, 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 die Definition benutzerdefinierter Berechtigungen ein legitimer und sicherer Ansatz ist. Das Erstellen benutzerdefinierter Berechtigungen ist jedoch manchmal nicht erforderlich und kann je nach dem Schutzniveau, das den Berechtigungen zugewiesen ist, sogar ein potenzielles Risiko für eine App darstellen.

Unter Android 5.0 wurde eine Verhaltensänderung eingeführt, damit nur eine App eine bestimmte benutzerdefinierte Berechtigung definieren kann, es sei denn, sie ist mit demselben Schlüssel signiert wie andere Apps, die die Berechtigung definieren.

Apps mit doppelten benutzerdefinierten Berechtigungen

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

Unter Android 4.4 und niedriger konnten Nutzer mehrere solcher Apps auf einem bestimmten Gerät installieren, obwohl das System das Schutzniveau der zuerst installierten App zuordnete.

Ab Android 5.0 erzwingt das System eine neue Einheitlichkeitsbeschränkung für benutzerdefinierte Berechtigungen für Apps, die mit verschiedenen Schlüsseln signiert sind. Jetzt kann nur eine App auf einem Gerät eine bestimmte benutzerdefinierte Berechtigung definieren (anhand ihres Namens), 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, die nicht mit demselben Schlüssel wie die residente App signiert ist, die die Berechtigung definiert, blockiert das System die Installation.

Hinweise für Ihre App

Unter Android 5.0 und höher können Apps wie bisher eigene benutzerdefinierte Berechtigungen definieren und über den <uses-permission>-Mechanismus benutzerdefinierte Berechtigungen von anderen Apps anfordern. Aufgrund der neuen Anforderung in Android 5.0 sollten Sie jedoch die möglichen Auswirkungen auf Ihre App sorgfältig prüfen.

Beachten Sie dabei Folgendes:

Enthält das Manifest Ihrer App <permission>-Elemente? Wenn ja, sind sie für die ordnungsgemäße Funktion Ihrer App oder Ihres Dienstes tatsächlich erforderlich? Könnten Sie stattdessen eine Standardberechtigung des Systems verwenden?
Wenn Sie <permission>-Elemente in Ihrer App haben, wissen Sie, woher sie stammen?
Möchten Sie, dass andere Apps Ihre benutzerdefinierten Berechtigungen über <uses-permission> anfordern?
Verwenden Sie in Ihrer App Textbausteine oder Beispielcode, der <permission>-Elemente enthält? Sind diese Berechtigungselemente wirklich erforderlich?
Verwenden Sie für Ihre benutzerdefinierten Berechtigungen einfache Namen oder solche, die auf gängigen Begriffen basieren, die auch andere Apps verwenden?

Neue Installationen und Updates

Wie bereits erwähnt, sind neue Installationen und Updates Ihrer App auf Geräten mit Android 4.4 oder niedriger nicht betroffen und es gibt keine Verhaltensänderungen. Bei Neuinstallationen und Updates auf Geräten mit Android 5.0 oder höher verhindert das System die Installation Ihrer App, wenn eine benutzerdefinierte Berechtigung definiert ist, die bereits von einer vorhandenen residenten App definiert wurde.

Vorhandene Installationen mit Systemupdate auf Android 5.0

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

Empfehlungen

Wenn Ihre App auf Geräten mit Android 5.0 oder höher ausgeführt wird, sollten Sie sie sofort prüfen, alle erforderlichen Anpassungen vornehmen und die aktualisierte Version so schnell wie möglich für Ihre Nutzer veröffentlichen.

Wenn Sie benutzerdefinierte Berechtigungen in Ihrer App verwenden, sollten Sie sich überlegen, woher sie stammen und ob Sie sie wirklich benötigen. Entfernen Sie alle <permission>-Elemente aus Ihrer App, es sei denn, Sie sind sich sicher, dass sie für die ordnungsgemäße Funktion Ihrer App erforderlich sind.
Ersetzen Sie nach Möglichkeit Ihre benutzerdefinierten Berechtigungen durch die Standardberechtigungen des Systems.
Wenn Ihre App benutzerdefinierte Berechtigungen erfordert, benennen Sie diese so um, dass sie für Ihre App eindeutig sind. Sie können sie beispielsweise an den vollständigen Paketnamen Ihrer App anhängen.
Wenn Sie eine Suite von Apps haben, die mit verschiedenen Schlüsseln signiert sind und die Apps über eine benutzerdefinierte Berechtigung auf eine freigegebene Komponente zugreifen, muss die benutzerdefinierte Berechtigung nur einmal in der freigegebenen Komponente definiert sein. Apps, die die freigegebene Komponente verwenden, sollten die benutzerdefinierte Berechtigung nicht selbst definieren, sondern stattdessen den Zugriff über den Mechanismus <uses-permission> anfordern.
Wenn Sie eine Suite von Apps haben, die mit demselben Schlüssel signiert sind, kann für jede App dieselbe benutzerdefinierte Berechtigung(en) nach Bedarf definiert werden. Das System ermöglicht die Installation der Apps auf die übliche Weise.

Änderungen an der Standardkonfiguration für TLS/SSL

In Android 5.0 wurde die Standard-TLS/SSL-Konfiguration geändert, die von Apps für HTTPS und anderen TLS/SSL-Traffic verwendet wird:

Die Protokolle TLSv1.2 und TLSv1.1 sind jetzt aktiviert.
AES-GCM-Chiffrensammlungen (AEAD) sind jetzt aktiviert.
MD5-, 3DES-, Export- und ECDH-Chiffrensuites mit statischem Schlüssel sind jetzt deaktiviert.
Cipher Suites mit Forward Secrecy (ECDHE und DHE) werden bevorzugt.

Diese Änderungen können in einigen Fällen (siehe unten) zu Unterbrechungen der HTTPS- oder TLS/SSL-Verbindung führen.

Hinweis: Der Sicherheitsanbieter-Installer der Google Play-Dienste bietet diese Änderungen bereits für alle Android-Plattformversionen bis einschließlich Android 2.3.

Der Server unterstützt keine der aktivierten Verschlüsselungs-Suiten

Ein Server unterstützt beispielsweise möglicherweise nur 3DES- oder MD5-Chiffren. Die bevorzugte Lösung besteht darin, die Serverkonfiguration zu verbessern, um stärkere und modernere Chiffren-Suiten und Protokolle zu aktivieren. Idealerweise sollten TLSv1.2 und AES-GCM aktiviert sein und Forward-Secrecy-Verschlüsselungssammlungen (ECDHE, DHE) aktiviert und bevorzugt werden.

Alternativ können Sie die App so ändern, dass eine benutzerdefinierte SSLSocketFactory für die Kommunikation mit dem Server verwendet wird. Die Factory sollte so konzipiert sein, dass SSLSocket-Instanzen erstellt werden, bei denen neben den Standardchiffrensammlungen auch einige der vom Server benötigten Chiffrensammlungen aktiviert sind.

Die App macht falsche Annahmen über die Chiffrensammlungen, die für die Verbindung zum Server verwendet werden

Einige Apps enthalten beispielsweise einen benutzerdefinierten X509TrustManager, der nicht funktioniert, weil er für den Parameter „authType“ den Wert „RSA“ erwartet, aber „ECDHE_RSA“ oder „DHE_RSA“ findet.

Der Server unterstützt TLS 1.1, TLS 1.2 oder neue TLS-Erweiterungen nicht

Beispielsweise wird der TLS/SSL-Handshake mit einem Server fälschlicherweise abgelehnt oder hängt. 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 und nicht unterstützte TLS-Erweiterungen ignorieren. In einigen Fällen kann das Deaktivieren von TLSv1.1 und TLSv1.2 auf dem Server als Notmaßnahme dienen, bis die Serversoftware aktualisiert wird.

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

Unterstützung für verwaltete Profile

Geräteadministratoren können einem Gerät ein verwaltetes Profil hinzufügen. Der Administrator ist Inhaber dieses Profils und hat somit die Kontrolle über das verwaltete Profil. Das private Profil des Nutzers und sein Speicherplatz bleiben jedoch in seiner Kontrolle. Diese Änderung kann sich auf das Verhalten Ihrer vorhandenen App folgendermaßen auswirken:

Umgang mit Intents

Geräteadministratoren können den Zugriff auf Systemanwendungen über das verwaltete Profil einschränken. Wenn in diesem Fall eine App eine Intent aus dem verwalteten Profil auslöst, die normalerweise von dieser Anwendung verarbeitet würde, und es keinen geeigneten Handler für die Intent im verwalteten Profil gibt, führt die Intent zu einer Ausnahme. So kann der Geräteadministrator beispielsweise Apps im verwalteten Profil den Zugriff auf die Kameraanwendung des Systems untersagen. Wenn Ihre App 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, führt dies zu einer ActivityNotFoundException.

Sie können dies verhindern, indem Sie vor dem Auslösen prüfen, ob es für jede Absicht mindestens einen Handler gibt. Rufe Intent.resolveActivity() auf, um nach einem gültigen Handler zu suchen. Ein Beispiel dafür finden Sie unter Einfach Fotos aufnehmen: Foto mit der Kamera App aufnehmen.

Dateien für alle Profile freigeben

Jedes Profil hat einen eigenen Dateispeicher. Da ein Datei-URI auf einen bestimmten Speicherort im Dateispeicher verweist, ist ein Datei-URI, der in einem Profil gültig ist, in einem anderen Profil nicht gültig. Das ist normalerweise kein Problem für eine App, die in der Regel nur auf die von ihr erstellten Dateien zugreift. Wenn eine App jedoch einer Intent-Aktion eine Datei anhängt, ist es nicht sicher, einen Datei-URI anzuhängen, da die Intent-Aktion unter Umständen im anderen Profil verarbeitet wird. Ein Geräteadministrator kann beispielsweise angeben, dass Ereignisse zur Bildaufnahme von der Kamera-App im privaten Profil verarbeitet werden sollen. Wenn die Absicht von einer App im verwalteten Profil ausgelöst wird, muss die Kamera das Bild an einen Ort schreiben können, an dem es von den Apps des verwalteten Profils gelesen werden kann.

Wenn Sie einer Absicht eine Datei anhängen möchten, die von einem Profil in ein anderes übergehen kann, sollten Sie zur Sicherheit einen Inhalts-URI für die Datei erstellen und verwenden. Weitere Informationen zum Freigeben von Dateien mit Inhalts-URIs finden Sie unter Dateien freigeben. Der Geräteadministrator kann beispielsweise zulassen, dass ACTION_IMAGE_CAPTURE im privaten Profil von der Kamera verarbeitet wird. Das EXTRA_OUTPUT-Attribut der auslösenden Intent-Aktion sollte eine Inhalts-URI enthalten, die angibt, wo das Foto gespeichert werden soll. Die Kamera-App kann das Bild an den mit diesem URI angegebenen Speicherort schreiben und die App, die die Intent ausgelöst hat, kann diese Datei lesen, auch wenn sich die App im anderen Profil befindet.

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