De technische kwaliteit van je app checken met App-vitaliteit

Voor meer informatie over een statistiek selecteer je Details bekijken () naast de statistiek. Op het volgende scherm kun je het onderstaande bekijken:

• Drempelwaarden voor ongewenst gedrag
• Categoriebenchmarks
• Gedetailleerde benchmarkvergelijkingen
  • Selecteer bovenaan de pagina in de vergelijkingskaart de optie Groep met vergelijkbare apps bewerken om een aangepaste groep met vergelijkbare apps te bewerken. Nadat je een aangepaste groep met vergelijkbare apps hebt gemaakt, kun je bekijken hoe je app presteert in vergelijking met andere apps op Google Play die je selecteert.
• Trend in statistieken in de loop van de tijd

Statistieken voor het ANR-percentage bieden een overzicht van de kwaliteit van je app. Deze statistieken worden berekend door het aantal gebruikers met ANR's dat je hebt, te normaliseren op basis van je app-gebruik. Ze worden gerapporteerd als een percentage van de dagelijks actieve gebruikers, waarbij een dagelijks actieve gebruiker wordt gedefinieerd als een gebruiker die de app gebruikt op één dag op één apparaat. Als een gebruiker je app op één dag op meer dan één apparaat gebruikt, draagt elk apparaat bij aan het aantal actieve gebruikers voor die dag. Als meerdere gebruikers hetzelfde apparaat op één dag gebruiken, wordt dit gerekend als één actieve gebruiker.

Er zijn 3 statistieken voor het ANR-percentage:

• Door de gebruiker waargenomen ANR-percentage: Het percentage van je dagelijks actieve gebruikers bij wie ten minste één door de gebruiker waargenomen ANR is opgetreden. Een door de gebruiker waargenomen ANR is een ANR die waarschijnlijk is opgemerkt door de gebruiker. Momenteel worden alleen ANR's van het type 'invoertime-out' meegeteld. Deze statistiek is altijd lager dan je algehele ANR-percentage omdat het is genormaliseerd op basis van het dagelijkse gebruik, maar niet alle ANR's meetelt.
  Het door de gebruiker waargenomen ANR-percentage is een belangrijke vitaliteitsstatistiek die de vindbaarheid van je app op Google Play beïnvloedt. Dit is belangrijk omdat de ANR's die worden geteld altijd optreden als de gebruiker de app gebruikt, wat de meeste problemen veroorzaakt.
• ANR-percentage: Het percentage dagelijkse gebruikers bij wie ten minste 1 ANR is opgetreden. Deze statistiek omvat ANR's die niet zijn geclassificeerd als door de gebruiker waargenomen, maar we kunnen niet garanderen dat deze ANR's geen invloed hebben op gebruikers.
• Multi-ANR-percentage: Het percentage dagelijkse gebruikers bij wie ten minste 2 ANR's zijn opgetreden. Met deze statistiek worden problemen aangeduid die herhaaldelijk optreden.

Een probleem oplossen

De ANR's die bijdragen aan je ANR-percentagestatistieken worden gerapporteerd op de pagina Crashes en ANR's. Je kunt op deze pagina filteren op door de gebruiker waargenomen ANR's.

De site Android voor ontwikkelaars biedt hulp bij het vaststellen en oplossen van ANR's.

Statistieken voor het crashpercentage bieden een overzicht van de kwaliteit van je app. Deze statistieken worden berekend door het aantal gebruikers met crashes dat je hebt, te normaliseren op basis van je app-gebruik. Ze worden gerapporteerd als een percentage van de dagelijkse gebruikers, waarbij een dagelijkse gebruiker wordt gedefinieerd als een gebruiker die de app gebruikt op één dag op één apparaat. Als een gebruiker meer dan één apparaat heeft, wordt de gebruiker meerdere keren geteld. Als bijvoorbeeld 2 gebruikers de app 2 dagen gebruiken op 1 apparaat, resulteert dit in 4 dagelijkse sessies.

Er zijn 3 statistieken voor het crashpercentage:

