Google zet apps die vaak crashen lager in zoekresultaten Play Store

Google heeft onlangs het algoritme aangepast voor het weergeven van zoekresultaten in de Play Store. Daarbij wordt nu ook gelet op de kwaliteit van de app. Als apps vaak crashen of de batterij snel leegtrekken, dan worden ze lager weergeven in de lijst.

Volgens Google hebben de wijzigingen een positief effect. Op het Android-ontwikkelaarsblog schrijft Google dat mensen meer gebruik maken van 'apps van hoge kwaliteit' en minder vaak apps verwijderen. Wanneer de wijzigingen zijn ingegaan is niet bekend.

Google geeft geen details over hoe het apps waardeert als het gaat om crashes en issues zoals accuverbruik, maar waarschijnlijk gebruikt het daarvoor de diagnostische gegevens die naar Google worden gestuurd als een app crasht.

De Play Store-beheerder benadrukt tegenover ontwikkelaars dat zij Android vitals kunnen gebruiken om prestatieproblemen op te sporen. Volgens Google is instabiliteit van apps een van de grootste ergernissen van gebruikers. In de helft van alle 1-sterbeoordelingen in de Play Store zou app-stabiliteit als kritiekpunt genoemd worden.

Reacties (64)

[Swerfer]

Ik mag wel hopen dat de crashes die gerapporteerd worden ook gefilterd worden. Ik hou van mijn app crashrapporten bij en merk op dat de meeste crashes niet in mijn eigen code zitten, maar in de api's van, in mijn geval, Microsoft (Windows 10 app). Misschien dat indirect in die api's crashes ontstaan door mijn code, maar lang niet altijd als ik naar de stacktrace kijk.

Het zou lullig zijn als apps lager in de zoekresultaten komen omdat de app gebruikt maakt van een api die zelf niet stabiel is...

[eric.1]

Maar goed, het maakt voor de eindgebruiker toch niets uit of dat direct door jouw code komt of door code die jij aanroept? Links- of rechtsom crasht jouw app, mocht dat geregeld gebeuren == ergernis.

Indien de API die je gebruikt niet stabiel is kun je ook kijken of je het gebruik van de API wellicht kan verbeteren (error-afhandeling?) of zelfs kan omzeilen.

[Reactie gewijzigd door eric.1 op 23 juli 2024 06:05]

[seapip]

De crashes waar Google op controleert zijn niet alleen gehele applicatie crashes maar ook gewoon errors die gethrowed worden door het crashen van een closed source library, deze kan je simpelweg niet catchen en zijn vaak ook gewoon niet merkbaar voor de eindgebruiker.

[Reactie gewijzigd door seapip op 23 juli 2024 06:05]

[EngineerCoding]

Try-catch all the things!

[seapip]

Zit met hetzelfde probleem, ik gebruik de Spotify android SDK en die crashed ook ieder uur ondanks dat het gewoon blijft werken voor de gebruiker en deze er niks van merkt.

En de crash fixen is niet mogelijk omdat deze ontstaat uit de closed source lib

Dus als dit inderdaad niet gefilterd wordt dan kom je al snel onderaan staan, ik heb nu namelijk meer crashes dan gebruikers

[Reactie gewijzigd door seapip op 23 juli 2024 06:05]

[3x3]

Misschien is dat een goede reden om een andere, geen of eigen api te gebruiken? En als het niet mogelijk is doordat je perce spotify's api nodig hebt. Dan zullen concurrenten voor jouw app die zich ook richten op spotify daar evenredig last van hebben.

Uiteindelijk heeft deze maatregel misschien ook wel effect op spotify zelf. Als alle apps die werken met hun api minder vindbaar zijn dan apps die werken op basis van concurrende api's zal een superieur alternatief voor spotify vanzelf populairder worden!

[seapip]

Beetje lastig om op een andere manier muziek van Spotify af te spelen zonder de closed source SDK van Spotify zelf immers is elke alternatieve SDK een hack en tegen de gebruikersovereenkomst van Spotify. En een bedrijf als Spotify is groot genoeg om deze klachten te negeren.

