Foto laat Android-smartphones crashen bij instellen als achtergrond

Er blijkt een foto in omloop te zijn die bij instellen als achtergrond op een Android-smartphone, ervoor zorgt dat de software crasht. Die problemen blijven bestaan na een reboot waardoor gebruikers hun smartphone moeten resetten.

De afbeelding circuleert sinds dit weekend, en blijkt onder meer bij Samsung-smartphones voor problemen te zorgen, zo meldt 9To5Google. De website testte de afbeelding vervolgens met een Pixel 2, en kon het crashen van de Android-software reproduceren.

Wie de bewuste afbeelding instelt als achtergrond, krijgt daarna een scherm dat steeds aan en uit gaat. Bij het aan gaan van het scherm is kortstondig het lockscreen te zien, maar de gebruiker kan het toestel verder niet bedienen. Het blijkt dat het opnieuw opstarten van de smartphone niet werkt, waardoor het in sommige gevallen nodig is om de fabrieksinstellingen te herstellen via de bootloader. Overigens lijkt het verwijderen van de desbetreffende afbeelding van de smartphone ook een oplossing te zijn.

Het is niet geheel duidelijk waar het probleem door wordt veroorzaakt. Een theorie gaat over de gebruikte kleurruimte; na het aanpassen van de kleuren lijkt de bewuste afbeelding geen problemen meer te veroorzaken. De afbeelding is gemaakt met de rgb-kleurruimte, terwijl Android liever srgb ziet; dit lijkt op Android 10 een probleem te vormen, maar Android 11, waarvan binnenkort een bèta moet uitkomen, kan er juist wel weer mee omgaan. Google heeft nog niet op het voorval gereageerd, waardoor de achtergrond van het probleem nog niet volledig is opgehelderd.

Reacties (111)

Grappig dat de foto wel gewoon weergegeven wordt. Ik had verwacht dat het zou crashen tijdens het renderen waardoor je niets zou zien.

Overigens niet zo heel spannend lijkt me, logcat eraan koppelen en je ziet gelijk wat het probleem is..

EDIT: Het is overigens wel duidelijk wat het probleem veroorzaakt. De colorspace inderdaad. Lijkt veel op deze bugreport: https://issuetracker.google.com/issues/153514657

[Reactie gewijzigd door ultimate-tester op 1 juni 2020 12:21]

Status: Won't Fix (Not Reproducible)
We are closing this issue as this issue is not reproducible.

Dit is waarom ik geen Android bugs meer rapporteer. Je moet praktisch de bugfix aanleveren, zo niet dan gaat de bug meteen dicht, en heropenen doen ze niet aan. Waardeloos, want zo krijg je honderden losse bug reports die allemaal gesloten worden, in plaats van een aggregatie van meerdere gebruikers hun data die gezamenlijk voldoende kunnen zijn om hem te reproduceren.

I set my home screen wallpaper to Cityscapes daily wallpaper; eventually, one of the new wallpapers triggers the crash. Since the crash is triggered by loading the new wallpaper, I have no idea which particular image is triggering it.

Of omdat er praktisch echt niet konden reproducen, omdat er geen specifieke afbeelding kon worden aangewezen die deze bug kon reproducen.

Je hebt mijn comment niet gelezen. Als de ticket open zou blijven in een "need more info" state zouden anderen hem kunnen aanvullen, mocht iemand het zelfde probleem tegen zijn gekomen met een specifieke afbeelding.

Dat is voor elke issue tracker anders, wij zelf hebben dit wel dat we issues openlaten als het probleem echt bij ons ligt en niet weten hoe we het kunnen reproducen. Ik heb daarin tegen ook issue trackers meegemaakt zoals nu ook issue tracker van Google ze het een wontfix geven.

Ja, en ik zeg dus dat iets direct op wontfix gooien gigantisch dom is omdat je jezelf op de lange termijn in de vingers snijd - je creëert een enorme hoeveelheid gesloten duplicaten waardoor de historie van enkele bug zich door je hele tracker versnippert. Als die bug later dan ineens belangrijk blijkt te zijn zit je met de administratie, en je had hem in eerste instantie al prima kunnen fixen door informatie van meerdere reports bij elkaar in één issue te aggregeren. Ik heb echt 0 respect voor teams die het zo aanpakken, het is alleen maar leed voor users, devs en qa. Het enige doel is het getalletje van open bugs zo laag mogelijk houden en dat is simpelweg frauduleus: er is immers een bug gevonden.