• Door de gebruiker waargenomen crashpercentage: Het percentage van je dagelijkse gebruikers bij wie ten minste één door de gebruiker waargenomen crash is opgetreden. Een door de gebruiker waargenomen crash is een crash die waarschijnlijk is opgemerkt door de gebruiker. Bijvoorbeeld crashes die plaatsvinden als je app een activiteit toont of wordt uitgevoerd als service op de voorgrond. Deze statistiek is altijd lager dan je algehele crashpercentage omdat het is genormaliseerd op basis van het dagelijkse gebruik, maar niet alle crashes meetelt.
  Het door de gebruiker waargenomen crashpercentage is een belangrijke vitaliteitsstatistiek die de vindbaarheid van je app op Google Play beïnvloedt. Dit is belangrijk omdat de crashes die worden geteld altijd optreden als de gebruiker de app gebruikt, wat de meeste problemen veroorzaakt. Daarom moet je ervoor zorgen dat je app de drempelwaarde voor ongewenst gedrag voor deze statistiek niet overschrijdt.

• Crashpercentage: Het percentage dagelijkse gebruikers bij wie ten minste 1 crash is opgetreden. Deze statistiek omvat crashes die niet zijn geclassificeerd als door de gebruiker waargenomen, maar we kunnen niet garanderen dat deze crashes geen invloed hebben op gebruikers.

• Multi-crashpercentage: Het percentage van je dagelijkse gebruikers bij wie ten minste 2 crashes zijn opgetreden. Met deze statistiek worden problemen aangeduid die herhaaldelijk optreden.

Een probleem oplossen

De site Android voor ontwikkelaars biedt hulp bij het vaststellen en oplossen van crashes.

Op de pagina Opstarttijd zie je aan de hand van de systeemstatus cold, warm of hot of je app langzaam opstart. De opstarttijd meet de tijd tussen het moment dat een gebruiker je app start en het moment waarop de eerste frames op het scherm worden getoond. Dit wordt ook wel tijd tot eerste weergave genoemd.

Na deze tijd is je app misschien nog niet gebruiksklaar, bijvoorbeeld als je app aanvullende laadschermen heeft.

Informatie over de gegevensverzameling

• Opstarttijden worden alleen geregistreerd als een gebruiker een activiteit veroorzaakt.
  • Voorbeeld: Voor toetsenbord-apps is de opstarttijd gelijk aan de opstarttijd van de bijbehorende app.
• Als een app meerdere keren op dezelfde dag vanuit dezelfde systeemstatus wordt gestart, wordt de maximale opstarttijd van die dag geregistreerd.
• Opstarttijden worden bijgehouden tot het moment dat het eerste frame van de app volledig is geladen, zelfs als dit geen scherm is waar gebruikers interactie mee hebben.
  • Voorbeeld: Als een app begint met een startscherm, is de opstarttijd gelijk aan de tijd die nodig is om het startscherm weer te geven.

Vitaliteitsdetails

• Beïnvloede sessies: Percentage sessies waarin gebruikers een langere opstarttijd ondervonden voor elke desbetreffende systeemstatus:
  • Langzame cold start: 5 seconden of langer
  • Langzame warm start: 2 seconden of langer
  • Langzame hot start: 1 seconde of langer
• Aantal sessies: Geschat aantal geregistreerde sessies.
• 90e/99e percentiel: 10%/1% van alle dagelijkse sessies van gebruikers waarin je app langzaam is opgestart.

Een probleem oplossen

Als het veel voorkomt dat je app langzaam opstart, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

Waarom dit belangrijk is

Met Langzame sessies krijg je inzicht in de prestaties voor framesnelheid van je game, en dus hoe soepel en vloeiend je game voelt voor gebruikers.

Inzicht in de gegevens van je app

De pagina Langzame sessies bevat informatie over het percentage dagelijkse sessies waarin gebruikers meer dan 25% van de frames met een langzamere snelheid dan 30 frames per seconde of 20 frames per seconde kregen, afhankelijk van de benchmark die je selecteert. Je kunt ook de verdeling van sessies per framesnelheid voor je game bekijken. (Framesnelheid op sessieniveau wordt gemeten bij het 75e percentiel, wat betekent dat 75% van de frames ten minste deze framesnelheid behaalt.)

De meeste games op Google Play moeten streven naar 30 frames per seconde of hoger. Dit biedt gebruikers een redelijke functionaliteit, ongeacht het type game dat ze spelen (hoewel sommige gebruikers liever minstens 60 frames per seconde hebben, vooral op apparaten met geavanceerdere opties). Houd de statistiek Langzame sessie (30 frames per seconde) in de gaten om ervoor te zorgen dat je deze limiet haalt. Deze statistiek heeft alleen betrekking op sessies waarbij 30 frames per seconde ontbreken bij meer dan 25% van de frames. Er is dus een bepaalde tolerantie voor de variabiliteit van de framesnelheid.