Laat staan dat ze een van de enigen zijn die een SDK aanbied, de meeste muziek diensten bieden helemaal geen SDK aan om muziek te streamen met een 3rd party app. En de meeste eindgebruikers laten echt niet hun streaming dienst keuze afhangen van een 3rd party app.

Dat anderen die dezelfde SDK gebruiken er evenredig last van hebben is wel een punt waar je gelijk in hebt

[Reactie gewijzigd door seapip op 23 juli 2024 06:05]

[Mittchel]

Je kan gewoon de spotify api hiervoor gebruiken. REST calls. Desnoods bouw je daar je eigen SDK omheen. Meerdere wegen naar Rome.

[seapip]

Nee dat kan niet, ik gebruik die rest web api uiteraard voor het ophalen van informatie en dergelijke maar het probleem zit hem in de Spotify Android SDK.

Deze gebruik je om daadwerkelijk hele muziek nummers af te spelen, hierin zitten gewoon een grote verzameling aan bugs. Deze SDK kan ook helemaal niet de dingen die de web api kan, dit zijn echt 2 geheel verschillende apis die je vaak beiden gebruikt.

[Reactie gewijzigd door seapip op 23 juli 2024 06:05]

[Mittchel]

Doet die Android SDK niet onder water gewoon een rest call dan? Dit zou je middels wireshark of fiddler kunnen inspecten. Ook kun je iets als classyshark gebruiken om de SDK te ontleden en te zien wat er gebeurt. Lijkt me sterk dat ze zelf geen api aanroepen. Zodra je dit kan mimicen zit je goed denk ik.

Heb zelf nooit iets met Spotify gedaan hoor, maar op deze wijze omzeilen wij soms brakke SDK's.

[seapip]

Nah dat zou waarschijnlijk veel werk zijn omdat het ook met versleuteld media streams werkt en dergelijke en is het uiteraard compleet tegen de EULA dus ook niet bruikbaar voor een productie app.

[Mittchel]

Vraag me af of het tegen de EULA is als je zelfde encyrptie methodes gebruikt. Als zij hun SDK niet obfusceraten dan kun je het denk ik gewoon doen. Veel werk is het wel idd 😁

[djwice]

Soms crashen API's van anderen als de tussentijd tussen twee geauthoriseerde calls langer is dan tijd X.
De api heeft dan niet op alle services de verlopen token afhandeling correct geïmplementeerd en dus krijg je een 500 of een timeout.

In andere gevallen is het juist te veel simultane calls vanaf dezelfde api-key.


Wellicht helpt dit jullie het aantal crashes te verminderen. Uiteraard is vaak niet gedocumenteerd wanneer een api crashed.

[Reactie gewijzigd door djwice op 23 juli 2024 06:05]

[RobLemmens]

Normale ontwikkelaars gaan dan ook geen product uitbrengen op basis van een instabiele api dus in deze enkel lof voor Google. Als jij in je product pruts api's gebruikt of deze verkeerd toepast dan heb je ook een pruts product. Als een library die veel gebruikt wordt steeds crashed in je app dan doe je waarschijnlijk zelf iets verkeerd, ja je zou kunnen zeggen dat die api kapot is maar dat is niet hoe een eindgebruiker en dus je klant dat ziet.

[djiwie]

Ik had een tijdlang een enorme hoeveelheid crash reports van één specifiek model Samsung waar blijkbaar een bug in de date picker zat. Dat is gewoon een standaard UI element en je gaat niet voor één toestel de hele UI omgooien (of zelf een date picker maken), zoiets moet de telefoonmaker gewoon oplossen.

[erikieperikie]

In dat geval heeft iedereen die dezelfde API's gebruikt er last van en dan maakt dat weer minder uit. Als het ligt aan de manier waarop jouw app de API gebruikt, dan ligt het dus toch weer aan jouw app. Linksom of rechtsom maakt het dus weinig uit. Het enige wat je kunt proberen is zo veel mogelijk die API's te vermijden, maar dat kan niet altijd.

[Distrax1988]

Krijgt de ontwikkelaar hier dan ook bericht over? anders zou het wel een boycot zijn.
Neem aan dat er statistieken verzameld worden en die eens per maand of week worden verstuurd worden naar de ontwikkelaar.