Wont fix is voor geverifiëerde issues waar besloten is dat ze het niet waard zijn. Maak dan een cannot reproduce state die je automatisch na een paar maanden inactiviteit op closed zet.

Wont fix is voor geverifiëerde issues waar besloten is dat ze het niet waard zijn. Maak dan een cannot reproduce state die je automatisch na een paar maanden inactiviteit op closed zet.

Dat ben ik met eens, wat Google hier doet is niet etisch en zoals je zelf zegt het getal laag houden.
Ze doen het heel smerig ze hebben de label `Won't Fix (Not reproducible)`. Dus als 1 iemand het niet kan reproducen is het gelijk `Oke ja dit is user error we kunnen er niks aan doen aan onze kant` en volgende issue.

Volgens mij kan je een bugfix gewoon op de backlog plaatsen voor een volgende sprint (wat mogelijk ook een bugsprint is)?

Oftewel gewoon die bug openlaten voor den eerstvolgende die er wel mee wat kan. AFAIK Sprints zijn niet zo zeer om bugs nouja misschien een bug die al langere tijd voordoet. Maar een standaard sprint gaat meestal ` we willen sowieso x feature en x methode rewritten zodat compent y ermee kan werken. En ohja alle bugs zijn mooi meegenomen. `

Bugs weet je niet welke allemaal gereport worden, je weet wel welke features je aan moet werken.

Dus conclusie het was totaal onnodig om die issue te sluiten en kon makkelijk op de backlog werden gezet.

Dat zou netjes zijn. Of opsplisten in losse werkitems om zo proberen het probleem in stukjes op te hakken mocht je er niet uitkomen.

Zonder meer afsluiten is niet de juiate werkwijze. Pak dan maar waterval erbij.

ps.
min punten mag. Ben gewend dat een kritische housing op scrum niet als prettig wordt gezien.

Je krijgt minpunten omdat dit is zijn geheel niets met scrum te maken heeft. Bovendien ging de discussie in deze thread over issue trackers en het gebruik ervan. Of je een issue tracker gebruikt met scrum/agile of waterfall is geheel je eigen keuze.

Sprints gaan om features(meeste deel) en bugs zijn mooi meegenomen.

Dan zet je hem toch gewoon terug naar backlog en veaag je extra gegevens aan? Moet zker bij dit issue toch vrij simpel zijn. “Hee als ik deze afbeelding instel als achtergrond flipt mn toestel”.

Kennelijk is het een android issue dus had dit met gemak reproducible moeten zijn. Het niet tijdig kunnen analyseren van bugs zou nooit “Cannot reproduce” Op moeten leveren als er voldoende reproductie info beschikbaar is.

Ik zou op zijn minst eens vragen of de stappen voor reproductie wel kloppen. Krijg vaak zat bug reports binnen waaruit uiteindelijk blijkt dat men de documentatie niet goed heeft gelezen, maar dat moet je dan wel even verifiëren.

Binnen scrum zou je als iets classificeert als "bug" dit direct moeten oplossen, maar tja dan blijft de eeuwig discussie is het een bug of niet,

Het gaat niet om dat rapport, maar om dit rapport en dat staat op 'Fixed': https://issuetracker.google.com/issues/76022479

cc @Gusted

Hoe zijn deze 2 Issues aan elkaar gelinkt.

De code waar de error zich voordoet lijkt niet in dezelfde classes.
Correct me If I'm wrong.

Dit is de issue waar andere media naar verwijzen.

Ah, dat make sense.....

Het is dat ik geen orginele afbeelding heb die niet gecompressed is anders is het wel te acherhalen of die 2 issues aan elkaar gelinkt zijn. In de andere media gelinkte Issue is de `Wallpaper` met Adobe sRGB al geconverteerd. Specifieker `photoshop:ColorMode="3" photoshop:ICCProfile="sRGB IEC61966-2.1"`. Als de nieuwe afbeelding ook specifiek is geconverteerd naar een kleurruimte is het aannemelijk dat de 2 issues aan elkaar gelinkt zijn, anders is het in mijn ogen een nieuwe bug met andere error en een andere achtergrond hoe dit gebeurd is.