Hoewel 30 frames per seconde een redelijke ervaring biedt, zijn er momenten of soorten games waarbij een lagere framesnelheid logisch is. Je kunt ook games spelen op telefoons die 30 frames per seconde niet ondersteunen. In deze scenario's moet ten minste 75% van de frames in een sessie toch 20 frames per seconde of hoger halen. Houd de statistiek Langzame sessie (20 frames per seconde) in de gaten om te zorgen dat je aan deze limiet voldoet.

App-vitaliteit rapporteert langzame sessies (30 frames per seconde) en langzame sessies (20 frames per seconde) voor elk apparaat afzonderlijk en voor alle apparaten en sessies. Gebruik de algemene statistiek om inzicht te krijgen in je algehele gebruikerservaring, maar let ook op de prestaties per apparaat. In de loop van de tijd houdt Play gebruikers weg bij games die geen 20 frames per seconde op hun telefoon kunnen halen.

App-vitaliteit begint de framesnelheid pas te controleren nadat je game 1 minuut actief is geweest.

Informatie over de gegevensverzameling

De statistiek Langzame sessies wordt berekend op basis van verzamelde gegevens uit SurfaceFlinger. Concreet wordt de framesnelheid van een sessie geschat op basis van de tijd tussen de getekende frames op platforms die eigendom zijn van de app. Dit is inclusief frames die zijn weergegeven door OpenGL, Vulkan en Android UI-toolkit. Deze statistiek is momenteel alleen beschikbaar voor games.

Gegevens over de framesnelheid voor Langzame sessies worden verzameld voor apparaten met Android 9 en hoger.

Dashboardweergave

• Representatieve framesnelheid: De prestaties voor framesnelheid van je game op apparaten met Android 9 of hoger, berekend op het 75e percentiel. Dit betekent dat 75% van de sessies 75% van de tijd deze of een hogere framesnelheid had.
• Percentage Langzame sessies na verloop van tijd: Een tijdreeks waarin je ziet hoeveel sessies zijn geïdentificeerd als langzame sessies.
• Distributie van framesnelheid: Histogram met het 75e percentiel framesnelheid over sessies. Dit betekent dat 75% van de frames in een sessie sneller was dan de framesnelheid die voor de sessie werd gebruikt.

Een probleem oplossen

Als je app een groot aantal langzame sessies heeft, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

Inzicht in de gegevens van je app

De pagina Overmatig veel langzame frames bevat informatie over het percentage dagelijkse sessies waarin gebruikers meer dan 50% van de frames niet binnen de tekendeadline van het apparaat hebben gekregen. Voor gebruikersinteracties met je app moeten er 60 frames per seconde worden weergegeven, zonder verloren of vertraagde frames.

Informatie over de gegevensverzameling

Google verzamelt de rendertijd van elk frame dat je app heeft weergegeven via het UI Toolkit-framework. Frames die rechtstreeks via OpenGL of Vulkan worden weergegeven, blijven buiten beschouwing.

Dashboardweergave

Als je een rij selecteert, worden de gegevens uitgesplitst in percentielen.

• Beïnvloede sessies: Percentage dagelijkse sessies waarin gebruikers meer dan 50% van de frames hebben gekregen met een rendertijd van meer dan 16 ms. Een dagelijkse sessie verwijst naar een dag waarop de app is gebruikt. Als bijvoorbeeld 2 gebruikers de app 2 dagen gebruiken, resulteert dit in 4 dagelijkse sessies.
• Aantal sessies: Geschat aantal geregistreerde sessies.
• 90e/99e percentiel: 90%/99% van het totale aantal frames had een rendertijd die korter was dan de onderstaande waarde. Deze cijfers zijn gebaseerd op alle verzamelde frames.

Als je op een vermelding in de tabel klikt, zie je het diagram Distributie van UI-rendertijd. Als je het diagram controleert, kijk je of het merendeel van de frames van je app in 16 ms of sneller is weergegeven.

De gegevens onder het diagram geven de weergaveprestaties van de app aan. Aan de hand van deze gegevens kun je mogelijk de achterliggende oorzaak van eventuele problemen met de rendertijd achterhalen. Als het percentage bijvoorbeeld hoog is voor Lange invoerwachttijd, check je de code van je app die gebruikersinvoer verwerkt. Ga naar het artikel over het testen van de UI-prestaties voor meer informatie over deze statistieken.