[SgtElPotato]

Tuurlijk krijgen de ontwikkelaars hier bericht over, zou een beetje raar zijn als Google dit zou doorvoeren zonder de ontwikkelaar op de hoogte te stellen

Tevens goede ontwikkeling, want als je bijvoorbeeld op een 'zaklamp' app zoekt wil je de beste apps zien in de top 5 en niet de apps die mogelijk vaak crashen. Die mogen wat mij betreft onderaan de lijst gezet worden of zelfs op de app pagina een melding: 'Let op; de app kan mogelijk crashes veroorzaken' (al vraag ik me af hoe het dan zit met de imagoschade die een app mogelijk op zou kunnen lopen).

[Distrax1988]

Ik neem niks meer aan met 'tuurlijk' of 'wat denk je dan' bij Google, er moet een inhoudelijk label komen (funcitoneel, en de app) daarnaast verbinding en performance label zou wenselijk zijn, en niet ergens moeten terug vinden in de comments van de review.

[3x3]

Op dit moment krijgt een ontwikkelaar al bug reports via de Play Development Console. Dus je suggestie dat app-ontwikkelaars niet weten of zouden weten over dat ze een vaak crashende app hebben lijkt mij een beetje raar.

[Faceless]

In de ontwikkel console kun je alle door de gebruikers gerapporteerde crashes zien.

[Cybergamer]

Daar heeft de gemiddelde consument geen donder aan. Het zou handiger zijn als dat beter toegankelijk zou zijn.

[m8ZBm1Si]

De vraag van Distrax1988 was of ontwikkelaars deze crashes ook konden zien / hierover bericht kregen. tomalbers gaf daar antwoord op met dat de crashes te zien zijn voor ontwikkelaars.

De gemiddelde consument is daarin volledig niet relevant, want dat vroeg Distrax1988 helemaal niet.

[Cybergamer]

Ow, my bad. Ik heb het blijkbaar verkeerd begrepen!

[m8ZBm1Si]

Kan natuurlijk altijd een keer gebeuren.

[Soldaatje]

Precies, en wat veel belangrijker is is dat Google dit bij de app zichtbaar moet maken waarom de app slecht is!
Nu weten we nog niks.

[djiwie]

Dat hoeft ook niet, de app scoort gewoon lager als je zoekt op een bepaalde term. Daar spelen wel meer factoren een rol in en de hoeveelheid crashes+battery drain is er één van.

[3x3]

Als er via Android Vitals analyses zijn te maken die prestatieproblemen en crash-oorzaken kunnen opsporen. Is het dan niet een beter idee om apps te laten benchmarken voor ze uberhaupt worden toegelaten in de app-store?

Als consument is het gewoon erg vervelend dat er bijzonder veel rommelige crashende apps in de Play Store aanwezig zijn en toegelaten worden. Het niet alleen lager zetten in de rijtjes, maar het ook weigeren van dramatisch slechte apps zal meer effect hebben om programeurs te dwingen een nette app af te leveren.

[Origin64]

De keerzijde daarvan is dat android steeds meer richting apple gaat. Google bepaalt welke apps populair worden, welke er goed draaien, etc. Lijkt me niet dat bijv. de facebook app naar beneden zal schuiven zelfs als deze om de haverklap crasht.

[Kama]

Daar ben ik het niet mee eens. De selectie hier is uitsluitend op basis van objectieve app kwaliteit (=aantal gemelde crashes / installaties) en niet op basis van inhoud of andere subjectieve zaken.

Uitgevers en ontwikkelaars moeten leren dat QA onderdeel moet zijn van het ontwikkelproces. Als je rommel oplevert dan moet je daar ook de gevolgen van ondervinden. Die feedback loop is nu wat versneld (en overigens kan het ook imagoschade schelen voor de betreffende ontwikkelaar).

Een "vriendelijkere" manier zou zijn om te melden hoeveel crashes een app zou hebben, maar als gebruiker zou ik me dan afvragen waarom een app uberhaupt nog tussen de zoekresultaten staat als het zo onstabiel is.

[Origin64]

Hoe kan iemand verifieren dat het proces objectief is? Play store is niet open source.