Je hebt ook de foto mee gestuurd. In zip ingepakt. Incl alle info mbt je toestel en android versie.
Als je als bugfixer moet gaan lopen zoeken welke afbeelding en van welke site het probleem veroorzaakt ben je even bezig. Daarbij komt nog dat een heleboel sites en app's afbeeldingen aanpassen.

Ja ok, maar dat is je werk. Terwijl degene die het meldt dat gratis en vrijwillig doet.

Ondertussen is het crashen bij het laden van een afbeelding een serieus issue. Het zou ook zo maar exploited kunnen worden. De meeste exploits beginnen met een crash bug.

Dus ik vind ook wel dat je dan zo'n issue niet meteen moet sluiten. Als je te weinig info hebt geef je dat aan en laat je hem open. Toch op zijn minst een paar weken of maanden. Anders je eigenlijk tegen degene die het gemeld heeft dat je die moeite niet serieus neemt.

Dit is waarom ik geen Android bugs meer rapporteer. Je moet praktisch de bugfix aanleveren, zo niet dan gaat de bug meteen dicht, en heropenen doen ze niet aan.

Ik kreeg een paar weken terug een reactie van Google op een bug in Android Studio die ik gemeld had in 2016. Of ik kon aangeven hoe de bug te reproduceren. Lekker zinloos.

Tja, mijn bugs werden allemaal binnen 3 weken gefixt en in de volgende release gestopt.

Dingen rond multi account gebruik bijvoorbeeld, geen makkelijke issues om op te pakken.

Precies gewoon een falend beleid dat bij Google gehanteerd wordt. Pas als een bug in de media beland gaan ze er eens naar kijken, als gebruiker ben je machteloos.

Google Devs zijn echt achterlijk soms..

Word gewoon niet geluisterd naar de gebruikers. Bij Google Chrome hebben ze al een tijdje een functie: Chrome Duet. Ideaal voor de schermen van nu, want de belangrijkste knoppen staan beneden. Dit werkte perfect tot ze besloten dat 5 knoppen teveel zijn en toen alles omgegooid hebben: https://www.androidpolice...hrome-duet-three-buttons/

Of je schakelt de telemetry terug in.

Je kunt in 10 sRGB aan en uit zetten.
Weet niet zeker of je daar developers-mode moet inschakelen want dat is ongeveer het eerste dat ik deed.

Alleen gaat het niet om dat bugrapport, maar om dit bugrapport: https://issuetracker.google.com/issues/76022479

https://mobile.twitter.co...tatus/1267295176046723072

Het probleem schijnt verholpen te zijn in een komende update. Samsung is begonnen met de uitrol van de Juni update in verschillende landen. Wellicht dat de oplossing hier al in zit. Al is de bug niet beperkt tot alleen Samsung toestellen.

Vind het bijzonder dat Google er voor kiest om een nieuwe kleurruimte te creëren (Google skia) terwijl er al zoveel breed geaccepteerde kleurruimtes zijn. Adobe rgb en p3 dekken al bijna alle mogelijke kleuren en zijn breed geaccepteerd.

Edit: Voor degene die niet door de tweets willen lezen. Deze crash bug komt door een conversie fout van Google skia naar sRGB waardoor er een array out of bounds fout word gemaakt die niet goed word opgevangen

[Reactie gewijzigd door mikesmit op 1 juni 2020 13:07]

Volgens mij is er het veel erger dan een array out of bounds.
Een crashende applicatie zou nooit het besturingssysteem moeten (kunnen) laten vastlopen. Dat duidt op een fout ontwerp en/of implementatie van het Android besturingssysteem.

Zo te zien loopt de kernel ook niet vast. De UI wordt echter onbruikbaar. Een probleem wat ik overigens ook een groot probleem met bijvoorbeeld Windows en Linux vind. Bij beide heb je niks meer aan je OS als je grafische interface (of vroeger bij Windows, Explorer) crashed. Bij beide heb je als power user dan nog enige kans om het weer goed te krijgen, maar meestal is je werk - wat immers meestal in een windowed applicatie draait - gewoon weg. Ik heb zelfs nu nog met Ubuntu met enige regelmaat crashes van de X-windows gebaseerde GUI.

