Mit Android Vitals die technische Qualität von Apps beobachten

Wenn Sie weitere Informationen zu einem bestimmten Messwert aufrufen möchten, klicken Sie daneben auf Details ansehen (). Auf dem nächsten Bildschirm wird Folgendes angezeigt:

• Grenzwerte zu unerwünschtem Verhalten
• Benchmark-Kategorien
• Detaillierte Benchmark-Vergleiche
  • Um eine benutzerdefinierte Gruppe ähnlicher Apps zu bearbeiten, wählen Sie oben auf der Seite auf der Karte zum App-Vergleich die Option Gruppe ähnlicher Apps bearbeiten aus. Nachdem Sie eine solche Gruppe erstellt haben, können Sie sehen, wie Ihre App bei Google Play im Vergleich zu anderen, von Ihnen ausgewählten Apps abschneidet.
• Trend der Messwerte im Zeitverlauf

Die Messwerte zur ANR-Rate geben einen Überblick über die Qualität Ihrer App. Zur Berechnung dieser Messwerte wird die Zahl der Nutzer ermittelt, bei denen ANR-Fehler aufgetreten sind, und diese dann anhand der App-Nutzung normalisiert. Die Messwerte werden als Prozentsatz der aktiven Nutzer pro Tag angezeigt. Zu „Aktiver Nutzer pro Tag“ zählt jeder Nutzer, der die App an einem Tag auf einem Gerät verwendet. Wenn ein Nutzer Ihre App an einem Tag auf mehreren Geräten verwendet, wird jedes Gerät zur Zahl der aktiven Nutzer an diesem Tag addiert. Verwenden mehrere Nutzer an einem Tag dasselbe Gerät, zählt dies als ein aktiver Nutzer.

Es gibt drei Messwerte zu ANR-Raten:

• Rate der vom Nutzer wahrgenommenen ANR-Fehler: Prozentsatz der aktiven Nutzer pro Tag, bei denen mindestens ein vom Nutzer wahrgenommener ANR-Fehler aufgetreten ist. Ein vom Nutzer wahrgenommener ANR-Fehler ist ein ANR, den der Nutzer wahrscheinlich bemerkt hat. Derzeit werden nur ANR-Fehler mit einer Zeitüberschreitung bei der Eingabe gezählt. Dieser Messwert ist immer niedriger als die ANR-Rate insgesamt, weil er durch die tägliche Nutzung normalisiert wird, aber nicht alle ANR-Fehler berücksichtigt werden.
  Die Rate der vom Nutzer wahrgenommenen ANR-Fehler ist ein Vitalparameter, d. h., er beeinflusst die Sichtbarkeit Ihrer App bei Google Play. Er ist wichtig, weil die gezählten ANR-Fehler immer auftreten, während der Nutzer mit der App interagiert, und daher die größte Störung verursachen.
• ANR-Rate: Prozentsatz der Nutzer pro Tag, bei denen mindestens ein ANR-Fehler aufgetreten ist. Dieser Messwert umfasst ANRs, die nicht als „vom Nutzer wahrgenommen“ eingestuft werden. Wir können jedoch nicht mit Sicherheit sagen, dass die Nutzung durch diese ANR-Fehler nicht beeinträchtigt wurde.
• Mehrfach-ANR-Rate: Prozentsatz der Nutzer pro Tag, bei denen mindestens zwei ANR-Fehler aufgetreten sind. Mit diesem Messwert lassen sich Fehlerschleifen erkennen.

Problem beheben

Die ANR-Fehler, die für die Messwerte zur ANR-Rate berücksichtigt wurden, werden auf der Seite Abstürze und ANRs aufgeführt. Auf dieser Seite können Sie nach vom Nutzer wahrgenommenen ANR-Fehlern filtern.

Auf der Website für Android-Entwickler finden Sie Informationen zur Diagnose und Behebung von ANR-Fehlern.

