Ny statistikk om problemer med appkvalitet og anbefalinger
Foreløpig viser vi problemer med appkompatibilitet, dårlig funksjonalitet og enkelte anbefalinger for brukeropplevelsen. I løpet av det neste året kommer vi til å jobbe videre med finne og vise flere kvalitetsproblemer og gi flere anbefalinger.
Bruk Android-nøkkelstatistikk for å få hjelp til å forstå – og forbedre – appens stabilitet, ytelse, batteribruk med mer.
Velg hvordan du vil ha tilgang til appdataene
Du kan bruke Android-nøkkelstatistikk på to måter: via Play-konsollen og via Play Developer Reporting API.
API-et gir programmatisk tilgang til Android-nøkkelstatistikk for utviklere som vil integrere Android-nøkkelstatistikk med andre datasett eller bygge den inn i arbeidsflytene sine. For å finne ut mer om hvordan du bruker API-er til å få tilgang til Android-nøkkelstatistikk, gå til Google Play Developer Reporting API-siden.
Sånn finner og gjennomgår du appens data fra Android-nøkkelstatistikk i Play-konsollen:
- Åpne Play-konsollen, og gå til siden med oversikt over Android-nøkkelstatistikk (Kvalitet > Android-nøkkelstatistikk > Oversikt).
- Velg dataområdet du vil se, ved å bruke datoperiodevelgeren øverst til høyre.
Viktig: Hvis ingen data er tilgjengelige, har ikke appen nok datapunkter i de angitte filtrene til å identifisere eventuelle problemer.
Overvåk appens kjernestatistikk
Øverst på siden Oversikt over Android-nøkkelstatistikk ser du data om appens kjernestatistikk. Dette er de viktigste tekniske verdiene som påvirker synligheten til appen din på Google Play. Kjernestatistikken omfatter:
Google Play definerer terskler for dårlig funksjonalitet for disse verdiene. Hvis appen din overskrider disse tersklene, blir den sannsynligvis mindre synlig i Google Play. I noen tilfeller kan det bli vist en advarsel i butikkoppføringen for appen for å sikre at brukerne får de riktige forventningene.
I «Kritiske problemer»-delen kan du raskt se områder appen din kan forbedres på. Det finnes to typer kritiske problemer:
- Dårlig funksjonalitet: Verdier som overskrider tersklene for dårlig funksjonalitet
- Avvik: Betydelige endringer i data (f.eks. en betydelig økning i brukeroppfattet ANR-frekvens)
For å bli varslet på e-post, gå til Konfigurering > Varsler, eller klikk på Administrer varsler i hjørnet av «Kjernestatistikk»-delen (Kvalitet > Android-nøkkelstatistikk > Oversikt). Vær oppmerksom på at varsler foreløpig bare er tilgjengelige for avvik.
Bla gjennom all nøkkelstatistikkPå midten av siden med oversikt over Android-nøkkelstatistikk kan du se data om all nøkkelstatistikk etter kvalitet.
I tabellen kan du se verdier for nåværende og tidligere tidsperioder. Du kan også se resultatene for appen din sammenlignet med andre apper på Google Play.
For å få mer informasjon om en verdi, velg Se detaljer () ved siden av den. På neste skjermbilde kan du se gjennom
- terskler for dårlig funksjonalitet
- kategorireferansemålinger
- detaljerte sammenligninger av referansemålinger
- Velg Endre gruppen med lignende apper nær toppen av siden, på kortet for sammenligning med lignende apper, for å endre en tilpasset gruppe med lignende apper. Når du har opprettet en tilpasset gruppe, kan du se resultatene for appen din sammenlignet med andre apper på Google Play som du velger.
- Verditrender over tid
For at det skal bli enklere for deg å organisere, segmentere og analysere dataene dine, blir verdiene inndelt etter flere forskjellige dimensjoner. Alle verdier har følgende oversikter:
- Artefakt: versjonen av appen der problemet oppsto
- Android-versjon (SDK): Android OS-versjonen som er rapportert fra brukerens enhet
- Formfaktor: enhetstypen som brukes til å kjøre appen (f.eks. telefon, nettbrett, TV, hapå-teknologi)
- Enhetsmodell: en overordnet beskrivelse av enheten som består av et unikt merke og en enhetsidentifikator, for eksempel «Google oriole» – én enkelt enhetsmodell kan ha varianter med ulike Android-versjoner, RAM, lagring eller SoC (system på integrert krets)
- Land/region: posisjonen som rapporteres av brukerens enhet på tidspunktet for problemet
Tips: Hvis du vil se en oversikt ordnet etter bestemte aspekter ved maskinvaren eller programvaren til enheten (for eksempel enhetsmodell eller Android-versjon), kan du klikke på symbolet () ved siden av elementet i tabellen.
Noen verdier har flere oversikter:
- Navn på oppvekkingslås: etiketter som er angitt programmatisk ved bruk av PowerManager API i appen din
- Vekkingsnavn: etiketter som ble angitt programmatisk ved bruk av AlarmManager API i appen din
- ANR-aktivitetsnavn: det fullstendige navnet på aktivitetsklassen der ANR-feilen oppsto (om tilgjengelig)
- ANR-type: når ANR-feilen oppsto (f.eks. under kjøring av en tjeneste) (om tilgjengelig)
Du kan se mer informasjon når dette er tilgjengelig (for eksempel krasj- eller ANR-gruppene som er tilknyttet den aktuelle oversikten), ved å velge Se detaljer () ved siden av elementet.
Tips: Du kan bytte mellom verdier i en kategori ved å bruke bryteren øverst på skjermen og filtrere siden.
Datatyper og -verdier
Android-nøkkelstatistikk er tilgjengelig for de siste 90 dagene i Play-konsollen og i tre år i Play Developer Reporting API.
Data samles inn fra brukere som har valgt å dele bruks- og diagnostikkdata automatisk fra et utvalg av Android-enheter og OS-versjoner. Mer informasjon om hvordan Android-brukere velger å dele data, er tilgjengelig i brukerstøtten for Google-kontoer.
Android-nøkkelstatistikken oppdateres daglig. Noen ganger kan data for enheter med Android 10 eller nyere komme tidligere enn data for enheter med Android-versjoner eldre enn Android 10. Hvis dette skjer, ser du Android 10+-data for de dagene der bare disse dataene er tilgjengelige.
Merk: Verdier i Android-nøkkelstatistikken omfatter ikke tekniske problemer som oppstår på usertifiserte enhetsmodeller eller i versjoner av appen din som ikke er installert via Google Play.
Stabilitet
Verdier for ANR-frekvensMed verdier for ANR-frekvens får du en oversikt over kvaliteten på appen din. Disse verdiene beregnes ved å ta antall brukere du har med ANR-feil, og normalisere dem basert på appbruken. De rapporteres som en prosentandel av daglige aktive brukere. En daglig aktiv bruker defineres som en bruker som bruker appen i løpet av én dag på én enkelt enhet. Hvis en bruker bruker appen din på mer enn én enhet i løpet av én dag, bidrar hver enhet til antallet aktive brukere for den aktuelle dagen. Hvis flere brukere bruker den samme enheten på samme dag, telles dette som én aktiv bruker.
Det finnes tre verdier for ANR-frekvens:
- Brukeroppfattet ANR-frekvens: prosentandelen av de daglige aktive brukerne som opplevde minst én brukeroppfattet ANR. En brukeroppfattet ANR er en ANR-feil som brukeren mest sannsynlig har merket. For øyeblikket telles bare ANR-feil for «sending av inndata fikk tidsavbrudd». Denne verdien er alltid lavere enn den totale ANR-frekvensen fordi den normaliseres av daglig bruk, men den teller ikke alle ANR-feil.
Brukeroppfattet ANR-frekvens er en kjernestatistikk. Det betyr at den påvirker hvor synlig appen din er på Google Play. Den er viktig fordi ANR-feilene den teller, alltid oppstår når brukeren bruker appen, noe som forårsaker mest forstyrrelse.
- ANR-frekvens: prosentandelen av daglige brukere som har opplevd minst én ANR-feil. Denne verdien omfatter ANR-feil som ikke er klassifisert som brukeroppfattet, men vi kan ikke garantere at disse ANR-feilene ikke berører brukerne.
- Multi-ANR-frekvens: prosentandelen av daglige brukere som opplevde minst to ANR-feil. Denne verdien fremhever gjentakende problemer.
Løs problemer
ANR-feilene som bidrar til verdiene for ANR-frekvens, rapporteres på Krasj og ANR-feil-siden. Du kan filtrere etter brukeroppfattede ANR-feil på denne siden.
På nettstedet for Android-utviklere finner du veiledning om hvordan du diagnostiserer og fikser ANR-feil.
Med beregningene av krasjfrekvens får du en oversikt over kvaliteten på appen din. Disse verdiene beregnes ved å ta antallet brukere du har med krasjfeil, og normalisere dem basert på appbruken. De rapporteres som en prosentandel av daglige brukere. En daglig bruker defineres som en bruker som bruker appen i løpet av én dag på én enkelt enhet. Hvis en bruker har mer enn én enhet, telles brukeren mer enn én gang. Hvis for eksempel to brukere bruker appen i to dager på én enhet hver, fører det til fire daglige økter.
Det finnes tre verdier for krasjfrekvens:
- Brukeroppfattet krasjfrekvens: prosentandelen av daglige brukere som har opplevd minst ett brukeroppfattet krasj. Et brukeroppfattet krasj er et krasj som brukeren mest sannsynlig har merket. Dette kan for eksempel være krasj som skjer når appen din viser en aktivitet eller kjører som en forgrunnstjeneste. Denne verdien er alltid lavere enn den totale krasjfrekvensen fordi den normaliseres av daglig bruk, men den teller ikke alle krasj.
Brukeroppfattet krasjfrekvens er en kjernestatistikk. Det betyr at den påvirker hvor synlig appen din er på Google Play. Den er viktig fordi krasjene den teller, alltid oppstår når brukeren samhandler med appen, noe som forårsaker mest forstyrrelse. Derfor bør du sørge for at appen din ikke overskrider terskelen for dårlig funksjonalitet for denne verdien.
-
Krasjfrekvens: prosentandelen av daglige brukere som har opplevd minst ett krasj. Denne verdien omfatter krasj som ikke er klassifisert som brukeroppfattet, men vi kan ikke garantere at disse krasjene ikke berører brukerne.
-
Multikrasjfrekvens: prosentandelen av daglige brukere som har opplevd minst to krasj. Denne verdien fremhever gjentakende problemer.
Løs problemer
På nettstedet for Android-utviklere finner du veiledning om hvordan du diagnostiserer og fikser krasj.
Oppstarts- og innlastingstider
Oppstartstid (tid til første visning)På siden Oppstartstid kan du se detaljer om når appen din starter tregt fra kald, lunken og varm systemtilstand. Oppstartstiden måler tiden det tar fra en bruker åpner appen din til de første bildene dukker opp på skjermen. Dette kalles også «tid til første visning».
Det kan hende appen ikke er klar til bruk etter dette, for eksempel hvis appen har flere innlastingsskjermer.
Informasjon om datainnsamling
- Oppstartstider registreres bare når en bruker utløser en aktivitet.
- Eksempel: For tastaturapper er oppstartstiden lik oppstartstiden for følgeappen.
- Hvis en app starter flere ganger på samme dag fra den samme systemtilstanden, registreres den høyeste oppstartstiden for den dagen.
- Oppstartstider registreres når det første skjermbildet i appen er lastet inn fullstendig, selv om det ikke er en skjerm der brukeren gjør noe aktivt.
- Eksempel: Hvis en app starter med en splash-skjerm, er oppstartstiden lik tiden som kreves for å vise splash-skjermen.
Nøkkelstatistikk
- Berørte økter: prosentandelen av økter der brukerne har opplevd en treg oppstart for hver systemtilstand:
- Treg kald oppstart: fem sekunder eller mer
- Treg lunken oppstart: to sekunder eller mer
- Treg varm oppstart: ett sekund eller mer
- Antall økter: omtrentlig antall registrerte økter.
- 90./99. persentil: 10 % / 1 % av daglige økter der brukerne har opplevd en treg oppstart av appen.
Løs problemer
Hvis appen din har et høyt antall trege oppstartstider, kan du gå til nettstedet for Android-utviklere for å få anbefalte løsninger.
Gjengivelse
All gjengivelse
Frekvens av trege økter (30 eller 20 bilder per sekund) [bare spill]Grunner til at dette er viktig
Ved å bruke trege økter kan du få en forståelse av hvor god bildefrekvensen i spillet ditt er. Bildefrekvensen påvirker hvor jevnt spillet føles for brukerne.
Forstå dataene for appen din
På Trege økter-siden ser du informasjon om prosentandelen av daglige økter der brukerne opplevde at mer enn 25 % av bildene ble vist saktere enn enten 30 eller 20 bilder per sekund, avhengig av hvilken referansemåling du velger. Du kan også se fordelingen av økter etter bildefrekvens for spillet ditt. (Bildefrekvensen på øktnivå måles i den 75. persentilen, noe som betyr at 75 % av bildene oppnår minst denne bildefrekvensen.)
De fleste spill på Google Play bør ha minst 30 bilder per sekund. Dette gir brukerne en rimelig opplevelse, uavhengig av hva slags spill de spiller (men noen brukere foretrekker minst 60 bilder per sekund – spesielt på toppmodeller). Følg med på beregningen for frekvensen av trege økter (30 bilder per sekund) for å sørge for at du oppnår denne verdien. Vær oppmerksom på at denne beregningen bare omfatter økter der mer enn 25 % av bildene ikke oppnår 30 bilder per sekund, så den har noe toleranse for variasjon i bildefrekvensen.
Selv om 30 bilder per sekund gir en rimelig opplevelse, kan det av og til være lurt å redusere bildefrekvensen under dette, eller det kan hende at brukerne vil spille spillet på telefoner som ikke støtter 30 bilder per sekund. I slike scenarioer bør minst 75 % av bildene i økten fortsatt oppnå minst 20 bilder per sekund. Følg med på beregningen for frekvensen av trege økter (20 bilder per sekund) for å sørge for at du oppnår denne verdien.
Android-nøkkelstatistikken rapporterer trege økter (30 bilder per sekund) og trege økter (20 bilder per sekund) for hver enhet samt for alle enheter og økter. Bruk den overordnede beregningen for å forstå den generelle brukeropplevelsen, men vær også oppmerksom på ytelsen per enhet. Etter hvert begynner Play å styre brukerne bort fra spill som ikke kan oppnå 20 bilder per sekund på telefonene de bruker.
Nøkkelstatistikken begynner bare å overvåke bildefrekvensen når spillet ditt har kjørt i 1 minutt.
Informasjon om datainnsamling
Beregningen av trege økter er basert på data som er samlet inn fra SurfaceFlinger. Bildefrekvensen for en økt anslås basert på tiden mellom bildene som vises på plattformer appen eier, og omfatter bilder som gjengis av OpenGL, Vulkan og Android UI-verktøysettet. Denne beregningen er foreløpig bare tilgjengelig for spill.
Data om bildefrekvens for trege økter samles inn for enheter som har Android 9 eller nyere.
Dataene i oversikten
- Representativ bildefrekvens: Bildefrekvensen for spillet ditt på enheter med Android 9 eller nyere beregnet ved den 75. persentilen. Dette betyr at 75 % av øktene hadde denne bildefrekvensen eller en raskere bildefrekvens 75 % av tiden.
- Frekvens av trege økter over tid: En tidsserie som viser prosentandelen av økter som var trege økter.
- Distribusjon av bildefrekvens: Histogram som viser den 75. persentilen for bildefrekvens for flere økter. Dette betyr at 75 % av bildene i økten var raskere enn bildefrekvensen som ble brukt i økten.
Løs problemer
Hvis appen din har mange trege økter, kan du gå til nettstedet for Android-utviklere for å se anbefalte løsninger.
Gjengivelse av Android UI-verktøysettet
For mange trege bilder [bare apper]Forstå dataene for appen din
På siden «For mange trege bilder» ser du informasjon om prosentandelen av daglige økter der brukerne opplevde at mer enn 50 % av skjermbildene ikke nådde enhetens frist for gjengivelse. Brukerinteraksjoner med appen din skal kjøre med 60 bilder per sekund uten at skjermbilder hoppes over eller forsinkes.
Informasjon om datainnsamling
Google registrerer gjengivelsestiden for hvert bilde som gjengis av appen din når UI Toolkit-rammeverket brukes. Bilder som er gjengitt direkte ved bruk av OpenGL eller Vulkan, samles ikke inn.
Dataene i oversikten
Når du velger en rad, ser du dataene inndelt i persentiler.
- Berørte økter: prosentandelen av daglige økter der brukerne opplevde at minst 50 % av bildene hadde en gjengivelsestid på mer enn 16 ms. En daglig økt er en dag når appen din blir brukt. Hvis for eksempel to brukere bruker appen i to dager, fører det til fire daglige økter.
- Antall økter: omtrentlig antall registrerte økter.
- 90./99. persentil: 90 % / 99 % av det totale antallet skjermbilder hadde en gjengivelsestid under tallet som vises. Disse tallene er basert på alle innsamlede skjermbilder.
Når du klikker på en oppføring i tabellen, ser du diagrammet «Fordeling av UI-gjengivelsestid». Når du går gjennom diagrammet, må du sørge for at gjengivelsestiden for de fleste bildene i appen er 16 ms eller mindre.
Dataene under diagrammet viser gjengivelsesytelsen til appen din og kan hjelpe deg med å finne rotårsaken til eventuelle problemer med gjengivelsestiden. Hvis for eksempel prosentandelen «Høy inngangsforsinkelse» er høy, kan det være lurt å se på appkoden som håndterer inndata fra brukerne. Gå til testing av UI-ytelsen for å få mer informasjon om disse beregningene.
- Tapte Vsync-hendelser: antall tapte Vsync-hendelser delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Høy inngangsforsinkelse: antall inndatahendelser som tar mer enn 24 ms, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Treg UI-tråd: antall ganger UI-tråden bruker mer enn 8 ms på å fullføres, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Trege gjengivelseskommandoer: antall ganger det tok mer enn 12 ms å sende gjengivelseskommandoer til GPU-en, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Trege punktgrafikkopplastinger: antall ganger det tok mer enn 3,2 ms å laste opp punktgrafikk til GPU-en, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
Løs problemer
Hvis appen din har et høyt antall bilder med gjengivelsestid på mer enn 16 ms, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.
Forstå dataene for appen din
På siden «For mange trege bilder» ser du informasjon om prosentandelen av daglige økter der brukerne opplevde at mer enn 50 % av skjermbildene ikke nådde enhetens frist for gjengivelse. Brukerinteraksjoner med appen din skal kjøre med 60 bilder per sekund uten at skjermbilder hoppes over eller forsinkes.
Informasjon om datainnsamling
Google registrerer gjengivelsestiden for hvert bilde som gjengis av appen din når UI Toolkit-rammeverket brukes. Bilder som er gjengitt direkte ved bruk av OpenGL eller Vulkan, samles ikke inn.
Dataene i oversikten
Når du velger en rad, ser du dataene inndelt i persentiler.
- Berørte økter: prosentandelen av daglige økter der brukerne opplevde at minst 50 % av bildene hadde en gjengivelsestid på mer enn 16 ms. En daglig økt er en dag når appen din blir brukt. Hvis for eksempel to brukere bruker appen i to dager, fører det til fire daglige økter.
- Antall økter: omtrentlig antall registrerte økter.
- 90./99. persentil: 90 % / 99 % av det totale antallet skjermbilder hadde en gjengivelsestid under tallet som vises. Disse tallene er basert på alle innsamlede skjermbilder.
Når du klikker på en oppføring i tabellen, ser du diagrammet «Fordeling av UI-gjengivelsestid». Når du går gjennom diagrammet, må du sørge for at gjengivelsestiden for de fleste bildene i appen er 16 ms eller mindre.
Dataene under diagrammet viser gjengivelsesytelsen til appen din og kan hjelpe deg med å finne rotårsaken til eventuelle problemer med gjengivelsestiden. Hvis for eksempel prosentandelen «Høy inngangsforsinkelse» er høy, kan det være lurt å se på appkoden som håndterer inndata fra brukerne. Gå til testing av UI-ytelsen for å få mer informasjon om disse beregningene.
- Tapte Vsync-hendelser: antall tapte Vsync-hendelser delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Høy inngangsforsinkelse: antall inndatahendelser som tar mer enn 24 ms, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Treg UI-tråd: antall ganger UI-tråden bruker mer enn 8 ms på å fullføres, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Trege gjengivelseskommandoer: antall ganger det tok mer enn 12 ms å sende gjengivelseskommandoer til GPU-en, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
- Trege punktgrafikkopplastinger: antall ganger det tok mer enn 3,2 ms å laste opp punktgrafikk til GPU-en, delt på antall skjermbilder for alle skjermbilder som gjengis på mer enn 16 ms.
Løs problemer
Hvis appen din har et høyt antall bilder med gjengivelsestid på mer enn 16 ms, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.
Batteribruk
Oppvekkingslåser som står fast, og delvise oppvekkingslåser som står fast (i bakgrunnen)På sidene Delvise oppvekkingslåser som står fast og Delvise oppvekkingslåser som står fast (i bakgrunnen) ser du delvise oppvekkingslåser som er utløst av appen din gjennom PowerManager-klassen. Delvise oppvekkingslåser sikrer at prosessoren kjører, men at skjermen og bakgrunnslyset for tastaturet kan slås av.
Informasjon om datainnsamling
- Av personvernhensyn blir ID-merker for delvise oppvekkingslås-hendelser anonymisert.
- Data om delvise oppvekkingslåser samles inn når enheten ikke lades og skjermen er av.
- Data for delvise oppvekkingslåser (i bakgrunnen) samles bare inn når appen kjører i bakgrunnen.
- Google beregner den maksimale varigheten for delvise oppvekkingslåser per batteriøkt for å vise hvor mange økter som berøres av en lang oppvekkingslås. Hvis en bruker for eksempel utløser oppvekkingslåser på to timer, bruker Google en maksimal oppvekkingslås-verdi på én time.
- For apper som angir
sharedUserIdi manifestfilen: Du ser bare data hvis maksimalt én app med sammesharedUserIder installert.
Nøkkelstatistikk
- Berørte økter: prosentandelen av batteriøkter der brukerne opplevde minst én oppvekkingslås på mer enn én time.
- Antall økter: omtrentlig antall registrerte økter.
- 90./99. persentil: 10 %/1 % av daglige økter der brukerne opplevde delvise oppvekkingslåser som varte lenger enn tallet som vises.
- Terskel for dårlig funksjonalitet: Hvis appen din viser en forekomstfrekvens som er lik eller høyere enn terskelen som er vist, er den blant de nederste 25 % av de 1000 mest populære appene på Google Play (etter antall installasjoner).
Løs problemer
Hvis appen din har mange delvise oppvekkingslåser som står fast, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.
På Overdreven vekking-siden ser du Alarm Manager-vekkingene som er utløst av appen din. Du ser vekkingsdata for klassene ELAPSED_REALTIME_WAKEUP eller RTC_WAKEUP.
Informasjon om datainnsamling
- Av personvernhensyn blir ID-merker for vekking anonymisert.
- Vekkinger samles inn når enheten ikke lades.
- For å generere en normalisert beregning blir antall vekkinger sammenlignet med tiden enheten går på batteri. Google beregner antall oppvekkingshendelser per bruker per time for å vise hvor mange brukere som berøres av en høy oppvekkingsfrekvens.
- For apper som angir
sharedUserIdi manifestfilen: Du ser bare data hvis maksimalt én app med sammesharedUserIder installert.
Nøkkelstatistikk
- Berørte økter: prosentandelen av batteriøkter der brukerne opplevde mer enn 10 vekkinger per time. En batteriøkt er en aggregering av alle batterirapporter som er mottatt i løpet av en periode på 24 timer. På Android 10 henviser batterirapporter til intervallet mellom to batteriladinger, enten fra under 20 % til over 80 % eller fra en hvilken som helst verdi og opp til 100 %. På Android 11 eller nyere henviser batterirapporter til en fast periode på 24 timer. Google samler bare inn data når enheten er koblet fra laderen.
- Antall økter: omtrentlig antall registrerte økter.
- 90./99. persentil: 10 % / 1 % av daglige økter der brukerne opplevde flere vekkinger per time enn tallet som vises.
- Terskel for dårlig funksjonalitet: Hvis appen din viser en forekomstfrekvens som er lik eller høyere enn terskelen som er vist, er den blant de nederste 25 % av de 1000 mest populære appene på Google Play (etter antall installasjoner).
Løs problemer
Hvis appen din har mange vekkinger, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.
På siden Uforholdsmessig mye Wi-Fi-skanning (i bakgrunnen) ser du når Wi-Fi-skanninger resulterer i høyt batteriforbruk.
Informasjon om datainnsamling
Data om wifi-skanning samles inn når enheten ikke lades og appen kjører i bakgrunnen.
Nøkkelstatistikk
- Berørte økter: prosentandelen av batteriøkter der brukerne opplevde mer enn fire wifi-skanninger per time.
- Antall økter: omtrentlig antall registrerte økter.
- 90./99. persentil: 10 % / 1 % av daglige økter der brukerne opplevde flere wifi-skanninger i bakgrunnen per time enn tallet som vises.
Løs problemer
Hvis appen din har mye Wi-Fi-skanning i bakgrunnen, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.
På siden Overdreven nettverksbruk ser du når mye nettverksdata er tilknyttet en bakgrunnstjeneste. Når bruk av mobilnettverk skjer i bakgrunnen, har ikke brukerne enkel tilgang til kontroller for å stoppe dataoverføringen.
Informasjon om datainnsamling
Data om mobilnettverksbruk samles inn når enheten ikke lades og appen kjører i bakgrunnen.
Nøkkelstatistikk
- Berørte økter: prosentandelen av batteriøkter der brukerne opplevde mer enn 50 MB med nettverksbruk i bakgrunnen per dag.
- Antall økter: omtrentlig antall registrerte økter.
- 90./99. persentil: 10 % / 1 % av daglige økter der brukerne opplevde mer nettverksbruk i bakgrunnen per dag enn tallet som vises.
Løs problemer
Hvis appen din har høy nettverksbruk i bakgrunnen, går du til nettstedet for Android-utviklere for å se anbefalte løsninger.
Tillatelser
Avvisning av tillatelserPå Avvisning av tillatelser-siden kan du se detaljer om prosentandelen av daglige tillatelsesøkter der brukerne avviste tillatelser. En daglig tillatelsesøkt er en dag der appen din har bedt om minst én tillatelse fra brukeren.
Informasjon om datainnsamling
Data om avvisning av tillatelser registreres når brukeren svarer på forespørsler om tillatelser i appen din.
Nøkkelstatistikk
- Avslag: prosentandelen av daglige tillatelsesøkter der brukere avslo å gi tillatelser.
- Ikke spør igjen: prosentandelen av daglige tillatelsesøkter der brukerne avslo å gi tillatelser ved å velge Ikke spør igjen.
- Totalt antall økter: omtrentlig antall registrerte økter.
Løs problemer
Hvis appen din har svært mange avvisninger av tillatelser, kan du gå til nettstedet for Android-utviklere for å få anbefalte løsninger.
Terskler for dårlig funksjonalitet for kjernestatistikk
Google Play har definert terskler for dårlig funksjonalitet i appens kjernestatistikk.
Hvis appen din overskrider en terskel for dårlig funksjonalitet, blir den sannsynligvis mindre synlig på Google Play. Hvis appen din har dårlig funksjonalitet på bestemte enhetsmodeller, styrer Google Play brukere med disse enhetene bort fra denne appen og til andre som er bedre egnet for dem. I noen tilfeller kan det bli vist en advarsel i butikkoppføringen for appen for å sikre at brukerne får de riktige forventningene og har muligheten til å finne alternativer med bedre teknisk kvalitet.
Google Play bruker vanligvis dataene fra de siste 28 dagene når kvaliteten på appen din evalueres, men kan reagere raskere hvis det oppstår kraftige økninger.
Stabilitet
Terskler for brukeroppfattet ANR-frekvensGoogle Play har definert terskler for dårlig funksjonalitet for brukeroppfattet ANR-frekvens:
-
Dårlig funksjonalitet generelt: Minst 0,47 % av daglige aktive brukere opplever en brukeroppfattet ANR-feil på alle enhetsmodeller.
-
Dårlig funksjonalitet på enheten: Minst 8 % av daglige aktive brukere opplever en brukeroppfattet ANR-feil for én enkelt enhetsmodell.
For å forbedre ANR-frekvensen må du fikse de underliggende ANR-gruppene som rapporteres på Krasj og ANR-feil-siden. Jo høyere antallet berørte brukere er, desto mer bidrar gruppen til ANR-frekvensen.
Hvis spesifikke aspekter ved enhetens maskinvare eller programvare kan bidra til ANR-frekvensen, varsler Android-nøkkelstatistikk deg. Du kan også utforske tilknytningene selv på oversiktssiden for rekkevidde og enheter (Utgave > Rekkevidde og enheter > Oversikt).
Google Play har definert terskler for dårlig funksjonalitet for brukeroppfattet krasjfrekvens:
-
Dårlig funksjonalitet generelt: Minst 1,09 % av daglige brukere opplever et brukeroppfattet krasj på alle enhetsmodeller.
-
Dårlig funksjonalitet på enheten: Minst 8 % av daglige brukere opplever et brukeroppfattet krasj på én enkelt enhetsmodell.
For å forbedre krasjfrekvensen må du fikse de underliggende krasjgruppene som er rapportert på Krasj og ANR-feil-siden. Jo høyere antallet berørte brukere er, desto mer bidrar gruppen til krasjfrekvensen.
Hvis spesifikke aspekter ved enhetens maskinvare eller programvare kan bidra til krasjfrekvensen, varsler Android-nøkkelstatistikk deg. Du kan også utforske tilknytningene selv på oversiktssiden for rekkevidde og enheter (Utgave > Rekkevidde og enheter > Oversikt).
Relatert innhold
Se anbefalte fremgangsmåter for bruk av Android-nøkkelstatistikk for å forbedre ytelsen og stabiliteten til appen din.