Ik kan op Windows 10 zoinder straf explorer.exe compleet afsluiten en weer opstarten.

Kon ik volgens mij met "iets meer moeite" in Windows 7 en xp ook al. Moest je dan taakbeheer - > uitvoeren - > explorer.exe

Dit probleem lijkt nu net het equivalent van in windows 7 explorer af te sluiten in taakbeheer. Dan zal die automatisch terug opstarten en kan je verder doen.
Het wordt moeilijker als je elke seconde explorer afsluit. Dan ga je niet veel meer doen op je windows installatie.

Hmm wat is je straf dan?

Die is er niet. Dat zegt keranoz juist!

O, huh, hoe kon ik dat nou verkeerd lezen.

Omdat je dan een zoinder straf krijgt, die zijn heel erg, erg!

Ja, dit is jaren geleden alweer verbeterd. Vroeger was het echt een probleem, nu veel minder. Sterker nog, er is een tijd geweest dat explorer weer automatisch opstart als je hem killed. Het zou kunnen zijn dat ze het er ondertussen weer uitgehaald hebben omdat het simpelweg minder nodig is.

Vroeger waren er ook meer plugins nodig voor explorer, en tja, dan crashed het ding natuurlijk ook sneller. En daarvoor nog was Windows Internet Explorer geïntegreerd. Als dat component crashde was je meteen ook je taakbalk kwijt; erg handig - maar niet heus.

[Reactie gewijzigd door uiltje op 1 juni 2020 15:32]

Je kunt toch gewoon een console op starten met crt-alt-f3 bijvoorbeeld? Dat is juist een voordeel van Linux

Ja, en haal ik daar mijn werk mee terug in mijn IDE of editor? Bij het herstarten van X crashen nog steeds je programmas. Ik heb er geen barst aan dat mijn kernel nog leeft als mijn programmas dood zijn. Dit is een fout die wel meer nerds lijken te maken (daar reken ik mezelf ook onder overigens).

Je kent vast deze grap al over de drivers?

https://xkcd.com/1200/

Nee, die grap kende ik nog niet.

Wel ken ik auto-save-session in Gnome