Die Messwerte zur Absturzrate geben einen Überblick über die Qualität Ihrer App. Zur Berechnung dieser Messwerte wird die Zahl der Nutzer ermittelt, bei denen Abstürze aufgetreten sind, und diese dann anhand der App-Nutzung normalisiert. Die Messwerte werden als Prozentsatz der Nutzer pro Tag angezeigt. Zu „Nutzer pro Tag“ zählt jeder Nutzer, der die App an einem Tag auf einem Gerät verwendet. Wenn ein Nutzer mehr als ein Gerät hat, wird er mehrmals gezählt. Verwenden beispielsweise zwei Nutzer die App zwei Tage lang auf jeweils einem Gerät, werden vier tägliche Sitzungen gezählt.

Es gibt drei Messwerte zur Absturzrate:

• Rate der vom Nutzer wahrgenommenen Abstürze: Prozentsatz der Nutzer pro Tag, bei denen mindestens ein vom Nutzer wahrgenommener Absturz aufgetreten ist. Ein vom Nutzer wahrgenommener Absturz ist ein Absturz, den der Nutzer wahrscheinlich bemerkt hat. Dazu gehören zum Beispiel Abstürze, die auftreten, solange in Ihrer App eine Aktivität angezeigt oder sie als Dienst im Vordergrund ausgeführt wird. Dieser Messwert ist immer niedriger als die Absturzrate insgesamt, weil er durch die tägliche Nutzung normalisiert wird, aber nicht alle Abstürze berücksichtigt werden.
  Die Rate der vom Nutzer wahrgenommenen Abstürze ist ein Vitalparameter, d. h., er beeinflusst die Sichtbarkeit Ihrer App bei Google Play. Das ist wichtig, weil die gezählten Abstürze immer auftreten, während der Nutzer mit der App interagiert, und daher die größte Störung verursachen. Aus diesem Grund sollten Sie dafür sorgen, dass Ihre App den Grenzwert zu unerwünschtem Verhalten für diesen Messwert nicht überschreitet.

• Absturzrate: Prozentsatz der Nutzer pro Tag, bei denen mindestens ein Absturz aufgetreten ist. Dieser Messwert umfasst Abstürze, die nicht als „vom Nutzer wahrgenommen“ eingestuft werden. Wir können jedoch nicht mit Sicherheit sagen, dass die Nutzung durch diese Abstürze nicht beeinträchtigt wurde.

• Mehrfachabsturzrate: Prozentsatz der Nutzer pro Tag, bei denen mindestens zwei Abstürze aufgetreten sind. Mit diesem Messwert lassen sich Fehlerschleifen erkennen.

Problem beheben

Auf der Website für Android-Entwickler finden Sie Informationen zur Diagnose und Behebung von Abstürzen.

Auf der Seite Startzeit finden Sie die Details zu langsamen Kaltstartzeiten, Warmstartzeiten und Heißstartzeiten der App. Die Startzeit entspricht der Zeitspanne zwischen dem Starten Ihrer App durch den Nutzer und der Anzeige der ersten Frames auf dem Bildschirm. Das wird auch als „Zeit bis zur ersten Anzeige“ bezeichnet.

Ihre App ist nach dieser Zeit möglicherweise noch nicht für eine Nutzerinteraktion bereit, z. B. wenn sie zusätzliche Bildschirme hat, die geladen werden.

Details zur Datenerhebung

• Startzeiten werden nur aufgezeichnet, wenn ein Nutzer eine Aktivität auslöst.
  • Beispiel: Bei Tastatur-Apps entspricht die Startzeit der Startzeit der Companion App.
• Wird eine App an einem Tag mehrmals aus demselben Systemzustand gestartet, wird die längste Startzeit des Tages aufgezeichnet.
• Startzeiten werden erfasst, sobald der erste Frame der App vollständig geladen wurde, auch wenn der Nutzer nicht mit diesem Bildschirm interagiert.
  • Beispiel: Wenn eine App mit einem Ladebildschirm startet, entspricht die Startzeit der Zeit, die zum Aufrufen des Ladebildschirms erforderlich war.

Details zu Android Vitals

• Betroffene Sitzungen: Prozentsatz der Sitzungen, bei denen Nutzer für den jeweiligen Systemzustand eine lange Startzeit hatten:
  • Lange Kaltstartzeit: 5 Sekunden oder länger
  • Lange Warmstartzeit: 2 Sekunden oder länger
  • Lange Heißstartzeit: 1 Sekunde oder länger
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
• 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen Nutzer lange App-Startzeiten hatten.

