Samsung en Google werken aan fix voor wallpaper-bug in Android

Samsung en Google werken beide aan een fix voor de bug die zorgt voor reboots als gebruikers een bepaalde wallpaper instellen. Volgens Google ligt de fout bij de manier waarop Android de helderheid van grijstinten berekent.

Samsung komt binnenkort met een fix, zegt SamMobile. Google zal ook met een fix komen, blijkt uit commits. Dat telefoons crashen en rebooten door het gebruik van specifieke wallpapers komt door de manier waarop Android de helderheid van grijswaarden berekent, zegt Romain Guy van Twitter.

Door een fout in de afronding komt de waarde boven het maximum uit, waardoor SystemUI crasht, omdat de software er niet mee om kan gaan. De fout blijft optreden, omdat die in de wallpaper zit en die elke keer in beeld is als gebruikers de telefoon opstarten. Terugzetten naar fabrieksinstellingen is de recovery-modus is een oplossing, maar gebruikers verliezen dan al hun data. Snel de wallpaper proberen te wijzigen is een andere optie.

Het probleem doet zich voor tot Android 10, maar zit niet in Android 11. Samsung-telefoons lijken er meer last van te hebben dan gebruikers van andere skins, zoals die van Huawei en Xiaomi. De bug kwam afgelopen weekeinde bovendrijven.

Door Arnoud Wokke

Redacteur

05-06-2020 • 08:03

22 Linkedin Whatsapp

Reacties (22)

22
21
12
2
0
5
Wijzig sortering
Het gaat heel specifiek om 1 wallpaper. Men heeft geprobeerd hetzelfde probleem na te bootsen met een nieuwe wallpaper, dit bleek nagenoeg onmogelijk te zijn. De crash ontstaat door 1 specifieke pixel in de wallpaper.

Normaal sluit Android een dergelijk proces af bij een error. Maar omdat de wallpaper daarna gelijk weer in zicht is, wordt deze weer opnieuw gestart.

Daarnaast komt het op Google en Samsung telefoons vaker voor, omdat deze beide gebruik maken van de standaard render engine van Android.

Ik vond dit zelf een hele duidelijke uitleg van het probleem:
https://youtu.be/iXKvwPjCGnY

[Reactie gewijzigd door CyberJohn op 5 juni 2020 08:27]

Interessante video, maar waarom levert de conversie van wit (R=255, G=255, B=255) dan geen error op?

0.2126*255 + 0.7152*255 + 0.0722*255 is toch ook groter dan 255?

[Edit] *als je de tussenresultaten van de vermenigvuldigingen afrond naar boven

[Reactie gewijzigd door rutgerdj op 5 juni 2020 10:24]

Duidelijk filmpje inderdaad, nice :)
Dat een simpele afronding van getallen dit kan veroorzaken
Lijkt me simpel op te lossen door te checken of de afronding groter is dan de maximum waarde, indien ja, dan is de waarde gelijk aan de maximum waarde.
In php zou dit zo zijn:
$calc=round($value)
if (round($calc)>$max){
$calc=$max;
}
:)
Lijkt me handiger om op een andere manier af te ronden ipv elke waarde te controleren.. Maar goed.
Zo simpel zou het kunnen zijn en dat is met een unit test af te vangen. Ik vermoed echter dat het component waarin de berekening gedaan wordt een andere is dan System UI (die dus crashed) en dat deze componenten niet dezelfde constraints hanteren. Dus de output van het ene component is de input voor de andere en gezien de complexiteit van een besturingssysteem zitten daar mogelijk nog andere componenten tussenin. Met een specifieke integratie test zou dit naar boven hebben komen drijven, maar dat zou wel gedetailleerd zijn voor een integratie test.
Als het zo eenvoudig is, dan is het meer waarschijnlijk dat de fout (wiskundig gezien) al eerder in de keten optreed.

Voor de snelheid en soepelheid zou je dan geen gebruik moeten maken van afronden maar van afkappen. Het zou wiskundig gezien misschien zelfs beter kunnen zijn: Als je met afronden aan de bovenkant buiten de schaal uit komt, dan kan het dus zijn dat je door dat afronden aan de onder kant van de schaal nooit op de minimale waarde komt.

Aan de andere kant begrijp ik dat het probleem ook/vooral optreed bij conversie van hdr naar niet-hdr, dus bij het aanpassen van een range, in dit geval een kleur-diepte. Misschien is er een bereik parameter verkeerd ingesteld.
Was het maar zo simpel. De fout zit namelijk in je eerste lijn. Die geeft int.max + 1 terug en gooit de fout waardoor je niet een bij je if structuur geraakt. Deze zou wel wel helpen.

try (
$calc = round($value);
} catch (OverflowException $e) {
$calc = $max;
}
Korter:

$calc = min(round($value), $max);

of

$calc = (round($value) <= $max ? round($value) : $max);