[Reactie gewijzigd door Origin64 op 23 juli 2024 06:05]

[pepsiblik]

Alleen is de rede waarschijnlijk eerder dat Facebook adequaat reageert op crashes en niet dat Google ze beschermt. De goede ontwikkelaar zorgt dat ie binnen no-time een fix in the store heeft staan. De slechte ontwikkelaar doet er maanden over.

Edit: Google heeft zijn eigen social network app(s). Dus Facebook een hak zetten door ze lager op de lijst te zetten zou ze opzich niet eens slecht uitkomen. Ze hebben net zoveel redenen om Facebook dwars te zitten als om Facebook te vriend te houden.

[Reactie gewijzigd door pepsiblik op 23 juli 2024 06:05]

[Koekhapperrr]

Ik neem aan dat die analyses pas goed werken op het moment dat veel gebruikers de app geïnstalleerd hebben. Anders is het heel lastig om goede statistieken te krijgen verdeeld over meerdere devices.

[3x3]

Als analyse vooraf niet voldoende is, is analyse terwijl een app actief wordt aangeboden door Google's store ook niet verkeerd natuurlijk.

Als dan een app alsnog geweigerd wordt, dwing je de ontwikkelaar alsnog om fouten op te lossen. Alleen lager in de ranking maakt voor bepaalde apps die gebruikers vooral zoeken via de zoekmachine niet veel uit. Zit je bij een bank, telefoonaanbieder, of overheid die een app vereist.. dan maakt de ranking niet zoveel uit.

Echte (dreiging van) verwijdering van zo'n app, zou voor de ontwikkelaars van dat soort apps veel meer druk zetten om gewoon een app van acceptabele kwaliteit af te leveren. Dat is niet alleen goed voor die partijen en consument/burger, maar ook voor het android platform zelf.. want de gebruikservaring is soms ronduit bedroevend te noemen.

[HellFury]

Google Play Protect (het op de achtergrond scannen van geïnstalleerde apps) scant apps op "harmful behavior". Ik kan me voorstellen dat, naast het scannen op virussen en malware, dit ook scant op slecht draaiende apps, en de crash logs naloopt. En anders zou dat een mooie uitbreiding hiervan zijn.

[Gomez12]

Alleen lager in de ranking maakt voor bepaalde apps die gebruikers vooral zoeken via de zoekmachine niet veel uit. Zit je bij een bank, telefoonaanbieder, of overheid die een app vereist.. dan maakt de ranking niet zoveel uit.

Juist voor die partijen is de ranking essentieel, ik denk zelfs dat die partijen mogelijk buiten dit proces gehouden moeten worden.

Als Bank heb je een redelijke uitdaging als jouw App onderaan staat maar een scammer App met hetzelfde logo uit joegoslavie bovenaan. En scammer app is hier zo'n ruim begrip dat het niet altijd geweerd kan worden door de App-Store zelf.
Of wat denk je als er een digid app bovenaan staat die vraagt om je inlognaam en wachtwoord om je daarna op een digid.tv site in te laten loggen, dat is 100% legitieme toepassing, alleen het is ietwat ongewenst als die in NL boven de officiele digid app komt, want dan kan het anders wel heel erg verleidelijk worden om die foute logins op die site te loggen.

[Koekhapperrr]

Dit kan inderdaad nog wel eens handig zijn. Het is ook vervelend dat apps die bijvoorbeeld veelvuldig, onnodig gebruik maken van locatievoorzieningen in het accuoverzicht allemaal onder de noemer "Google Play Services" geplaatst worden.

Daarnaast is het sinds Android Nougat niet meer mogelijk om (ongeroot) iets als een taakbeheer te gebruiken, waarmee je kan zien welke app veel CPU-cycles gebruikt. Eerder kon je hiermee op momenten dat je batterij snel leeg liep of de telefoon een beetje 'sloppy' werd snel zien welke app de boosdoener was.

Uiteindelijk heb ik liever dat het allemaal gewoon werkt en je überhaupt niet meer de behoefte hebt naar dit soort dingen te kijken. Dan is dit wel een stap in de goede richting.

[RobbieB]

Uiteindelijk heb ik liever dat het allemaal gewoon werkt en je überhaupt niet meer de behoefte hebt naar dit soort dingen te kijken.