Problem beheben

Werden für Ihre App viele lange App-Startzeiten aufgezeichnet, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Warum ist das wichtig?

Durch die Analyse langsamer Sitzungen können Sie die Framerateleistung Ihres Spiels nachvollziehen, die sich darauf auswirkt, wie flüssig und ruckelfrei sich Ihr Spiel für Nutzer anfühlt.

Daten Ihrer App analysieren

Auf der Seite „Langsame Sitzungen“ finden Sie den Prozentsatz der täglichen Sitzungen, bei denen mehr als 25 % der Frames langsamer als 30 oder 20 fps dargestellt wurden, je nachdem, welche Benchmark Sie ausgewählt haben. Sie können sich auch die Verteilung der Sitzungen nach Framerate für Ihr Spiel ansehen. Die Framerate auf Sitzungsebene wird im 75. Perzentil gemessen. Das bedeutet, dass 75 % der Frames mindestens diese Framerate erreichen.

Die meisten Spiele bei Google Play sollten mindestens 30 fps erreichen. Unabhängig von der Art des Spiels ist das der Wert, ab dem ein Spiel für Nutzer geeignet ist. Insbesondere auf hochwertigeren Geräten bevorzugen manche Nutzer aber mindestens 60 fps. Behalten Sie den Messwert für den Anteil langsamer Sitzungen (30 fps) im Blick, damit Sie diesen Grenzwert auch sicher erreichen. Beachten Sie, dass dieser Messwert nur Sitzungen umfasst, bei denen mehr als 25 % der Frames keine 30 fps erreichen, es besteht also etwas Toleranz im Hinblick auf die Frameratevariabilität.

30 fps bieten zwar eine angemessene Qualität, es kann aber Situationen oder Arten von Spielen geben, bei denen es sinnvoll ist, die Framerate darunter anzusetzen. Es kann außerdem auch vorkommen, dass Nutzer Ihr Spiel auf Smartphones spielen möchten, die keine 30 fps unterstützen. In diesen Szenarien sollten mindestens 75 % der Frames in einer Sitzung weiterhin 20 fps erreichen. Behalten Sie den Messwert für den Anteil langsamer Sitzungen (20 fps) im Blick, damit Sie diesen Grenzwert auch sicher erreichen.

Android Vitals meldet langsame Sitzungen (30 fps sowie 20 fps) für jedes Gerät sowie für alle Geräte und Sitzungen. Anhand des Gesamtmesswerts können Sie sich ein Bild von der Qualität insgesamt machen, achten Sie aber auch auf die Leistung bei einzelnen Geräten. Google Play wird früher oder später dazu übergehen, Nutzern Spiele nicht mehr zu empfehlen, die keine 20 fps auf ihren Smartphones erreichen.

Vitals beginnt erst eine Minute nach dem Start Ihres Spiels, seine Framerate zu erfassen.

Details zur Datenerhebung

Der Messwert für langsame Sitzungen wird mit Daten von SurfaceFlinger berechnet. Genauer gesagt wird die Framerate einer Sitzung basierend auf der Zeit zwischen den Frames berechnet, die auf Oberflächen der App gezeichnet wurden. Dazu gehören Frames, die von OpenGL, Vulkan und dem Android-UI-Toolkit gerendert werden. Dieser Messwert ist derzeit nur für Spiele verfügbar.

Für Geräte mit Android 9 und höher werden Daten zur Framerate bei langsamen Sitzungen erhoben.

Dashboardanzeige

• Repräsentative Framerate: Die Framerate für Ihr Spiel auf Geräten mit Android 9 und höher, die im 75. Perzentil berechnet wird. Das bedeutet, dass diese Framerate in 75 % der Sitzungen erreicht wurde oder höher war.
• Anteil langsamer Sitzungen im Zeitverlauf: Eine Zeitreihe mit dem Prozentsatz der Sitzungen, die als „Langsame Sitzungen“ eingestuft werden.
• Framerate-Verteilung: Histogramm, das das 75. Perzentil der Framerate für mehrere Sitzungen zeigt. Das bedeutet, dass 75 % der Frames in einer Sitzung schneller waren als die Framerate, mit der die Sitzung gruppiert wurde.