• Gemiste Vsyncs: Voor alle frames waarvoor het weergeven langer dan 16 ms duurde: het aantal gemiste Vsync-gebeurtenissen, gedeeld door het aantal frames.
• Lange invoerwachttijd: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal invoergebeurtenissen dat meer dan 24 ms in beslag neemt, gedeeld door het aantal frames.
• Langzame UI-thread: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal keer dat de UI-thread niet binnen 8 ms wordt voltooid, gedeeld door het aantal frames.
• Langzame tekenopdrachten: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal keer dat tekenopdrachten niet binnen 12 ms naar de GPU worden gestuurd, gedeeld door het aantal frames.
• Langzame bitmapuploads: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal keer dat de bitmap niet binnen 3,2 ms naar de GPU wordt geüpload, gedeeld door het aantal frames.

Een probleem oplossen

Als je app een groot aantal frames bevat met een rendertijd van meer dan 16 ms, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

Inzicht in de gegevens van je app

De pagina Overmatig veel langzame frames bevat informatie over het percentage dagelijkse sessies waarin gebruikers meer dan 50% van de frames niet binnen de tekendeadline van het apparaat hebben gekregen. Voor gebruikersinteracties met je app moeten er 60 frames per seconde worden weergegeven, zonder verloren of vertraagde frames.

Informatie over de gegevensverzameling

Google verzamelt de rendertijd van elk frame dat je app heeft weergegeven via het UI Toolkit-framework. Frames die rechtstreeks via OpenGL of Vulkan worden weergegeven, blijven buiten beschouwing.

Dashboardweergave

Als je een rij selecteert, worden de gegevens uitgesplitst in percentielen.

• Beïnvloede sessies: Percentage dagelijkse sessies waarin gebruikers meer dan 50% van de frames hebben gekregen met een rendertijd van meer dan 16 ms. Een dagelijkse sessie verwijst naar een dag waarop de app is gebruikt. Als bijvoorbeeld 2 gebruikers de app 2 dagen gebruiken, resulteert dit in 4 dagelijkse sessies.
• Aantal sessies: Geschat aantal geregistreerde sessies.
• 90e/99e percentiel: 90%/99% van het totale aantal frames had een rendertijd die korter was dan de onderstaande waarde. Deze cijfers zijn gebaseerd op alle verzamelde frames.

Als je op een vermelding in de tabel klikt, zie je het diagram Distributie van UI-rendertijd. Als je het diagram controleert, kijk je of het merendeel van de frames van je app in 16 ms of sneller is weergegeven.

De gegevens onder het diagram geven de weergaveprestaties van de app aan. Aan de hand van deze gegevens kun je mogelijk de achterliggende oorzaak van eventuele problemen met de rendertijd achterhalen. Als het percentage bijvoorbeeld hoog is voor Lange invoerwachttijd, check je de code van je app die gebruikersinvoer verwerkt. Ga naar het artikel over het testen van de UI-prestaties voor meer informatie over deze statistieken.

• Gemiste Vsyncs: Voor alle frames waarvoor het weergeven langer dan 16 ms duurde: het aantal gemiste Vsync-gebeurtenissen, gedeeld door het aantal frames.
• Lange invoerwachttijd: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal invoergebeurtenissen dat meer dan 24 ms in beslag neemt, gedeeld door het aantal frames.
• Langzame UI-thread: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal keer dat de UI-thread niet binnen 8 ms wordt voltooid, gedeeld door het aantal frames.
• Langzame tekenopdrachten: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal keer dat tekenopdrachten niet binnen 12 ms naar de GPU worden gestuurd, gedeeld door het aantal frames.
• Langzame bitmapuploads: Voor alle frames die niet binnen 16 ms worden weergegeven: het aantal keer dat de bitmap niet binnen 3,2 ms naar de GPU wordt geüpload, gedeeld door het aantal frames.

Een probleem oplossen

Als je app een groot aantal frames bevat met een rendertijd van meer dan 16 ms, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

Op de pagina's Vastgelopen gedeeltelijke wake locks en Vastgelopen gedeeltelijke wake locks (achtergrond) worden gedeeltelijke wake locks weergegeven die door je app zijn verzameld via de klasse PowerManager. Een gedeeltelijke wake lock zorgt ervoor dat de CPU actief is, maar dat de achtergrondverlichting van het scherm en toetsenbord mogen worden uitgezet.

Informatie over de gegevensverzameling