ik vraag me echt af wat jij draait op ubuntu dat je x-windows nog laat crashen dat is bij mij al minstens een jaar of 5 niet meer voorgekomen (behalve dan misschien als ik zelf iets van source installeer. letterlijk alle ppa:'s die ik gebruik en alle distropackages zijn stabiel genoeg om tenminste niet dieper te crashen dan de app zelf.

volgens mij geldt dat tegenwoordig ook voor windows (10)

Nogal wiedes. Niets is onmogelijk. Waarschijnlijk een aantal fouten die elkaar versterken/triggeren.
De noodstop indrukken op een kerncentrale zou ook nooit tot gevolg mogen hebben dat de core ontploft. Toch gebeurde dat in Chernobyl. Onmogelijk zei men...totdat het gebeurt. En inderdaad, een inherente fout in de basis maakt zoiets mogelijk.

Het is natuurlijk ook geen app. De achtergrond functie zit natuurlijk in de Android software zelf.

Zelfde met chrome. Google wilt zoveel mogelijk eigen dingen maken en gemeengoed maken.

Wat mij betreft nog een reden bovenop genoeg anderen om geen chrome/google te gebruiken.

Chrome heeft zijn nut wel gehad in het begin, de browser markt stond muurvast toen en innovatie was zo goed als verdwenen.

Maar hedendaags is chrome aardig log aan het worden en irriteer ik me aan de enorme integratie met hun diensten. Bovendien heeft het geen nadelen om nu weer edge te gebruiken (is ook chromium)

Skia is een library voor 2D-graphics, geen kleurruimte. Van de website:

It (Skia, red.) serves as the graphics engine for Google Chrome and Chrome OS, Android, Mozilla Firefox and Firefox OS, and many other products.

Waarschijnlijk zit er een bug in de manier waarop Skia met die specifieke kleurruimtes omgaat.

Zover ik weet is RGB geen specifieke kleurruimte, in het gelinkte artikeltje lees ik wel wat over wide-gamut, wat dus een kleurruimte groter dan sRGB betekent. Bekende wide-gamut kleurruimten zijn adobe-RGB en prophoto-RGB.

Maar waarom dat effect zou moeten hebben op een besturingssysteem is mij onduidelijk. Het klinkt niet logisch. Misschien dat het een ongespecificeerde kleurruimte betreft?

[Reactie gewijzigd door LA-384 op 1 juni 2020 12:33]

Het lijkt te gaan om een stukje code dat een histogram maakt [1].

Daar wordt een histogram gemaakt met 256 grijstinten. Op regel 139 in de code kan dat mis gaan wanneer er meer tinten zijn dan in het histogram passen.

[1] https://android.googlesou...ageProcessHelper.java#129

[...]
Maar waarom dat effect zou moeten hebben op een besturingssysteem is mij onduidelijk. Het klinkt niet logisch. Misschien dat het een ongespecificeerde kleurruimte betreft?

Het OS zal vast wel allerlei libraries aanbieden voor het verwerken van allerlei image formaten.
Dit zodat niet elke app dit opnieuw hoeft te implementeren en ook dat het per platform geoptimaliseerd kan worden indien gewenst omdat de CPU of GPU bijv. bepaalde extra mogelijkheden biedt om dit sneller uit te voeren.

Dat dit dus op OS-niveau fout gaat, of in elk geval alleen met een OS update gefixt kan worden is niet zo gek.

De kleur-ruimte kan ervoor zorgen dat je wellicht niet helemaal precies uit komt op een veelvoud van 4 of 8 bytes en als je dan net niet genoeg geheugen alloceert kun je crashes krijgen bij specifieke afbeeldingen.
Wat ook kan is dat in de meta-data een bepaalde extensie gebruikt is die niet zo vaak voor komt en dus niet zo uitgebreid getest is.
De afbeelding openen in een foto applicatie en opnieuw opslaan kan het probleem met _die_ afbeelding wellicht ook al verhelpen, maar dat neemt niet weg dat het een bug is die alleen met een OS-update verholpen kan worden.

Maar in een nette omgeving zou enkel de achtergrond moeten crashen en niet het hele OS.

Ik kan me voorstellen dat een app die iets met deze afbeelding wil doen zal crashen.
Dat haalt niet je hele systeem onderuit.
Maar ik weet niet welk proces de achtergrond plaatst op het scherm.
Wellicht is dat iets wat op een net wat ander niveau draait dan een app.
Ik weet dat Android gebruik maakt van een 'launcher' proces. Wellicht als dat specifieke proces crasht bij boot, dat Android daarop iets anders reageert. Of misschien voorkomt een crash hiervan wel dat je door de 'inlogprocedure' heen komt en als dat een timeout geeft kan Android bijvoorbeeld uit voorzorg je mobiel herstarten.

Neemt niet weg dat dit een erg vervelende loop geeft waar lastig uit te komen is.
Mijn idee zou zijn om dit launcher proces bij te laten houden hoe vaak 'ie niet succesvol heeft kunnen starten en dan stap voor stap zaken uitschakelen om te kijken of je dan verder kunt komen.
Dit zou mogelijk ook kunnen crashen als een file niet goed gelezen kan worden of corrupt is en dan krijg je hetzelfde probleem.

Bedankt voor de interessante informatie!

Zover ik weet is RGB geen specifieke kleurruimte

Vind ik ook vaag, ik heb een item in het feedbackforum gemaakt.

[Reactie gewijzigd door 84hannes op 1 juni 2020 19:48]

Heeft Android tegenwoordig geen safe mode meer voor dit soort ongein?

Kan nog best wel tricky zijn. Heeft een safe-mode een achtergrond? En zo niet, kan je dan vanuit safe-mode makkelijk je achtergrond veranderen?

Het artikel van 9to5Google heeft een update waarin staat:

If you decide to ignore our warning and try this for yourself (seriously, please don’t), you should be able to recover your device by either resetting it completely (using the bootloader) or by entering safe mode and deleting the file from the device from there.

Dus blijkbaar is Safe Mode inderdaad een optie om het te fixen.

Ik dacht te moeilijk; gewoon plaatje deleten, je hoeft niks in te stellen. Genereert ie alsnog een fout natuurlijk - maar nu eentje waar rekening mee gehouden is.

Wie noemt zijn site nou 9to5 Google. Als ik Google was zou ik eisen dat ze per direct 24/7 Google gaan heten.

Net getest, mijn samsung S8+ heeft zelfde achtergrond als voorheen in safe mode

android heeft een safe mode, maar ik geloof dat de safe mode niet de achtergrond reset.
dan blijf je dus alsnog crashen.

Hmm, ik kan me herinneren op een HTC dat in safe mode de achtergrond een default kleur werd. Maar misschien was dat alleen als de foto op de SD-kaart stond of was dat in Android 3/4 anders dan nu. Of gewoon HTC specifiek.

Zoals hierboven al gemeld: bestand van het plaatje weghalen en je bent klaar.

De foto:
https://twitter.com/Unive...66943909499826176/photo/1

Bij instellen van deze achtergrond op mijn nexus 5x geen issues

Even de eerste reacties lezen op die tweet, uploaden naar Twitter wijzigt de colorspace met als gevolg dat het probleem niet meer optreedt.

Won't Fix (Not Reproducible)

Je bedoelt 'Fixed': https://issuetracker.google.com/issues/76022479

Uh, mijn reactie had ergens anders onder gemoeten, waar gelinkt werd naar een issue met bovengenoemde melding

Ik heb de neiging...maar probeer het maar niet.

Op Twitter had iemand de achtergrond ingesteld en was meteen verdrietig dat zijn telefoon niet meer werkte .

Maar erg mooi is het plaatje sowieso niet, vind ik.

"Google heeft nog niet op het voorval gereageerd, waardoor de achtergrond van het probleem nog niet volledig is opgehelderd."

I see what you did there!

Als je de foto laadt in Gimp stelt hij al meteen voor om het kleurenprofiel te converteren naar sRGB, nog voor hij hem op het scherm laat zien. Slimme Gimp. :-)