Problem beheben

Wenn bei Ihrer App viele Sitzungen langsam ausgeführt werden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Daten Ihrer App analysieren

Auf der Seite „Übermäßig langsame Frames“ finden Sie den Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames die Rendering-Frist des Geräts nicht einhalten. Nutzerinteraktionen mit Ihrer App werden üblicherweise mit 60 Frames pro Sekunde ausgeführt, ohne dass Frames ausgelassen oder verzögert werden.

Details zur Datenerhebung

Google erfasst nur die Renderingzeit der Frames, die von Ihrer App mit dem UI Toolkit gerendert werden. Mithilfe von OpenGL oder Vulkan direkt gerenderte Frames gehören nicht dazu.

Dashboardanzeige

Wenn Sie eine Zeile auswählen, sehen Sie die Daten in Perzentile unterteilt.

• Betroffene Sitzungen: Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames länger als 16 ms gerendert wurden. Die Kennzahl „tägliche Sitzung“ bezeichnet einen Tag, an dem Ihre App genutzt wurde. Wenn beispielsweise zwei Nutzer die App zwei Tage lang verwenden, werden vier tägliche Sitzungen erstellt.
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
• 90./99. Perzentil: 90 % bzw. 99 % der Frames insgesamt hatten eine Renderingzeit, die kürzer war als der angegebene Wert. Diese Werte beruhen auf allen erfassten Frames.

Wenn Sie auf einen Tabelleneintrag klicken, wird das Diagramm „Verteilung der UI-Renderingzeit“ angezeigt. Hier sollten Sie prüfen, ob die meisten Frames Ihrer App bei oder unter 16 ms liegen.

Anhand der Daten unterhalb des Diagramms können Sie die Rendering-Leistung der App analysieren und so möglicherweise die Ursache potenzieller Rendering-Probleme erkennen. Wenn beispielsweise der Prozentsatz unter „Hohe Eingabelatenz“ hoch ausfällt, sollten Sie eventuell den App-Code prüfen, der Nutzereingaben verarbeitet. Weitere Informationen zu diesen Messwerten finden Sie im Artikel UI-Leistung testen.

• Verpasste VSync-Ereignisse: Für alle in mehr als 16 ms gerenderten Frames die Anzahl verpasster VSync-Ereignisse geteilt durch die Anzahl der Frames.
• Hohe Eingabelatenz: Für alle in mehr als 16 ms gerenderten Frames die Anzahl der Eingabeereignisse, für die mehr als 24 ms benötigt wurden, geteilt durch die Anzahl der Frames.
• Langsamer UI‑Thread: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der für den Abschluss des UI-Threads mehr als 8 ms benötigt wurden, geteilt durch die Anzahl der Frames.
• Langsame Zeichenbefehle: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Senden von Zeichenbefehlen an die GPU mehr als 12 ms benötigt wurden, geteilt durch die Anzahl der Frames.
• Langsame Bitmap-Uploads: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Hochladen der Bitmap-Datei in die GPU mehr als 3,2 ms benötigt wurden, geteilt durch die Anzahl der Frames.

Problem beheben

Wenn in Ihrer App viele Frames in mehr als 16 ms gerendert werden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Daten Ihrer App analysieren

Auf der Seite „Übermäßig langsame Frames“ finden Sie den Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames die Rendering-Frist des Geräts nicht einhalten. Nutzerinteraktionen mit Ihrer App werden üblicherweise mit 60 Frames pro Sekunde ausgeführt, ohne dass Frames ausgelassen oder verzögert werden.

Details zur Datenerhebung

Google erfasst nur die Renderingzeit der Frames, die von Ihrer App mit dem UI Toolkit gerendert werden. Mithilfe von OpenGL oder Vulkan direkt gerenderte Frames gehören nicht dazu.

Dashboardanzeige

Wenn Sie eine Zeile auswählen, sehen Sie die Daten in Perzentile unterteilt.