Maar als je er nou vanuit kan gaan dat die waarde nooit 255 overstijgt hoef je nooit die check te doen en spaar je 1440*2560=3.686.400 extra checks uit. Makkelijke performance gain :-)
En dan maar denken dat google of samsung de oplossingen voor hun problemen altijd hier op de deze forum kunnen vinden ...
+grappig ;) . Jammer dat we die niet meer kunnen toekennen.
Samsung-telefoons lijken er meer last van te hebben dan gebruikers van andere skins, zoals die van Huawei en Xiaomi.
Gezien de aard van de bug vraag ik mij af waarop dit is gebaseerd. Of is dit enkel gebaseerd op marktaandeel?

[Reactie gewijzigd door Caayn op 5 juni 2020 08:15]

Wat ik bij het laatste bericht al in een reactie op iemand suggereerde moet dit vrij zeker mogelijk zijn via ADB.

Ik ga het zelf niet testen maar de wallpaper wijzigen via ADB is zeker mogelijk geweest en dus misschien nog steeds :)

https://stackoverflow.com...ndroid-wallpaper-with-adb

Edit: niet als reactie op @Caayn bedoeld, sorry :)

[Reactie gewijzigd door watercoolertje op 5 juni 2020 08:20]

Dan moet je nog steeds tijd hebben tussen het rebooten door om in het slechtste geval de Developer options in te schakelen en ADB aan te zetten. Dit duurt net zo lang als een Gallery app openen en je wallpaper handmatig veranderen.

Verder laat je link naar Stackoverflow geen oplossing zien, alleen suggesties. Geen enkel antwoord is als 'juist' gemarkeerd en veel upvotes hebben ze ook niet.
Ik zeg ook niet dat het de oplossing is maar suggereer dat het een oplossing kan zijn :Y)

En je kan dat soort commando's automatiseren dus dat is sowieso sneller.
Nee, er staat "lijken". Dus dat zal eerder te maken hebben met het aantal meldingen. Als mensen met andere merken relatief weinig meldingen doen, dan weten we dus niet goed hoe veel mensen er met die telefoons last van hebben.
Waarom staat de tijd in de video eerst op 8:00 en na de reboot heel even op 7:58 en dan 8:01??
Kans is groot dat de bios-klok 3 minuten achter loopt. voor de boot is het de netwerk tijd (ntp, gsm, gps of zo iets). Bij booten wordt de bios klok uitgelezen en gebruikt tot dat het netwerk werkt en de netwerk tijd wordt opgehaald. Daarna wordt de tijd aangepast.

In de regel wordt bij het aanpassen van de tijd via het netwerk de bios klok niet altijd direct aangepast. Een afwijking van veel seconden (enkele minuten) is voor de bios klok acceptabel.

[nadere beschouwing]
In dit geval zou het goed kunnen zijn dat de plaatjes die je ziet gebufferde plaatjes zijn. Dat het beeld van het plaatje met de klok er op uit een scherm buffer komt.

In een grijs verleden heb ik wel eens gezien dat de tijd van het gsm-signaal niet helemaal perfect ingesteld staat (operator configuratie fout). Maar dat was al 20 jaar geleden. Ik ga er voor het gemak van uit dat de huidige netwerk operators de klokken wel beter synchroniseren. In 1990 konden unix en vax/vms computers al op de 0.1 seconde (en beter) gesynchroniseerd worden met ntp, ook als ze slechts af en toe via een pots/analoog/inbel-modem contact hadden.

[ extra info]
Als de bios-batterij leeg is of er geen bios klok is zoals op de raspberry-pi weet de machine dus na een boot niet hoe laat het is. Het tijdstip 0 is voor unix/linux computers 00:00 op 1 januari 1970 (utc/gmt). Voor microsoft operating systems is het 00:00 op 1 januari 1980 (lokale tijd).
Een raspberry-pi kijkt naar de schrijf-datum/tijd van een bepaalde file als ze boot. Dat gebruikt ze als opstart tijd. Die file wordt regelmatig beschreven (of met `touch`) van de huidige tijd voorzien. Dit ook om er voor te zorgen dat de boot-log-tijden niet steeds terug vallen op de zelfde tijd. Daarmee zal een RPi altijd iets terug in de tijd gaan als ze boot. Maar nooit verder terug als de vorige boot.

[Reactie gewijzigd door beerse op 5 juni 2020 10:12]

Toen ik hier voor het eerst iets over las geloofde ik het niet. Klonk als fake news. Wilde het bijna proberen...blij dat ik het niet gedaan heb ;)
Vreemd. Van de custom ROM die ik op mijn telefoon gebruik is gisteren al een update uitgebracht waar dit ook in opgelost was. Dan zou je toch verwachten dat Google en Samsung het ook al lang opgelost hadden.

[Reactie gewijzigd door MarnickS op 5 juni 2020 10:51]

Je custom rom is voor 1 specifiek toestel.
Voor Google en vooral Samsung heb je te maken met een heel leger aan toestellen.
Beetje hetzelfde als een zwakpunt in een auto aanpassen door een tuner of dat die door de fabriek of officiële dealers wordt aangepast.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee