De technische kwaliteit van je app checken met App-vitaliteit

Nieuwe inzichten in problemen met app-kwaliteit en aanbevelingen

Vanaf september 2024 vind je nieuwe inzichten en aanbevelingen op de pagina's Overzicht van App-vitaliteit en Crashes en ANR's in de Play Console. Zo kun je prioriteit geven aan kwaliteitsproblemen.

Op dit moment worden problemen met app-compatibiliteit, ongewenst gedrag en enkele UX-aanbevelingen getoond. In het komende jaar breiden we onze opsporing en aanbevelingen uit naar meer typen kwaliteitsproblemen.

Gebruik App-vitaliteit om inzicht te krijgen in onder andere de stabiliteit, de prestaties en het batterijgebruik van je app en om deze aspecten te verbeteren.

Kiezen hoe je toegang wilt krijgen tot de gegevens van je app

Je kunt App-vitaliteit op 2 manieren gebruiken: via de Play Console en via de Play Developer Reporting API.

De API biedt programmatische toegang tot App-vitaliteit voor ontwikkelaars die gegevens van App-vitaliteit willen integreren met andere datasets of deze in hun workflows willen integreren. Ga naar de pagina Google Play Developer Reporting API voor meer informatie over het gebruik van een API voor toegang tot App-vitaliteit.

Zo kun je gegevens over app-vitaliteit voor je app vinden en checken in de Play Console:

  1. Open de Play Console en ga naar de pagina App-vitaliteit: overzicht (Kwaliteit > App-vitaliteit > Overzicht).
  2. Kies met de periodekiezer rechtsboven voor welke periode je gegevens wilt bekijken.

Belangrijk: Als er geen gegevens beschikbaar zijn, heeft je app onvoldoende gegevenspunten binnen de gespecificeerde filters om eventuele problemen te identificeren.

Belangrijke vitaliteitsstatistieken van je app checken

Bovenaan de pagina App-vitaliteit: overzicht kun je belangrijke vitaliteitsstatistieken van je app bekijken. Dit zijn de belangrijkste technische statistieken die van invloed zijn op de vindbaarheid van je app op Google Play. Belangrijke vitaliteitsstatistieken zijn:

Google Play definieert drempelwaarden voor ongewenst gedrag op basis van deze statistieken. Als je app deze drempelwaarden overschrijdt, is deze waarschijnlijk minder vindbaar op Google Play. In sommige gevallen krijg je een waarschuwing in de winkelvermelding van je app om aan te geven wat gebruikers kunnen verwachten.

In het gedeelte Kritieke problemen vind je snel verbeterpunten voor je app. Er zijn 2 typen kritieke problemen:

  • Ongewenst gedrag: Statistieken die de drempelwaarden voor ongewenst gedrag overschrijden.
  • Afwijkingen: Aanzienlijke wijzigingen in gegevens (bijvoorbeeld een sterke toename in het percentage door de gebruiker waargenomen ANRs).

Als je e-mailmeldingen wilt krijgen, ga je naar Instellen > Meldingen of klik je op Meldingen beheren in de hoek van het gedeelte Belangrijke vitaliteitsstatistieken (Kwaliteit > App-vitaliteit > Overzicht). Houd er rekening mee dat meldingen momenteel alleen beschikbaar zijn voor afwijkingen.

Door alle vitaliteitsstatistieken browsen

Ongeveer in het midden van de pagina App-vitaliteit: overzicht kun je gegevens over alle vitaliteitsstatistieken per kwaliteitsaspect bekijken.

In de tabel staan statistieken voor de huidige en eerdere perioden. Je kunt ook bekijken hoe je app presteert in vergelijking met andere apps op Google Play.

Gedetailleerde statistieken bekijken

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
Gegevens analyseren met dimensies

Je statistieken worden onderverdeeld in verschillende dimensies, zodat je de gegevens makkelijk kunt ordenen, segmenteren en analyseren. Alle statistieken hebben de volgende uitsplitsingen:

  • Artefact: De versie van je app waarin het probleem zich voordeed.
  • Android-versie (SDK): Versie van Android OS die vanaf het apparaat van de gebruiker wordt gerapporteerd.
  • Vormfactor: Het type apparaat waarop de app is uitgevoerd (bijvoorbeeld telefoon, tablet, tv, wearable).
  • Apparaatmodel: Een algemene beschrijving van het apparaat, die bestaat uit een unieke combinatie van merk en apparaat-ID, bijvoorbeeld Google oriole. Eén apparaatmodel kan varianten met verschillende Android-versies, RAM, opslag of system-on-chip (SoC) hebben.
  • Land/regio: De locatie die is gerapporteerd door het apparaat van de gebruiker op het moment dat het probleem zich voordeed.

Tip: Voor uitsplitsingen in specifieke aspecten van de apparaathardware of -software (bijvoorbeeld apparaatmodel of Android-versie), klik je naast het item in de tabel op het symbool ().

Sommige statistieken hebben aanvullende uitsplitsingen:

  • Wake lock-naam: Tags die programmatisch zijn ingesteld bij gebruik van de PowerManager API in je app.
  • Activeringsnaam: Tags die programmatisch zijn ingesteld bij gebruik van de AlarmManager API in je app.
  • Naam ANR-activiteit: Volledig gekwalificeerde naam van de activiteitsklasse waarin de ANR plaatsvond (indien beschikbaar).
  • ANR-type: Wanneer de ANR is opgetreden, bijvoorbeeld tijdens het uitvoeren van een service (indien beschikbaar).

Als je meer informatie wilt bekijken (bijvoorbeeld de crash- of ANR-clusters die aan de uitsplitsing zijn gekoppeld), selecteer je naast het item Details bekijken ().

Tip: Met de schakelaar bovenaan het scherm kun je schakelen tussen statistieken binnen een categorie en de pagina filteren.

Gegevenstypen en statistieken

Gegevens van App-vitaliteit zijn beschikbaar voor de afgelopen 90 dagen in de Play Console en voor de afgelopen 3 jaar in de Play Developer Reporting API.

Gegevens worden vanuit een subset van Android-apparaten en -besturingssysteemversies verzameld van gebruikers die toestaan dat gebruiks- en diagnostische gegevens automatisch worden gedeeld. Ga naar het Helpcentrum van Google Accounts voor meer informatie over hoe Android-gebruikers het delen van gegevens kunnen toestaan.

App-vitaliteit wordt dagelijks geüpdatet. Soms komen gegevens voor apparaten met Android 10 en hoger eerder binnen dan gegevens op apparaten met een lagere versie. Als dit gebeurt, zie je gegevens voor Android 10 en hoger die beschikbaar zijn voor dagen waar alleen deze beschikbaar zijn.

Let op: In de statistieken voor App-vitaliteit zijn geen technische problemen opgenomen die optreden op niet-gecertificeerde apparaatmodellen of in versies van je app die niet zijn geïnstalleerd via Google Play.

Alles samenvouwen Alles uitvouwen

Stabiliteit

Statistieken voor het ANR-percentage

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:

  • Percentage door de gebruiker waargenomen ANRs: 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 percentage door de gebruiker waargenomen ANRs 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 één 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

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 één 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.

Opstart- en laadtijden

Opstarttijd (tijd tot eerste weergave)

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 warme start: 2 seconden of langer
    • Langzame hete 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.

Weergave

Alle weergaven

Percentage langzame sessies (30 frames per seconde of 20 frames per seconde) [alleen games]

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 het percentage langzame sessies (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 het percentage langzame sessies (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.

Rendering van Android UI-toolkit

Overmatig veel langzame frames [alleen apps]

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 getoonde 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 misschien de hoofdoorzaak 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 die niet binnen 16 ms worden gerenderd: het aantal gemiste Vsync-gebeurtenissen, gedeeld door het aantal frames.
  • Lange invoerwachttijd: Voor alle frames die niet binnen 16 ms worden gerenderd: 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 gerenderd: het aantal keer dat de UI-thread niet binnen 8 ms wordt afgerond, gedeeld door het aantal frames.
  • Langzame tekenopdrachten: Voor alle frames die niet binnen 16 ms worden gerenderd: 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 gerenderd: 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.

Overmatig veel vastgelopen frames [alleen apps]

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 getoonde 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 misschien de hoofdoorzaak 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 die niet binnen 16 ms worden gerenderd: het aantal gemiste Vsync-gebeurtenissen, gedeeld door het aantal frames.
  • Lange invoerwachttijd: Voor alle frames die niet binnen 16 ms worden gerenderd: 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 gerenderd: het aantal keer dat de UI-thread niet binnen 8 ms wordt afgerond, gedeeld door het aantal frames.
  • Langzame tekenopdrachten: Voor alle frames die niet binnen 16 ms worden gerenderd: 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 gerenderd: 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.

Batterijgebruik

Vastgelopen wake locks en vastgelopen gedeeltelijke wake locks (achtergrond)

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 één wake lock van meer dan één 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 getoonde waarde.
  • Drempelwaarde voor ongewenst gedrag: Als je app een frequentie heeft die gelijk is aan of hoger is dan de getoonde 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.

Overmatig veel geactiveerd

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 getoonde waarde.
  • Drempelwaarde voor ongewenst gedrag: Als je app een frequentie heeft die gelijk is aan of hoger is dan de getoonde 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.

Overmatig veel wifi-scans (achtergrond)

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 op de achtergrond hebben ondervonden dan de getoonde 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.

Overmatig veel netwerkgebruik (achtergrond)

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 getoonde 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.

Rechten

Rechtenweigeringen

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 sessies waarin gebruikers machtigingen 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.

Drempelwaarden voor ongewenst gedrag met betrekking tot belangrijke vitaliteitsstatistieken

Google Play heeft drempelwaarden voor ongewenst gedrag met betrekking tot de belangrijke vitaliteitsstatistieken van je app gedefinieerd.

Als je app een drempelwaarde voor ongewenst gedrag overschrijdt, is je app waarschijnlijk minder vindbaar op Google Play. Als je app ongewenst gedrag vertoont op specifieke apparaatmodellen, leidt Google Play gebruikers op die apparaten weg van deze titels en naar andere die geschikter voor ze zijn. In sommige gevallen kan er een waarschuwing worden weergegeven in de winkelvermelding van je app om aan te geven wat gebruikers kunnen verwachten en de optie te bieden om alternatieven met een hogere technische kwaliteit te zoeken.

Google Play houdt bij de evaluatie van de kwaliteit van je app rekening met de gegevens van de afgelopen 28 dagen, maar kan in het geval van een piek eerder een beslissing nemen.

Alles samenvouwen Alles uitvouwen

Stabiliteit

Drempelwaarden voor door de gebruiker waargenomen ANR-percentage

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).

Drempelwaarden voor door de gebruiker waargenomen crashpercentage

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).

Gerelateerde content

Lees onze best practices om de werking en stabiliteit van je app te verbeteren aan de hand van App-vitaliteit.

Was dit nuttig?

Hoe kunnen we dit verbeteren?

Meer hulp nodig?

Probeer de volgende stappen:

Zoeken
Zoekopdracht wissen
Zoekfunctie sluiten
Hoofdmenu
1699138183699871345
true
Zoeken in het Helpcentrum
true
true
true
true
true
92637
false
false