• Betroffene Sitzungen: Prozentsatz der täglichen Sitzungen, bei denen mehr als 50 % der Frames länger als 16 ms gerendert wurden. Die Kennzahl „tägliche Sitzung“ bezeichnet einen Tag, an dem Ihre App genutzt wurde. Wenn beispielsweise zwei Nutzer die App zwei Tage lang verwenden, werden vier tägliche Sitzungen erstellt.
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
• 90./99. Perzentil: 90 % bzw. 99 % der Frames insgesamt hatten eine Renderingzeit, die kürzer war als der angegebene Wert. Diese Werte beruhen auf allen erfassten Frames.

Wenn Sie auf einen Tabelleneintrag klicken, wird das Diagramm „Verteilung der UI-Renderingzeit“ angezeigt. Hier sollten Sie prüfen, ob die meisten Frames Ihrer App bei oder unter 16 ms liegen.

Anhand der Daten unterhalb des Diagramms können Sie die Rendering-Leistung der App analysieren und so möglicherweise die Ursache potenzieller Rendering-Probleme erkennen. Wenn beispielsweise der Prozentsatz unter „Hohe Eingabelatenz“ hoch ausfällt, sollten Sie eventuell den App-Code prüfen, der Nutzereingaben verarbeitet. Weitere Informationen zu diesen Messwerten finden Sie im Artikel UI-Leistung testen.

• Verpasste VSync-Ereignisse: Für alle in mehr als 16 ms gerenderten Frames die Anzahl verpasster VSync-Ereignisse geteilt durch die Anzahl der Frames.
• Hohe Eingabelatenz: Für alle in mehr als 16 ms gerenderten Frames die Anzahl der Eingabeereignisse, für die mehr als 24 ms benötigt wurden, geteilt durch die Anzahl der Frames.
• Langsamer UI‑Thread: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der für den Abschluss des UI-Threads mehr als 8 ms benötigt wurden, geteilt durch die Anzahl der Frames.
• Langsame Zeichenbefehle: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Senden von Zeichenbefehlen an die GPU mehr als 12 ms benötigt wurden, geteilt durch die Anzahl der Frames.
• Langsame Bitmap-Uploads: Für alle in mehr als 16 ms gerenderten Frames die Häufigkeit, mit der zum Hochladen der Bitmap-Datei in die GPU mehr als 3,2 ms benötigt wurden, geteilt durch die Anzahl der Frames.

Problem beheben

Wenn in Ihrer App viele Frames in mehr als 16 ms gerendert werden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Auf den Seiten Hängende Teil-Wakelocks und Hängende Teil-Wakelocks im Hintergrund werden Teil-Wakelocks angezeigt, die Ihre App aus der Klasse „PowerManager“ übernommen hat. Bei einem Teil-Wakelock können das Display und die Tastaturbeleuchtung bei aktiver CPU ausgeschaltet werden.

Details zur Datenerhebung

• Zum Schutz der Privatsphäre werden die Tags zur Identifizierung von Teil-Wakelocks anonymisiert.
• Daten zu Teil-Wakelocks werden erfasst, während das Gerät gerade nicht geladen wird und der Bildschirm ausgeschaltet ist.
• Daten zu hängenden Teil-Wakelocks im Hintergrund werden nur erhoben, wenn die App im Hintergrund ausgeführt wird.
• Google berechnet die Höchstdauer der Teil-Wakelocks pro Akkusitzung, um zu analysieren, wie viele Sitzungen von einem langen Wakelock betroffen sind. Wenn ein Nutzer beispielsweise zwei Wakelocks von je einer Stunde auslöst, legt Google den Wert der Höchstdauer auf eine Stunde fest.
• Für Apps, bei denen in der Manifestdatei eine sharedUserId festgelegt wurde: Es werden nur Daten angezeigt, wenn höchstens eine App mit derselben sharedUserId installiert wurde.

Details zu Android Vitals