• Uit privacyoverwegingen worden de identificatietags van gedeeltelijke wake locks geanonimiseerd.
• Gegevens over gedeeltelijke wake locks worden verzameld als het apparaat niet wordt opgeladen en het scherm uitstaat.
• Gegevens over vastgelopen gedeeltelijke wake locks (achtergrond) worden alleen verzameld als de app op de achtergrond wordt uitgevoerd.
• Google berekent de maximale wake lock-duur per batterijsessie om aan te geven tijdens hoeveel sessies zich een lange wake lock heeft voorgedaan. Als een gebruiker bijvoorbeeld wake locks van 2 uur activeert, gebruikt Google een maximale wake lock-waarde van 1 uur.
• Voor apps waarvoor sharedUserId wordt ingesteld in het manifestbestand: Er worden alleen gegevens getoond als er maximaal 1 app met dezelfde sharedUserId is geïnstalleerd.

Vitaliteitsdetails

• Beïnvloede sessies: Percentage batterijsessies waarin gebruikers ten minste 1 wake lock van meer dan 1 uur hebben ondervonden.
• Aantal sessies: Geschat aantal geregistreerde sessies.
• 90e/99e percentiel: 10%/1% van alle dagelijkse sessies waarin gebruikers een gedeeltelijke wake lock hebben ondervonden die langer duurde dan de weergegeven waarde.
• Drempelwaarde voor ongewenst gedrag: Als je app een frequentie heeft die gelijk is aan of hoger is dan de weergegeven drempelwaarde, staat deze in de onderste 25% van de top 1000 apps op Google Play (op basis van het aantal installaties).

Een probleem oplossen

Als je app veel vastgelopen gedeeltelijke wake locks bevat, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

De pagina Overmatig veel geactiveerd bevat informatie over Alarm Manager-activeringen voor je app. Er worden activeringsgegevens getoond voor de klassen ELAPSED_REALTIME_WAKEUP of RTC_WAKEUP.

Informatie over de gegevensverzameling

• Uit privacyoverwegingen worden de identificatietags voor activeringen geanonimiseerd.
• Activeringen worden verzameld wanneer het apparaat niet wordt opgeladen.
• Voor een genormaliseerde statistiek wordt het aantal activeringen vergeleken met de tijd die het apparaat gebruikmaakt van de batterij. Google berekent het aantal activeringen per gebruiker per uur om aan te geven hoeveel gebruikers veel activeringen ondervinden.
• Voor apps waarvoor sharedUserId wordt ingesteld in het manifestbestand: Er worden alleen gegevens getoond als er maximaal 1 app met dezelfde sharedUserId is geïnstalleerd.

Vitaliteitsdetails

• Beïnvloede sessies: Percentage batterijsessies waarin gebruikers meer dan 10 activeringen per uur hebben ondervonden. Een batterijsessie is de aggregatie van alle batterijrapporten die binnen een bepaalde periode van 24 uur zijn ontvangen. In Android 10 verwijst een batterijrapport naar het interval tussen 2 keer opladen van de batterij: van lager dan 20% tot hoger dan 80% of van elke waarde tot 100%. In Android 11 en hoger verwijst een batterijrapport naar een vaste periode van 24 uur. Google verzamelt de gegevens alleen wanneer het apparaat niet wordt opgeladen.
• Aantal sessies: Geschat aantal geregistreerde sessies.
• 90e/99e percentiel: 10%/1% van alle dagelijkse sessies waarin gebruikers meer activeringen per uur hebben ondervonden dan de weergegeven waarde.
• Drempelwaarde voor ongewenst gedrag: Als je app een frequentie heeft die gelijk is aan of hoger is dan de weergegeven drempelwaarde, staat deze in de onderste 25% van de top 1000 apps op Google Play (op basis van het aantal installaties).

Een probleem oplossen

Als je app regelmatig activeringen genereert, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

De pagina Overmatig veel wifi-scans (achtergrond) bevat informatie over wifi-scans die tot een hoog batterijgebruik leiden.

Informatie over de gegevensverzameling

Gegevens over wifi-scannen worden verzameld wanneer het apparaat niet wordt opgeladen en de app op de achtergrond is geopend.

Vitaliteitsdetails

• Beïnvloede sessies: Percentage batterijsessies waarin gebruikers meer dan 4 wifi-scans per uur hebben ondervonden.
• Aantal sessies: Geschat aantal geregistreerde sessies.
• 90e/99e percentiel: 10%/1% van alle dagelijkse sessies waarin gebruikers meer wifi-scans per uur hebben ondervonden dan de weergegeven waarde.