Hmm, toevallig dit weekend mijn Galaxy S8 opnieuw geinstalleerd. Alle apps gebackupt en teruggezet. Had na het terugzetten vrijwel een zelfde loop met een zwart blad wat steeds weer over een zwarte achtergrond schoof na 3 seconden niks doen. kon vrijwel niks doen in die korte tijd. Op een gegeven moment was het wel even spontaan weg. Vervolgens startte ik mijn Bunq app weer op en kwam het weer terug. Met veel pijn en moeite en heel snel handelen de Bunq app kunnen verwijderen. Opnieuw geïnstalleerd en geen problemen meer gehad. Dacht dat het te maken heeft met een beveiliging

Ik vind het erg bijzonder dat het instellen van een achtergrondplaatje een besturingssysteem kan laten crashen.

Een plaatje weergeven/instellen is iets dat met de allerlaagste rechten in een besturingssysteem gedaan kan worden (zou moeten in elk geval). Namelijk die van de gebruikersinterface. Hoe kan het dan zo zijn dat er een mechanisme aangeroepen wordt dat zo hoog het OS in kan, dat het hierdoor kan crashen.

Helaas zien we dat basale subonderdelen (in dit geval het onderdeel dat de achtergrondfoto instelt of weergeeft) van een besturingssysteem vaak diep ingeworteld zitten, en standaard met te veel rechten worden uitgevoerd.

Een ander klassiek voorbeeld was van ondertussen heel lang geleden. Microsoft had in de tijd van (uit m'n hoofd) Windows 2000 een keer een probleem dat je een virus in een MP3tje kon stoppen, waar Windows Media Player dan vatbaar voor was. Een MP3 hoeft helemaal niks 'uit te voeren' (geen execute-vlaggetje). Waarom kon WMP uberhaupt een MP3 uitlezen en naar aanleiding daarvan iets uitvoeren.

Het besturingssysteem crasht niet, maar de GUI. Zonder GUI heb je echter vrij weinig aan een moderne smartphone.

Heb ik nog nooit meegemaakt op mijn Pixel 2, een afbeelding die het doet crashen. Ik haal ze altijd op unsplash.

Ok

Suggereer je nu dat er ook afbeeldingen in omloop zijn die Android niet laten crashen?

En precies daarom is het nu nieuws....