• Betroffene Sitzungen: Prozentsatz der Sitzungen, bei denen mindestens ein Wakelock von mehr als einer Stunde genutzt wurde.
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
• 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen Teil-Wakelocks von einer längeren Dauer als dem angezeigten Wert stattgefunden haben.
• Grenzwert zu unerwünschtem Verhalten: Wenn Ihre App über dem angezeigten Grenzwert liegt oder ihm entspricht, gehört sie zu den unteren 25 % der 1.000 meist installierten Apps bei Google Play.

Problem beheben

Wenn Ihre App eine hohe Anzahl von hängenden Teil-Wakelocks hat, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Auf der Seite Übermäßige Wakeups werden AlarmManager-Wakeups angezeigt, die von Ihrer App ausgelöst wurden. Hier sehen Sie Wakeup-Daten der Klassen ELAPSED_REALTIME_WAKEUP oder RTC_WAKEUP.

Details zur Datenerhebung

• Aus Datenschutzgründen werden die Tags zur Identifizierung von Wakeups anonymisiert.
• Wakeups werden erfasst, während das Gerät gerade nicht geladen wird.
• Um einen normalisierten Messwert zu liefern, wird die Anzahl der Wakeups mit der Akkulaufzeit verglichen. Google berechnet die Anzahl der Wakeups pro Nutzer pro Stunde, um zu analysieren, wie viele Nutzer von einer hohen Wakeup-Rate betroffen sind.
• Für Apps, bei denen in der Manifestdatei eine sharedUserId festgelegt wurde: Es werden nur Daten angezeigt, wenn höchstens eine App mit derselben sharedUserId installiert wurde.

Details zu Android Vitals

• Betroffene Sitzungen: Prozentsatz der Akkusitzungen, bei denen Nutzer mehr als zehn Wakeups pro Stunde hatten. Eine Akkusitzung ist die Zusammenfassung aller Akkuberichte, die innerhalb eines festgelegten Zeitraums von 24 Stunden empfangen wurden. In Android 10 bezieht sich ein Akkubericht auf das Intervall zwischen zwei Akkuladungen: entweder von unter 20 % bis über 80 % oder von einem beliebigen Wert bis 100 %. Ab Android 11 bezieht sich ein Akkubericht auf einen festen Zeitraum von 24 Stunden. Google erfasst die Daten nur, während das Gerät nicht geladen wird.
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
• 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen Nutzer mehr Wakeups pro Stunde hatten als den angegebenen Wert.
• Grenzwert zu unerwünschtem Verhalten: Wenn Ihre App über dem angezeigten Grenzwert liegt oder ihm entspricht, gehört sie zu den unteren 25 % der 1.000 meist installierten Apps bei Google Play.

Problem beheben

Wenn in Ihrer App häufig Wakeups vorkommen, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Auf der Seite Übermäßig viele WLAN-Scans im Hintergrund wird angezeigt, wenn WLAN-Scans den Akku stark beanspruchen.

Details zur Datenerhebung

Daten zu WLAN-Scans werden erfasst, während das Gerät gerade nicht geladen und die App im Hintergrund ausgeführt wird.

Details zu Android Vitals

• Betroffene Sitzungen: Prozentsatz der Akkusitzungen, bei denen mehr als vier WLAN‑Scans pro Stunde durchgeführt wurden.
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
• 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen im Hintergrund mehr WLAN‑Scans pro Stunde durchgeführt wurden als der angezeigte Wert.

Problem beheben

Wenn auf Ihrem Gerät viele WLAN-Scans im Hintergrund auftreten, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Auf der Seite Übermäßige Mobilfunknutzung im Hintergrund wird angezeigt, wenn einem Hintergrunddienst große Mengen Netzwerkdaten zugeordnet sind. Wenn die Mobilfunknutzung im Hintergrund erfolgt, ist es Nutzern aufgrund fehlender Steuerelemente nicht ohne Weiteres möglich, die Datenübertragung zu stoppen.

Details zur Datenerhebung

Daten zur Mobilfunknutzung werden erfasst, während das Gerät gerade nicht geladen und die App im Hintergrund ausgeführt wird.

Details zu Android Vitals