Ik ga hier vast flink wat -1's mee scoren maar als je dat wil moet je een iPhone nemen. Je kunt veel vinden van iOS en de zaken die Apple niet toelaat op hun toestellen, maar de dagelijkse issues waar veel Android gebruikers mee kampen (battery drain, crashende apps, malware, achterstallige updates, bloatware) zijn op iOS echt vrijwel een non-issue. Natuurlijk is het niet perfect maar het verschil tussen de 2 OS'en begint wel echt steeds schrijnender te worden...

[tijgetje57]

Ik kan zo en zo zien welke app er veel battery drained via mijn MIUI8.

Je kan ook zo zien welke app er veel data verbruikt, deze kun je dan beperken tot alleen wifi.

Goede beslissing om apps die draconisch omgaan met resources op de smartphone onderaan te plaatsen. Geeft gebruikers ook goede informatie dat je dit soort apps niet moet hebben.

[Koekhapperrr]

Datagebruik interesseert mij niet zo, maar dat zit ook standaard in Android ingebakken.

En natuurlijk kan je in het accuscherm een overzicht van apps zien en het percentage batterij dat ze gebruikt hebben. Apps gebruiken voor hun meest belastende zaken alleen Google Play Services, waardoor dit pakket vaak bovenaan staat in het overzicht, zonder dat duidelijk is welke app hier precies verantwoordelijk is.

[Zenomyscus]

Het viel mij tijdens mijn vakantie op dat Google Play Services veel data en stroom verbruikt. Ik heb die service op 'restrict background data' gezet en ben verder niet tegen problemen aangelopen. Ik weet eigenlijk niet wat voor gevolgen mijn actie heeft. Maar ik vond 50mb data (30 in background) te veel worden.

[pepsiblik]

Ik doe hetzelfde. Lijkt mij geen nadeel te hebben. Ok, soms krijg je updates later binnen. Big deal...

[HellFury]

Google Play Services doet heel veel, maar door het restricten zie ik zo al dat: je locatie minder vaak en minder accuraat kan worden vastgelegd voor gebruik van je Tijdlijn in Google Maps (of je dat wel of niet erg vindt mag je zelf weten) en het handelt ook de push notificaties af van apps die Play Services gebruikt. Het kan dus zijn dat je pushberichten van een nieuwe mail, nieuw whatsapp-bericht e.d. later krijgt.

[mat.hi.as]

Dan komt Pokemon Go dus zo'n beetje onderaan, met al die crashes en battery drain die iedereen repporteert de laatste weken (en eigenlijk al sinds het begin).

Zonder dollen, dit klinkt best aardig. Kwalitatief betere apps beter vindbaar. Voor zowel de gebruiker fijn, als voor de developers een goede motivatie om een kwalitatief goede app neer te zetten (en onderhouden + fixen).

[3x3]

Voor een app als Pkmn Go verwacht ik juist niet dat dit middel veel effect heeft. Pkmn Go is een hype game, die zoek je waarschijnlijk op via de zoekfunctie, omdat je in de media gelezen hebt over de game of hype, iemand anders in je omgeving de game ook gebruikt of het wordt aangeraden door iemand.

Hetzelfde geldt voor een slechte bank app, of slechte app van een mobiele telefoonprovider, overheid of andere instantie.

[RoestVrijStaal]

Prima. Als app ontwikkelaar zal ik dan vereisen dat de smartphone 4 GB aan RAM en 4 GHz met 16 core CPU aan boord moet hebben, geen TouchWiz als GUI mag hebben en maximaal 5 apps in de background mag draaien, anders start de app "niet verder".

Apps crashen vaak niet zomaar.
Dat gebeurt ook omdat Jan met de Pet een "lekker goedkope" of "tweedehands / refurbished" smartphone koopt met specs van een decennia terug en dan ook nog eens apps op installeren of preinstalled apps op hebben die op de achtergrond draaien en weinig resources laten overhouden voor de foreground apps.
Ja, geen wonder waarom die foreground apps dan crashen. Ik als app ontwikkelaar laat mijn ranking dan niet door een groepje met crappy phones naar beneden halen.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 16:19]