Een probleem oplossen

Als je app veel wifi-scans op de achtergrond uitvoert, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

De pagina Overmatig veel netwerkgebruik geeft aan wanneer een grote hoeveelheid netwerkgegevens wordt geassocieerd met een achtergrondservice. Als mobiel netwerkverkeer op de achtergrond wordt uitgevoerd, kunnen je gebruikers de netwerkoverdracht niet makkelijk stoppen.

Informatie over de gegevensverzameling

Gegevens over mobiel netwerkgebruik worden verzameld wanneer het apparaat niet wordt opgeladen en de app op de achtergrond wordt uitgevoerd.

Vitaliteitsdetails

• Beïnvloede sessies: Percentage batterijsessies waarin gebruikers op de achtergrond meer dan 50 MB aan netwerkgebruik per dag hebben ondervonden.
• Aantal sessies: Geschat aantal geregistreerde sessies.
• 90e/99e percentiel: 10%/1% van alle dagelijkse sessies waarin gebruikers een groter dagelijks netwerkgebruik hebben ondervonden dan de weergegeven waarde.

Een probleem oplossen

Als je app een hoog netwerkgebruik heeft op de achtergrond, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

Op de pagina Rechtenweigeringen staat informatie over het percentage dagelijkse rechtensessies waarin gebruikers rechten hebben geweigerd. Een dagelijkse rechtensessie verwijst naar een dag waarop je app ten minste één rechtenverzoek bij de gebruiker indient.

Informatie over de gegevensverzameling

Wanneer gebruikers reageren op rechtenverzoeken in je app, worden gegevens over geweigerde rechten verzameld.

Vitaliteitsdetails

• Weigeringen: Percentage dagelijkse rechtensessies waarin gebruikers rechten hebben geweigerd.
• Niet meer vragen: Percentage dagelijkse rechtensessies waarin gebruikers rechten hebben geweigerd door te kiezen voor Niet meer vragen.
• Totaal aantal sessies: Het geschatte aantal geregistreerde sessies.

Een probleem oplossen

Als het veel voorkomt dat rechten worden geweigerd voor je app, ga je naar de site Android voor ontwikkelaars voor aanbevolen oplossingen.

Google Play heeft drempelwaarden voor ongewenst gedrag rond het door de gebruiker waargenomen ANR-percentage gedefinieerd:

• Ongewenst gedrag op totaalniveau: Ten minste 0,47% van de dagelijks actieve gebruikers op alle apparaatmodellen ervaart een door de gebruiker waargenomen ANR.

• Ongewenst gedrag op apparaatniveau: Ten minste 8% van de dagelijks actieve gebruikers op een specifiek apparaatmodel ervaart een door de gebruiker waargenomen ANR.

Als je je ANR-percentage wilt verbeteren, verhelp je de onderliggende ANR-clusters die worden gerapporteerd op de pagina Crashes en ANR's. Hoe hoger het aantal getroffen gebruikers, hoe meer die cluster bijdraagt aan je ANR-percentage.

Als specifieke aspecten van de apparaathardware of -software kunnen bijdragen aan je ANR-percentage, krijg je een melding van App-vitaliteit. Je kunt ook zelf kijken welke aspecten hierbij betrokken zijn op de pagina Overzicht van bereik en apparaten (Release > Bereik en apparaten > Overzicht).

Google Play heeft drempelwaarden voor ongewenst gedrag rond het door de gebruiker waargenomen crashpercentage gedefinieerd:

• Ongewenst gedrag op totaalniveau: Ten minste 1,09% van de dagelijkse gebruikers op alle apparaatmodellen ervaart een door de gebruiker waargenomen crash.

• Ongewenst gedrag op apparaatniveau: Ten minste 8% van de dagelijkse gebruikers op een specifiek apparaatmodel ervaart een door de gebruiker waargenomen crash.

Als je je crashpercentage wilt verbeteren, verhelp je de onderliggende crashclusters die worden gerapporteerd op de pagina Crashes en ANR's . Hoe hoger het aantal getroffen gebruikers, hoe meer die cluster bijdraagt aan je crashpercentage.

Als specifieke aspecten van de apparaathardware of -software kunnen bijdragen aan je crashpercentage, krijg je een melding van App-vitaliteit. Je kunt ook zelf kijken welke aspecten hierbij betrokken zijn op de pagina Overzicht van bereik en apparaten (Release > Bereik en apparaten > Overzicht).