• Betroffene Sitzungen: Prozentsatz der Akkusitzungen, bei denen pro Tag mehr als 50 MB Mobilfunkdaten im Hintergrund genutzt wurden.
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.
• 90./99. Perzentil: 10 % bzw. 1 % der täglichen Sitzungen, bei denen im Hintergrund eine höhere tägliche Mobilfunknutzung stattfand als der angezeigte Wert.

Problem beheben

Wenn Ihre App eine starke Mobilfunknutzung im Hintergrund verursacht, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Auf der Seite Abgelehnte Berechtigungen sehen Sie Details zum Prozentsatz der täglichen Berechtigungssitzungen, bei denen Nutzer Berechtigungen verweigert haben. Eine tägliche Berechtigungssitzung bezieht sich auf einen Tag, an dem Ihre App mindestens eine Berechtigungsanfrage an einen Nutzer stellt.

Details zur Datenerhebung

Daten zu abgelehnten Berechtigungen werden erfasst, wenn Nutzer auf Berechtigungsanfragen in Ihrer App reagieren.

Details zu Android Vitals

• Ablehnungen: Prozentsatz der täglichen Berechtigungssitzungen, bei denen Nutzer Berechtigungen verweigert haben
• Nicht mehr fragen: Prozentsatz der täglichen Berechtigungssitzungen, bei denen Nutzer die Option „Nicht mehr fragen“ ausgewählt und damit Berechtigungen verweigert haben.
• Anzahl der Sitzungen: Ungefähre Anzahl der aufgezeichneten Sitzungen.

Problem beheben

Wenn in Ihrer App viele Berechtigungen abgelehnt wurden, finden Sie auf der Website für Android-Entwickler Lösungsansätze.

Google Play hat Grenzwerte zu unerwünschtem Verhalten für die Rate der vom Nutzer wahrgenommenen ANR-Fehler definiert:

• Unerwünschtes Verhalten auf allen Geräten: Bei mindestens 0,47 % der aktiven Nutzer pro Tag tritt auf allen Gerätemodellen ein vom Nutzer wahrgenommener ANR-Fehler auf.

• Unerwünschtes Verhalten auf einzelnen Geräten: Bei mindestens 8 % der aktiven Nutzer pro Tag tritt bei einem einzelnen Gerätemodell ein vom Nutzer wahrgenommener ANR-Fehler auf.

Um die ANR-Rate zu verbessern, korrigieren Sie die zugrunde liegenden ANR-Cluster, die auf der Seite Abstürze und ANRs aufgeführt werden. Je größer die Anzahl der betroffenen Nutzer ist, desto stärker fällt dieser Cluster bei der ANR-Rate ins Gewicht.

Falls bestimmte Aspekte der Gerätehardware oder ‑software zur ANR-Rate beitragen, werden Sie von Android Vitals benachrichtigt. Sie können sich die Zusammenhänge auch auf der Seite Übersicht zu Reichweite und Geräten ansehen (Beobachten und verbessern > Reichweite und Geräte > Übersicht).

Google Play hat Grenzwerte zu unerwünschtem Verhalten für die Rate der vom Nutzer wahrgenommenen Abstürze definiert:

• Unerwünschtes Verhalten auf allen Geräten: Auf allen Gerätemodellen tritt bei mindestens 1,09 % der Nutzer pro Tag ein vom Nutzer wahrgenommener Absturz auf.

• Unerwünschtes Verhalten auf einzelnen Geräten: Bei einem einzelnen Gerätemodell tritt bei mindestens 8 % der Nutzer pro Tag ein vom Nutzer wahrgenommener Absturz auf.

Um die Absturzrate zu verbessern, korrigieren Sie die zugrunde liegenden Absturzcluster, die auf der Seite Abstürze und ANRs aufgeführt werden. Je größer die Anzahl der betroffenen Nutzer ist, desto stärker fällt dieser Cluster bei der Absturzrate ins Gewicht.

Falls bestimmte Aspekte der Gerätehardware oder ‑software zur Absturzrate beitragen, werden Sie von Android Vitals benachrichtigt. Sie können sich die Zusammenhänge auch auf der Seite Übersicht zu Reichweite und Geräten ansehen (Beobachten und verbessern > Reichweite und Geräte > Übersicht).