[Proxi]

Ik snap de downmods niet echt, RoestVrijStaal start een relevante discussie en uit gewoon zijn mening.

OT: Ik ben het hier mee eens. Vaak genoeg zie ik crashes bij onbekende en onstabiele tablets van 50 euro. Dus puur omdat je doelgroep toevallig goedkope B-merken koopt, word je lager in de zoekresultaten geplaatst. Het is nou eenmaal zo dat Android op ontzettend veel apparaten draait, daardoor kun je niet elke combinatie van Androidversie en hardware testen. Een crash ligt vaak niet alleen aan een ontwikkelaar, maar kan bijvoorbeeld ook aan het type (obscure) GPU liggen.

[Krulliebol]

Mee eens, echter:
als dat de doelgroep van je app is (zoals je schrijft), moet je ofwel je app optimaliseren voor slechtere devices ofwel je op een andere doelgroep richten.

[RoestVrijStaal]

In mijn voorbeeld (met flink aangedikte specs om mijn punt te maken) doe ik dat toch al?

Ik dwing af dat enkel mensen met fatsoenlijke phones mijn app kunnen draaien. En dat het riedeltje dus niet crasht vanwege te lage specs of brakke configuratie.

Dat scheelt mij ook een hoop tijd dat ik kan gebruiken voor nieuwe features en versies eerder kan releasen. I.p.v. tijd en moeite in steken in verouderde of Aldi/Action-smartphones die ook nog eens mijn ranking omlaag kunnen halen. Dat hen weinig tot geen geld aan hun smartphone uit willen geven moet niet mijn probleem zijn.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 06:05]

[Krulliebol]

Ja, min of meer wel.

Wat ik dacht:
Je hebt het over een app voor een doelgroep die goedkope B-merken koopt. Dat wekt de indruk dat de aard van de app paupers aantrekt (je maakt een app met een bepaalde doelgroep op het oog). In dat geval zou je dus een ander soort app moeten maken: met inhoud die enkel aantrekkelijk is voor mensen die de nieuwste/duurste telefoons kopen.

[Kama]

Als het aan het zuiver aan het device ligt, zal jouw app niet vaker crashen dat andere apps, dus dan zul je er niet bovenuit steken met je app.

[Zenomyscus]

Doei Pokemon Go

Ik vind het een prima idee. Een indicatie voor batterijgebruik en hoeveel onzinnige opslag de app gebruikt zou ik ook graag zien. Je download een spel en een maand later is er 300mb aan data bij gekomen. Het moet altijd meer, groter en minder zuinig. Apps zijn soms zo erg dat je je accupercentage ziet aflopen.. Soms heb ik het idee dat ontwikkelaars nergens op letten. Mooi dat ze daar nu op gewezen worden.

[Jaded]

Slecht nieuws voor de Rabobank app

[himlims_]

positief voor de consument; ze 'moeten' nu wel iets fatsoenlijks bouwen

[com2,1ghz]

De oude app was een native app en die werkte wel soepel. Helaas moesten zij ook mee met de hybrid web app hype waardoor ze nu een gare app hebben. Hoe vaak ik wel niet een 404 krijg als ik gewoon probeer in te loggen. Na restart van de app werkt het opeens wel.

[Stoelpoot]

De Rabo app vind ik nog wel stabiel. Draconisch, traag en onhandig, maar stabiel.

[Faceless]

De app die vaak bij mij crasht is Chrome.

[blorf]

Als ze nou eerst eens zorgen dat de gebruiker ook alle geinstalleerde apps kan controleren gebruikte bronnen en gewoon kan stoppen en uninstallen. Persoonlijk vind ik het compleet belachelijk dat ik bij de 10 apps die ik gebruik verplicht nog tegen 20 andere brouwsels van Samsung of Google moet aankijken. Totaal niet realistisch om over de matige kwaliteit van sommige apps te kletsen. De hele handel is al bloated van de overbodige troep.

[FreshMaker]

Voor Samsung kanje deze gebruiken
https://play.google.com/s....packagedisablerpro&hl=nl

Zeker (alleen) op unrooted telefoons, maar je kan héél veel disablen, ook externe services