App-ontwikkelaars stellen ranglijst agressiefste 'appkillers' op

De ontwikkelaars achter de apps Sleep As Android en Twilight hebben een ranglijst opgesteld van de agressiefste 'appkillers', besturingssystemen die agressief apps op de achtergrond afsluiten om acculading te besparen. Volgens hen is Nokia de grootste boosdoener.

Op dontkillmyapp.com zetten de ontwikkelaars uiteen wat de verschillende grote smartphonefabrikanten doen om hun plaats op de ranglijst te verdienen. Nokia bijvoorbeeld zou al na twintig minuten screen off alle achtergrondprocessen de nek omdraaien. Dat gebeurt zowel bij Android 8 als bij 9, volgens de developers. Het systeem is zo agressief dat bijvoorbeeld wekkerapps niet werken. Na Nokia zijn OnePlus en Xiaomi de grootste boosdoeners volgens de lijst, die in totaal tien namen bevat.

In een poging om niet alleen in problemen te denken, volgen de ontwikkelaars deze verhalen op met secties waarin ze uiteenzetten wat een gebruiker en wat een app-ontwikkelaar kan doen om deze problemen recht te zetten. Er kan niet in alle gevallen evenveel aan gedaan worden, maar de technisch onderlegde gebruiker kan een eind komen. Zo kan Nokia's accubesparing met een force close tot de volgende reboot worden uitgeschakeld of via ADB worden gedeïnstalleerd.

Onderaan in de lijst staan HTC en stock-Android. Deze bevatten nog steeds maatregelen om achtergrondapps de nek om te draaien, maar deze zijn zonder ingrijpende stappen uit te schakelen en de twee partijen bieden ook documentatie waarin wordt uitgelegd hoe dat moet.

Reacties (129)

[SomerenV]

Je kunt dat soort agressieve manieren om accu te besparen toch gewoon per app instellen? M'n Huawei is ook best ijverig met het afsluiten van apps die zich in de achtergrond bevinden, maar ik kan eenvoudig zeggen dat een app wél op de achtergrond mag draaien. Prima als het zo kan. Maximale accuduur maar niet het ongemak van apps die opeens niks meer doen omdat ze te lang op de achtergrond zitten.

[msx2]

Het probleem is nu juist dat dat niets uitmaakt. In het geval van Nokia (7+) kan je bijvoorbeeld alle besparingsmogelijkheden uitzetten en toch worden apps gekilled, waardoor bijvoorbeeld het nachtelijke Whatsapp back-up proces pas 's ochtends bij het ontwaken van de telefoon gestart wordt en bluetooth connecties met smart devices continu onderbroken worden.

[SomerenV]

Ja, daar heb ik dus totaal geen last van. Als ik m'n telefoon zeg dat een app zoveel mag verbruiken aan stroom als nodig dan wordt ie niet gekilled. Maar wel vreemd dat het bij Nokia dus niet goed werkt.

[totaalgeenhard]

Chrome app onder Andriod 9 heeft daar maling aan.

[RobinJ1995]

Ik ben hier ook al sinds het begin dat ik mijn OnePlus 5T heb boos over op OnePlus. Support zegt steevast "nee hoor wij hebben niks speciaals gedaan", maar ik kan bijvoorbeeld niet naar muziek luisteren terwijl Google Fit aan het tracken is in de achtergrond, want dan wordt Google Fit constant gekilled. Echt enorm vervelend en ben dus ook niet van plan nog een OnePlus-toestel te kopen. Jammer genoeg, zoals je aan die lijst wel kan zijn, zijn er niet heel erg veel opties...

Fabrikanten, blijf nou eens gewoon met je fikken van die power saving modes af. Je veroorzaakt er veel meer problemen mee dan je oplost.

[Reactie gewijzigd door RobinJ1995 op 22 juli 2024 21:36]

[blackadder91]

Ja, ik moet er ook eens achteraan gaan of ik dit nog kan optimaliseren op mijn Oneplus 3T. In de auto heb ik altijd flitsmeister en waze open staan. Dit zijn apps die normaal netjes op de achtergrond je positie bijhouden en een melding van events op de weg geven, maar mijn oneplus killed het meestal al na 5 minuten zonder melding zodat ik er niets aan heb.

[FrankReuser]

Mijn OnePlus 3T had hier ook last van inderdaad. Totdat ik in de lijst van geopende apps het slotje uitvond.
Door een app op slot te zetten kun je hem zelf niet verwijderen uit je geopende apps maar ook het systeem niet. Enige nadeel is dat je elke keer als je telefoon is opgestart dit moet doen.

[jip_86]

Heb een Nokia, maar mijn wekker doet het prima. Dat het zo erg is herken ik dus niet eigenlijk.

[aequitas]

Het is afhankelijk van hoe de wekker app werkt. Als het gebruikt maakt van de jobscheduler api (dit heeft de voorkeur) dan werkt het gewoon. Maar als de app een service gebruikt om in de achtergrond zelf de timer te laten lopen bv. Dan treedt dit probleem wel op.

Het komt omdat Android lange tijd geen goede API's had voor dit soort dingen en programmeurs hun toevlucht moesten zoeken naar dit soort methodes als background services. Ondanks dat er nu API's zijn die dit soort functionaliteit beter kunnen uitvoeren (lees, behoud van functionaliteit maar wel met goed powermanagement) zijn die dus nog niet ingeburgerd en blijf je nog lange tijd met veel slecht geschreven apps zitten die je batterij drainen.

[Cebby]

Niet helemaal waar volgens mij. Een prima API om schedules mee te maken is gewoon de AlarmManager (https://developer.android.../android/app/AlarmManager). Inplannen wanneer je iets gaat doen etc, dat is waar die voor is. Alleen niet voor taken die lang duren, dat kan wel maar dan moet je een service starten in de broadcast die je krijgt van de AlarmManager.

Goed, dat mensen dat niet snappen maakt dat het uiteindelijk minder werkt en hun eigen altijd runnende background services gaan bouwen. JobScheduler doet slim en pakt meerdere jobs samen op hetzelfde moment zonder dat 15 processen moeten checken of ze nu iets kunnen doen. Dat ze niet ingeburgerd zijn heeft er vooral mee te maken dat de API in principe API 21 of hoger is. Vandaar dat we https://github.com/firebase/firebase-jobdispatcher-android hadden en dat Google inmiddels https://developer.android...architecture/workmanager/ heeft geintroduceerd (die overigens de AlarmManager gebruikt in bepaalde cases).

Zoals ik de website nu lees zouden JobScheduler en AlarmManager allebei niet moeten werken want Nokia killt/force closed de processen en dan kun je niets meer totdat de gebruiker de app weer heeft geopend.

edit: Als het een goede wekker app is zou ie de AlarmManager moeten gebruiken trouwens (zie ook McBacon in 'nieuws: App-ontwikkelaars stellen ranglijst agressiefste 'appkill...). Je wilt namelijk dat je wekker afgaat om 9:00 en met de JobScheduler gaat je dat echt niet lukken. Zelfs AlarmManager is niet volledig exact meer tenzij je dat expliciet aangeeft. Dat de wekker niet werkt heeft er dan waarschijnlijk puur mee te maken dat ie geen broadcasts meer ontvangt omdat ie gekillt is.

[Reactie gewijzigd door Cebby op 22 juli 2024 21:36]

[jhnddy]

Grappig, ik had een externe wekker app, en sinds de laatste update van mijn Nokia 8 werkt deze niet meer. Ik weet nu dus ook waarom: het is een wat oudere app die waarschijnlijk nog gebruik maakt van een oude API.

Bedankt voor de goede uitleg!

Overigens is het voor mij een stuk prettiger dat applicaties automatisch worden gekilled. Ik had jarenlang al problemen met matige accuduur, voornamelijk door applicaties die op de achtergrond continu doordraaien.

[Cebby]

Het heeft eigenlijk vooral niet te maken met de API die gebruikt wordt, heb nog even wat verduidelijking toegevoegd.

[itContinues]

Is jouw wekker een externe app of de ingebakken wekker. De ingebakken wekker heeft hier volgens mij geen last van nml.

[McBacon]

Ligt er maar net aan wat de app developer ervan heeft gebakken (Android docje: https://developer.android...device-state/doze-standby):

• Standard AlarmManager alarms (including setExact() and setWindow()) are deferred to the next maintenance window.
• If you need to set alarms that fire while in Doze, use setAndAllowWhileIdle() or setExactAndAllowWhileIdle().
• Alarms set with setAlarmClock() continue to fire normally — the system exits Doze shortly before those alarms fire.

Ik gebruik zelf ook Alarm Clock Xtreme en deze gaat netjes iedere morgen af. Je kunt voor Doze (vaak) nog wel e.e.a. handmatig whitelisten, maar verschilt beetje per fabrikant. Ik kan bijv. in mijn settings (Nokia 6.1) naar Battery gaan en daaronder de opties "allow process to run in background" en "don't optimise battery usage" instellen per (userland) app.

[Reactie gewijzigd door McBacon op 22 juli 2024 21:36]

[24shure]

Ik heb ook een Nokia (6.1 Plus) en gebruik een externe wekkerapp (Alarmy) en mijn wekker gaat elke ochtend gewoon af.

Wat ik wel merk is dat wanneer ik snachts een bericht via bijvoorbleeld Messenger ontvang, dat sochtends deze melding verdwenen is. Als ik op deze manier een melding zou ontvangen van een weinig gebruikte app, zou ik deze wel eens kunnen missen.

^{Edit: Telefoon-type toegevoegd.}

[Reactie gewijzigd door 24shure op 22 juli 2024 21:36]

[airell]

Op mijn Nokia 6.1 wordt na x minuten (zou best 20 kunnen zijn) Flitsmeister afgesloten als Android Auto op de voorgrond draait. Flitsmeister gaat automatisch aan bij een Bluetooth verbinding, maar gaat dus 'zomaar' weg.

[Causs]

Ik heb een Nokia ( 8 ) en maak gebruik van een externe wekker (Alarm Clock Xtreme). Deze wordt niet automatisch afgesloten.

[Reactie gewijzigd door Causs op 22 juli 2024 21:36]

[!mark]

Gebruik je de wekker/klok app die meegeleverd is met je apparaat of een derde uit de Play Store?

Meegeleverde apps worden waarschijnlijk uitgezonderd

[jip_86]

Timely gebruik ik

[Geerbeer94]

Waarom zou je een third party app gebruiken? Wat heeft een andere app dat de ingebouwde alarm niet heeft? Ik ben gewoon benieuwd

[michaelkamen]

Ik gebruik Timely ook. Naast het feit dat de app er gewoon prachtig uitziet (het oog wil ook wat ) kan je bijv. instellen dat je eerst een puzzel moet oplossen of een patroon moet invoeren voordat je het alarm kunt uitschakelen. (voor de mensen onder ons die de neiging hebben om het alarm uit te zetten en dan verder te slapen )

[Geerbeer94]

(voor de mensen onder ons die de neiging hebben om het alarm uit te zetten en dan verder te slapen )

Ik ben er ook zo één, alleen hoor ik mijn hele telefoon niet... Dus zo'n puzzel functie heeft helaas ook geen nut. Ik heb een wekker die de rest van het huis ook wakker maakt waar ik doorheen kan slapen

[jip_86]

In mijn geval instelbare snoozeduur, snoozeduurverkorting en grapjes om niet zo maar snooze in te kunnen drukkken. Echte wekker voor (te) luie tweakers dus

[Frenziefrenz]

Dat ligt eraan welk alarm er bij jou ingebouwd zit natuurlijk, maar vooral voor herhalende wekkers (bv. elke ochtend om 6u45) is dismiss zonder het alarm uit te hoeven zetten enorm handig.

[Xm0ur3r]

De stock wekker doet het ook prima,

Ik heb ook een Nokia 6.1 (2018) en het is wel degelijk een probleem met andere apps zoals inderdaad sleep as android, het werkte prima toen ik hem had toegestaan in adaptive battery voor android 9, maar sinds android 9 heeft die er ook schijt aan en wordt regelmatig wakker door de stock (backup) wekker.

Volledige reset heb ik nog niet geprobeerd, even tijd voor maken.

[Zoidberg_AvG]

Staat sleep as android in je Restricted App list? (instellingen >> batterij >> Aanpasbaar batterijbeheer)

Heb dezelfde telefoon, en had problemen dat VLC vanzelf afgesloten werd, dit probleem was opgelost nadat ik de app uit de Restricted App list heb gehaalt.

[Xm0ur3r]

Sorry dat bedoelde ik in eerste instantie ja, staat erin als toegestaan en dat werkte prima voor 9 maar daarna is het problemen gaan geven, maar misschien werkt een factory reset wel.

[Adanteh]

Hier ook een Nokia 6.1 en mijn Sleep as Android werkt ook niet. Zal nog wel even kijken of het valt op te lossen, hoewel ik de app sowieso bijna niet meer gebruik. Twilight is ondertussen ook bijna volledig vervangen door de standaard night light, omdat hij steeds slechter werkt bij nieuwere android versies, maar die standaard night light valt bijna niet in te stellen.

Valt me sowieso op met Android de laatste tijd, steeds meer problemen met third party applicaties, en de ingebouwde varianten zijn veel te beperkt, vooral qua instellingmogelijkheden. Kom van jarenlang Miui af en had je nette themas, in de laatste Android (stock) versie kan je niet eens je menu's op donker in stellen, en LineageOS schijnt niet echt een mogelijkheid te zijn op de Nokia 6.1 (Bij mij werkte de HMD bootloader unlock in ieder geval niet).

[Reactie gewijzigd door Adanteh op 22 juli 2024 21:36]

[Mavamaarten]

Nja, het is zo simpel niet. Nokia heeft wel een whitelist voor de meegeleverde apps die van alarms afhankelijk zijn. Maar third party apps worden gewoon gekilled in de achtergrond, no matter what.

[Tjark]

Nokia's eigen wekker doet 't natuurlijk wel. Maar een 3rd party app/wekker?

[hellfighter87]

Zelfde hier, al denk ik dat het hier gaat om aparte android apps die in wekker functionaliteit voorzien.
Kan me voorstellen dat die wel de nok om gedraaid worden.

[Anoniem: 1128097]

Voldoe je aan de versies? etc etc, hoop variabelen,

https://dontkillmyapp.com/nokia

[Vinny_93]

Ik heb een Nokia 8, mijn wekker doet het prima, maar ik moet wel zeggen dat apps vrij snel vergeten waar ik gebleven was. Het enige waar ik me echt aan stoor is dat als ik op Discord zit, hij me gewoon disconnect na een tijdje. Dit is op te lossen door bij developer options in te stellen dat het scherm aan blijft tijdens het laden, aan de lader leggen en Discord open te houden.

[11supplier]

Begrijp het dilema maar transparante setting zijn echt nodig.

Mijn Nokia killed onder andere mijn tetering na inactiviteit. Deze tetering heb ik nodig voor mijn TomTom. Ofterwijl als ik op de weg zit heeft mijn TomTom plots geen file informatie meer (ja ik weet het tetering is geen echte app, maar volgt dezelfde principes). Het tetering weer aanzetten kost meerdere complexe handelingen (dus onveilig), maar als ik het niet doe is er natuurlijk net altijd toevallig file .

Ook Runkeeper wordt standaard na 30 minuten afgesloten. Helaas is een halve marathon binnen 30 minuten voor mij te ambitieus en mis ik dus een groot deel van mijn run. Erg jammer als je net een PR rent.

Natuurlijk is er goed als er wat aan gebeurt dat je flashlight app op de achtergrond al je data verzameld en doorstuurt, daarom lijkt mij transparantie en inzichtelijkheid belangrijk. Even een bericht van "Heej ik heb deze app afgesloten ivm batterij. Wil je dit in de toekomst voorkomen klik hier zou het een stuk mooier maken".

[Reactie gewijzigd door 11supplier op 22 juli 2024 21:36]

[84hannes]

ven een bericht van "Heej ik heb deze app afgesloten ivm batterij. Wil je dit in de toekomst voorkomen klik hier zou het een stuk mooier maken".

Het fijne aan moderne ecosystemen is dat resourcemanagment niet langer een taak van de gebruiker is. Je browser afsluiten als je een computerspel gaat spelen? Niet nodig op een modern besturingssysteem, daar zorgt het OS wel voor. Door de gebruiker nu met dit soort vragen lastig te vallen leg je verantwoordelijkheid weer bij de persoon die er in jouw geval misschien geschikt voor is, maar meestal niet. Een gebruiker zou zich er ook niet druk over hoeven te maken. Een betere oplossing is volgens mij een goed event-trigger framework. Ja, de wekker wordt afgesloten als je de app 20 minuten gesloten hebt, maar voordat hij dat doet stopt hij een trigger op de event-trigger stack: zodra het 7:59 uur is wordt de app weer gestart en kan deze zich klaar maken om om 8:00 uur te gaan piepen. Jouw TomTom zou afgesloten worden, maar er zit een event-trigger op de stack die aangeeft dat hij weer getriggerd moet worden als de GPS locaties meer dan 50m van de huidige locatie verschuiven. Dat gebeurt zo snel dat er elke minuut wel een paar events zijn het Android het proces maar niet afsluit zolang er andere opties zijn.

Het is maar een idee dat ik in vijf minuten bedenk, er zijn vast veel mooiere oplossingen, maar de eindgebruiker als systeembeheerder aanstellen lijkt me niet de beste.

[Stoelpoot]

Als gebruiker van onder andere Sleep as Android zou dit idee echter niet werken. Sleep as Android meet je activiteit terwijl je slaapt, dat is dus constant.

[84hannes]

Sleep as andorid meet je activiteit, die activiteit zou dus een event-trigger zijn.

[Stoelpoot]

En om een event-trigger op activiteit te hebben, moet je app actief zijn, waarvoor je een event-trigger nodig hebt, waarvoor je app actief moet zijn om te meten... Of zou elke input een event-trigger zijn wat enkel door de fabrikant geoptimaliseerd kan worden?

[Croga]

Nee hoor. Om een event trigger op activiteit te hebben hoeven alleen de sensoren van je telefoon actief te zijn.

Als jij een gyroscoop in je telefoon hebt (nagenoeg alle moderne telefoons hebben dat) dan wordt deze door het OS uitgelezen. Het OS geeft deze informatie weer door aan alle apps die die info willen hebben. Wat je in dit geval dus doet:
- App in slaap gooien
- Event trigger op de gyroscoop
- Gyroscoop triggered het event op OS niveau
- OS haalt app uit slaap en geeft gyroscoop data door

Hiermee kun je dus rustig alle apps uit het geheugen gooien en deactiveren om batterij te besparen totdat zich een event voordoet waar de app op geaboneerd is. De app hoeft niet actief te zijn om het event te triggeren; dat gebeurt op veel lager niveau.

[Adanteh]

Dan kom je uiteindelijk op een 'event' uit voor letterlijk alles. In het Sleep as android geval bijvoorbeeld dus ook al de microfoon. Krijg je dan een "Er is geluid" event? Of misschien "Er is geluid boven db-niveau X"? Misschien snap ik niks van het hele systeem, maar ik zou het fijner vinden als ik battery management voor een bepaalde applicatie 100% uit kan zetten, zonder eerste meerdere menus door te moeten.

Zelfde ervaring had ik toevallig met SkiTracks afgelopen week, gebruik ik al jaren maar met mijn Nokia 6.1 schakelde hij automatisch uit als ik de eerste X minuten geen bereik had via GPS, met mijn vorige xiaomis nooit last van gehad. (Bij de gondel in het dal zet ik hem aan, maar is een groot betonnen gebouw, dus als je even moet wachten dan zet hij hem meteen weer uit). Of dat een fout is van het OS dat misschien de GPS uit zet, of van SkiTracks weet ik niet, maar als eindgebruiker maakt me dat eerlijk gezegd helemaal niks uit.

[84hannes]

maar als eindgebruiker maakt me dat eerlijk gezegd helemaal niks uit.

Precies dit: de eindgebruiker moet gewoon een werkende app hebben zonder zelf in te hoeven stellen welke app welke prioriteit krijgt, of hij wel of niet in de achtergrond mag draaien etc.

[Croga]

Dus een event trigger op activiteit en je app gaat nooit meer afgesloten worden.....

[84hannes]

In tegendeel: een event trigger op een activiteit, en de app kan rustig gesloten worden totdat de activiteit plaatsvindt (het event getriggerd wordt). Volgens mij werken background services al op zo'n manier. Natuurlijk kan een app het misbruiken, maar dan moet je die apps afrekenen op hun slechte gedrag.

[Stoelpoot]

Zie m'n reactie hier ook, gaat in op hetgeen wat je zegt.. Ik kan 'm wel knippen / plakken, maar dat staat ook zo lullig.

[11supplier]

Ik vraag me af of je dit puur vanuit het besturingssysteem kan oplossen.

Een app die resources op de achtergrond gebruikt kan daar een goede reden voor hebben of niet. Runkeeper mag op de achtergrond mijn data verzamelen en de zaklamp niet.

Je mag beide apps niet hetzelfde behandelen, ook al doen ze technisch misschien hetzelfde. Dan is de vraag of Nokia vanaf bovenaf deze beslissing moeten maken (gaat nu dus niet zo goed) of dat ik er als gebruiker ook wat van mag vinden.

[j1b2c3]

Je kunt het ook omdraaien Nokia helpt jou toestel de batterij te besparen. Ik heb jaren mijn Sony in power saving mode staan en de stand-by tijden gaan er echt gigantisch op voor uit. Mijn tablet kon een week stand-by halen. Ik hoef geen notificaties als ik mijn telefoon niet gebruik.

[84hannes]

Dat Nokia jouw dubieuze zaklamp-app na 20 minuten sluit is natuurlijk geen veiligheidsmaatregel. Ik zou bijvoorbeeld niet inzien waarom het okay is dat de app die gegevens verzameld zolang de zaklamp brandt, dan nog eens 20 minuten, maar daarna opeens niet meer. Daarvoor heeft Android een permission-systeem, en dat zou ik buiten dit onderwerp houden.

Runkeeper heeft toestemming om jouw bewegingsactiviteiten te meten en kan dus een event-trigger aanmaken door deze activiteiten. Als jij jouw zaklamp-app toestemming geeft je bewegingsactiviteiten te gebruiken dan kan Nokia jouw niet redden.

edit:
nog even een seconde extra nagedacht

Er zijn zaklampapps die opstarten als je je telefoon schudt. Die zouden wellicht toegang tot dezelfde activiteiten willen hebben, en deze dus ook kunnen tracken. Het na 20 minuten sluiten van deze zaklampapp gaat dus ook een slechte gebruikerservaring opleveren.

[Reactie gewijzigd door 84hannes op 22 juli 2024 21:36]

[11supplier]

Fair enough, eens dat Nokia niet al het misbruik van mijn zaklamp-app moet oplossen, maar denk dat hier wat nuance in zit.

De status quo is dat internettoegang geen 'permission' is, maar standaard. GPS toegang wel, maar als je gebruikers niet vertrouwend om te beslissen over wat wel en niet automatisch moet sluiten, je ze ook niet kan vertrouwen om GPS permissions goed te zetten. De enige oplossing is om de apps top-down te controleren voordat ze in de shop komen.

Ik kan komen in je trigger-systeem voor veel apps, maar voor sommige apps minder geschikt. Runkeeper en sleeptrackers worden door alles getriggerd (beweging, geluid, GPS) dus kunnen net zo goed standaard aan staan... of in ieder geval vanaf het moment dat je 'track activity' doet. Een aparte permission voor "running on background" lijkt me hiervoor ook niet een slechte oplossing. De ontwikkelaar kan nu automatisch afsluiten voorkomen door het scherm aan te laten staan, mij lijkt dat je hier een ontwikkelaar meer tools voor kan geven.

[Reactie gewijzigd door 11supplier op 22 juli 2024 21:36]

[eric.1]

In principe bestaat dit al in de vorm van een soort scheduled tasks: Alarm Manager, Job Scheduler, Evernote-Jobs of Work Manager. Dit werkt allemaal buiten jouw eigen applicatie-lifecycle om en is dus in staat om jouw applicatie te "wekken". Zo kan je zelfs een oneindige service maken.

[borft]

Is er geen manier om apps te whitelisten? Mijn OnePlus heeft dat wel, ik nam eigenlijk aan dat het standaard Android functionaliteit was. Apps mogen beperkt in de background draaien, tenzij de gebruiker anders aangeeft.

[Shannara]

Ik heb zelf ook een OnePlus (5) maar helaas is dat geen garantie. Ik heb een aantal apps die ik inderdaad zou willen whitelisten, maar bij sommige wordt dit regelmatig gereset. O.a. na een update van de betreffende app.
Dit is een bekend en erg irritant probleem bij OnePlus. Zoek maar eens op het OnePlus forum.
En het staat ook op: https://dontkillmyapp.com/oneplus

[borft]

hmm vreemd, ik heb het nog nooit gehad. In ieder geval, de manier waarop je het uit moet zetten volgens de "dontkillmyapp" website klopt in ieder geval niet. Je moet op het slotje klikken in de app overview. Dan wordt de app niet gekilled.

[cmwmobile.com]

Mijn ervaring is dat je app gewoon blijft werken zolang je je maar aan de Android specificaties houdt. Het is wel zo dat die zo nu en dan strenger worden.

[jeroen3]

Best wel veel strenger eigenlijk. https://developer.android.com/guide/background/

Vroeger foeterde iedereen op Apple omdat apps gewoonweg niet in de achtergrond konden draaien. Toen werd dat omzeilt door locatievoorzieningen. Iedereen prees android de hoogte in omdat het daar wel kon.
En nu breken ze deze feature langzaam weer af.

Ik zou wel eens willen weten of dit nu voornamelijk komt omdat de Appdevs zich niet aan de bovengenoemde regels houden, of dat telefoonfabrikanten maar met de bijl te werk moeten gaan omdat de toestellen eigenlijk gewoon teveel energie verbruiken.

[Anoniem: 457607]

Op Android was het volgens mij broodnodig. Een jaar of 5 geleden had ik een Android tablet met slechts enkele apps erop. Ik gebruikte deze tablet nauwelijks maar moest hem voortdurend opladen omdat zelfs met niets doen zo'n 30 a 40% van de charge leegliep per dag. Inmiddels is dat een stuk beter, op nieuwere versies van Android.

[cmwmobile.com]

Ze breken het niet af maar leggen wel meer regels op waar je je aan moet houden.

[himlims_]

toont dit niet een 'dieper' android probleem aan; resource geile apps, en RAM-hugging diensten?

[aryan1171]

Nee niet echt. Het betekent meer dat merken als Nokia liever apps killen op de achtergrond dan dat ze extra moeite steken in het efficienter maken van hun procéde. Nou weet ik dat Nokia in dit geval vrij weinig te maken heeft met de efficientie van het Android platform maar dat betekent zeker niet dat het okay is om gewoon lui te doen en de gebruiker op nummer twee te zetten. Dit merk ik zowiezo heel erg met elektronica tegenwoordig. De gebruiker/consument staat tegenwoordig op nummer twee en wij moeten ons maar aanpassen aan het gedrag en overregulering van bedrijven en instanties:

- Volume waarschuwing die niet uitgezet kan worden en mensen dwingt elke dag hun telefoon uit hun zak te halen om het goed te keuren.
- Besturingsystemen die controle van gebruikers afpakken en updaten/herstarten.
- Opties waar men veel gebruik van maken worden verwijderd waardoor makkelijke zaken in eens veel moeilijker worden.
- Hardware dat verwijderd wordt en waar men vervolgens de meest achterlijke redenen voor opgeeft (headphone jack)

Ik denk dat we dagelijks tegen dingen aanlopen waarvan we denken "dit doen ze express" of "hier is niet over nagedacht".

[RJG-223]

Het betekent meer dat merken als Nokia liever apps killen op de achtergrond dan dat ze extra moeite steken in het efficienter maken van hun procéde

Ik denk dat telefoonmakers hun gloeiende best doen, waar ze kunnen. Want als de batterijduur niet goed is, dan klagen de gebruikers, of krijgen ze een slechte review.. Maar 1000 telefoonmakers kunnen niet op tegen één beroerde app die continu CPU-tijd vreet. Denk jij nu echt dat app ontwikkelaars allemaal hoogopgeleide professionals zijn die alle APIs kennen als hun broekzak, en altijd hun best doen om de meest efficiënte apps te schrijven ? Integendeel. Heel veel cowboy-bedrijven die met beperkt budget en relatief laag betaalde ontwikkelaars apps in elkaar flansen. Die gebruiken voornamelijk de APIs die ze kennen, zelfs al zijn die voor bepaalde doeleinden inefficiënt, besteden weinig tijd aan optimaliseren, want dat kost geld, en levert niets op.

Om nog maar niet te spreken van apps die expres in de achtergrond data verzamelen om aan de data-honger van de makers te voldoen. Dat kost ook processortijd.

Gebruikers laten te veel onnodige apps draaien, en veel apps zijn ook onnodig inefficiënt. En dan klagen de gebruikers dat de telefoon een slechte accuduur heeft, terwijl het dus hun eigen schuld is (teveel apps, 'foute' apps). Als telefoonfabrikanten dan veel moeite gedaan hebben om de telefoon efficiënt te maken, en zien dat het resterende accuduur-probleem voornamelijk ligt aan de apps, dan gaan ze daar wat aan doen. En dus maken ze een appkiller. Dat kost extra moeite, en dat doen ze echt niet om de gebruiker dwars te zitten. Ze kunnen hun geld wel beter besteden. Dat doen ze omdat de gebruikers klagen over accuduur zonder de hand in eigen boezem te steken.

Nou zou ik zelf zeggen, dat ze beter een app kunnen maken 'waarom is mijn batterij nu weer leeg', die laat zien welke apps per uur en/of per dag veel stroom gebruikt hebben. Dan kan de gebruiker zelf beslissen wat hij daarmee doet. En dan hebben app-ontwikkelaars ook een reden om apps te optimaliseren. En dan krijgt de telefoonmaker ook niet onnodig de schuld.

• Volume waarschuwing die niet uitgezet kan worden en mensen dwingt elke dag hun telefoon uit hun zak te halen om het goed te keuren.
• Besturingsystemen die controle van gebruikers afpakken en updaten/herstarten.
• Opties waar men veel gebruik van maken worden verwijderd waardoor makkelijke zaken in eens veel moeilijker worden.
• Hardware dat verwijderd wordt en waar men vervolgens de meest achterlijke redenen voor opgeeft (headphone jack)

Deze argumenten heben helemaal niets te maken met het afsluiten van apps om stroom te besparen, of met inefficiënte apps. Volkomen off-topic dus.

[Reactie gewijzigd door RJG-223 op 22 juli 2024 21:36]

[WillySis]

Android heeft zelf wel degelijk een aantal "functies" waardoor je kan stellen dat het batterijgebruik niet helemaal onder controle is.
Android heeft niet eens een functie om app geheel af te sluiten. Via een omweg kan het (schijnbaar) wel, door eerst naar de lijst met actieve apps te gaan. Als ontwikkelaars willen kan een app daarna nog steeds gewoon actief blijven.
Ook is het niet inzichtelijk hoeveel en welke apps bij het opstarten al heimelijk worden gestart om de push-berichten door te geven. Een aantal apps kijkt zelfs met enige regelmaat even op een server of er nog een nieuw bericht klaarstaat. Al die activiteiten worden via systeem onderdelen uitgevoerd en zijn daardoor niet afzonderlijk terug te vinden.

Als je een app-killer installeert weet je wat je doet. Bij de betere kan je ook een white-list opstellen voor apps die je nooit af wilt sluiten. Als fabrikant al een standaard app-killer in de eigen software-schil opnemen is natuurlijk niet netjes en kan net als een snel leeg rakende accu voor slechte reviews zorgen. Als de app-killer standaard uit staat en je zelf per app kunt instellen of die moeten worden afgesloten of niet, heb ik er niet zoveel bezwaar tegen.

Het zou veel mooier zijn als Google een functie inbouwt waarmee de ontwikkelaars kunnen bepalen hoe een app moet worden afgesloten. Dat kan zijn naar de app-list om na een bepaalde tijd geheel afgesloten te worden, direct helemaal afsluiten of actief blijven. In het laatste geval zou het handig zijn als je daar ook netjes toestemming voor moet geven.
Een aantal app's gebruikt nu een tussenoplossing door in het meldingen scherm een optie op te nemen om de app helemaal af te sluiten.

[Propane]

En als ze het niet doen klaagt diezelfde gebruiker over hoe slecht de batterij in de nieuwste Nokia wel niet is of dat er battery drain is zonder te beseffen dat één of andere kneuter app dat veroorzaakt.

Uit je lijstje is de volume waarschuwing ook wel weg te strepen, want als ze het niet doen krijg je weer 'gebruikers' die de fabrikant ergens voor de rechter slepen na gehoorschade ofzo.

Ben het wel deels met je eens, maar ik kan de andere kant van het verhaal ook wel zien. De enige manier waarop een fabrikant een bepaalde ervaring kan garanderen is soms om de controle daarover zelf in handen te nemen/houden.

[timmiej93]

Dit dus inderdaad. Nu valt het in Nederland misschien nog mee, maar vooral in Amerika wordt je als fabrikant gewoon voor de rechter gesleept als je niet overduidelijk aangeeft dat je sommige dingen niet moet doen, of niet voldoende waarschuwt, en helaas krijgt de klager in veel te veel gevallen nog gelijk ook. Wat voor een opties heb je dan als fabrikant nog? Zelfs al zet je in de gebruikershandleiding een waarschuwing voor een te hoog volume met oortelefoons, dat wordt dan in de rechtszaal alsnog afgedaan als "niet voldoende gewaarschuwd", al dan niet terecht.

[holoduke51]

Daarnaast wordt whitelisting gebruikt om hun eigen apps (of partner apps) wel gewoon te laten werken. Oneerlijk

[Militia Pilot]

Heb je daar een bron voor?

[holoduke51]

Ja hier is eentje
https://www.google.com/ur...UPhpHYLqzsyFyZSTE&ampcf=1

En

https://www.google.com/am...all_log_permissions/eruit het meest schrijnende geval. Bepaalde third party tooling apps waaronder een paar zeer populaire kunnen niet langer meer werken. Systeem apps plus paar gewhiteliste dus wel.

[Reactie gewijzigd door holoduke51 op 22 juli 2024 21:36]

[aryan1171]

Daar heb je geen bron voor nodig. Systeem apps hebben zowiezo meer rechten op permissies en systeemtijd. Het is dan alleen maar logsich dat een systeemapp niet wordt afgesloten.

[NC83]

Is ook niet raar dat ze dat hebben, os maker/hardware vendor weet precies wat die dingen doen. Andere partijen kan en wil je niet vertrouwen. Ik vind het juist goed dat het OS gewoon hardcore een app killt. Daarnaast hoort een applicatie permissie te vragen of het in de achtergrond dingen mag doen, en niet gewoon dom weg door het systeem worden toegelaten.

[holoduke51]

Nee het is niet eerlijk. Misschien voor jou als consument maakt het niet uit. Voor bedrijven die producten maken is dit een zeer oneerlijke situatie. Bepaalde apps als Facebook, Whatsapp etc krijgen door fabrikanten voorrang. En op die manier wordt het voor concurrentie vrijwel onmogelijk om een vergelijkbaar product te maken.
Dit probleem is de laatste tijd meer voorgekomen. Sms uitlezen voor apps is bijvoorbeeld ook met een whitelisting. Hetzelfde geldt voor push notificaties die alleen via firebase kunnen lopen. Er zijn hoop partijen benadeeld en een aantal zijn verdwenen.
Het jammere is dat de onwetende consument hier geen benul van heeft en zelfs denkt dat het goed is. Uiteindelijk is dit dus niet zo. Huidige situatie zorgt ervoor dat grote partijen nog groter worden en kleinere of nieuwe partijen verdwijnen. Erg jammer

[NC83]

Je leest over wat ik wil ik wil die keuze maken of die dingen in de achtergrond mogen draaien of niet. Ik wil dit helemaal niet aan de fabrikant of app maker over laten, ze moeten me er expliciet om vragen of ze daar mogen draaien. Hierdoor heeft niemand meer voordeel behalve de consument die dan bewust een keuze maakt of een applicatie, wel batterij of data mag gebruiken als de telefoon in standby staat.

[Miglow]

Maar als ik naar de radio wil luisteren op de motor, wordt de app dus na 20 minuten gekilled, terwijl Spotify rustig de hele dag kan blijven spelen... En dan kun je zeggen, luister dan naar Spotify, maar ik wil soms gewoon radio luisteren.

[Xorgye]

Je kunt op 2 manieren een langere tijd garanderen op een telefoon: de hardware of de software.
Je ziet dat langzamerhand men (android, de fabrikanten) zich op de software gaan richten als zijnde de boosdoener. Dit is omdat er langzamer vorderingen gemaakt worden met accu's maar de klant wel elke release spectaculaire verbeteringen verwacht.

Ja er zijn problemen met resource geile apps en ram hugging diensten. Maar er moet een keuze zijn voor de ontwikkelaar en de gebruiker om daar iets aan te doen.
Bijvoorbeeld als je een bepaalde app (neem flitsmeister, google maps, of een corporate app op een corporate telefoon) belangrijk vind en het je waard is dat die app je telefoon minder lang mee laat gaan.

[divvid]

Dit komt natuulijk door de perceptie van de fabrikanten dat telefoons alsmaar dunner moéten worden. Geef de gemiddelde belmiep de keuze, telefoon twee mm dikker, maar wél kunnen appen óf super dun ding, maar snel leeg....
Nu zie ik regelmatig mensen met powerpacks in de weer. Draadje uit de rugzak enzo, omdat anders hun telefoon weer eens leeg is.
Zelf heb ik zo'n Wakawaka light in gebruik. Ooit gekregen als gadget, maar super handig op lange wandelingen.

[Anoniem: 951889]

Helemaal dit. Ik zag laatst bijvoorbeeld dat spotify 2% van mijn accu had gebruikt sinds de laatste laadsessie - ik zat op 86% en heb spotify niet gebruikt, en had hem gekilled na het laatste gebruik.

Heel jammer, want wat moet een muziekstreaming dienst op de achtergrond doen wanneer je geen muziek luistert? (Ik had ook geen lopende downloads!)

[borft]

Hmm, lijkt erop dat ze hun fact checking niet helemaal voor mekaar hebben. Ik heb een OnePlus, en ik kan gewoon instellen dat een app niet gekilled wordt, ook niet in de background, ook niet als het scherm uitstaat, kwestie van op het slotje bij een app killen. Ik vind het eigenlijk wel prima werken. Voor de meeste apps maakt het namelijk niet uit of ze suspended worden of niet. Alleen bij streaming apps, of bv GPS trackers is het onhandig, dus voor die apps pas je het simpel aan.

[herofruit]

Het lijkt erop dat jij je fact (en spell) checking niet voor elkaar hebt. Als je verder leest staat er voor OnePlus duidelijk dat:

Not only did users need to enable extra settings to make their apps work properly, but those settings even get reset with firmware update so that apps break again and users are required to re-enable those settings on a regular basis.

Bron

Ik heb ook een OnePlus en ervaar bovenstaande wel degelijk.

Voor de duidelijkheid, het gros van de gebruikers heeft geen idee van deze processen (laat staan opties om deze aan te passen) maar ervaren wel alle problemen die er mee gepaard gaan.

[Reactie gewijzigd door herofruit op 22 juli 2024 21:36]

[borft]

Bij mij wordt niets gereset bij firmware updates. Ik heb bv ingesteld dat Strava moet blijven draaien, meer dan een jaar geleden, sindsdien een stuk of 20 firmware updates gehad en het werkt nog steeds prima.

Dat mensen niet doorhebben dat je op het slotje moet klikken om een proces te locken is inderdaad minder handig. Maar het voordeel is wel, het geeft controle aan de gebruiker, ipv dat alle apps gewoon blijven draaien, met alle ingebouwde tracking rommel erbij.

<off topic>
mekaar is een synoniem (weliswaar informeel) voor elkaar

[OmgItsKoen]

Waarom commentaar leveren op @borft zijn spelling? Nergens voor nodig, hij geeft alleen zijn mening.

[B127]

Het probleem is niet dat je het niet aan kan passen, maar dat standaard alles uiteindelijk gesloten wordt. (mijn xiaomi doet min of meer hetzelfde)

[Reactie gewijzigd door B127 op 22 juli 2024 21:36]

[borft]

Ik kan het prima aanpassen. Als je in het app overzicht op het slotje klikt, blijft de app gewoon draaien. Werkt prima voor apps als Spotify, Strava, etc. die blijven gewoon uren draaien, zonder dat het scherm aan is.

[Sinnergy]

Zelfde bij Samsung, en toch 'stopt' Pushbullet regelmatig met werken tot ik 'm nog eens ff focus geef...

Wat je ziet en wat je krijgt is niet altijd hetzelfde

[temp00]

Als ik naar https://dontkillmyapp.com/ ga, is het eerste wat ik lees dit:
Don't kill my app!
Smartphones are turning back into dumbphones. We have to fight back!
Gevolgd door ratings per fabrikant in de vorm van een turd-icoontje.
Niet echt iets om serieus te nemen. Persoonlijk vind ik het helemaal niet erg dat fabrikanten agressief/serieus met achtergrond apps omgaan. Een telefoon is nou éénmaal geen pc en wat mij betreft kan het wel wat minder met apps die altijd op de achtergrond met iets bezig zijn.

[Xfade]

Maar jij wilt toch ook dat je direkt een notificatie krijgt van je mail en je whatsapp en niet een uur of wat later als je dan maar handmatig die app opent? Dat is het hele punt. Door die battery management en andere meuk kan het zijn dat je apps gewoon niet meer geconnect zijn. Toch jammer als je zus vraagt of je even langs kan komen maar je krijgt het bericht pas 2 uur later als je zelf iemand een bericht wil sturen.

[DutchKevv]

Ha! Ik merk dit constant met Flitsmeister. Als ik Google maps op de voorgrond zet, word Flitsmeister gekilled (op Nokia)

[airell]

Yep, same here. Je zou Flitsmeister onder de batterij instellingen bij de Restricted Apps kunnen zetten, maar ik heb nog steeds het idee da FM zomaar ineens verdwijnt. Als FM dan weer eens 'hé Bleutooth' ziet, sprint hij weer aan (op de achtergrond met dan piep-piep geluid).

[SanderBos]

Ik vind de OnePlus manier (GUI) hiervoor in ieder geval niet geweldig. Dus het slotje activeren in recent apps.
"Je wil dat een proces op de achtergrond blijft draaien? Prima, mag, maar dan moet die app wel in je recent app lijst blijven staan"
De lijst van apps processen waar OnePlus met z'n tengels af moet blijven zou los moeten staan van wat ik tijdens apps switchen tegenkomt (zoals Android's eigen donotoptimize lijst er los van staat), zeker aangezien de meeste dingen die je niet gekilled wilt hebben juist achtergrond processen zijn.
Het is ook belachelijk om aan de ene kant 8GB (wat een overkill) werkgeheugen in een telefoon stoppen, en vervolgens er naar lijken te streven dat er nooit meer dan 3GB echt gebruikt zal worden...

(verder wel tevreden over mijn OnePlus 6)

[Arnout]

Ja, bizar gedrag, ik heb ook 8GB werkgeheugen, ik heb te weinig apps om dat helemaal te vullen, maar toch wordt bijvoorbeeld Maps al na een paar minuten gekilled...

[Xfade]

Het slotje werd mij ook aangeraden, echter had dit bij mij niet veel invloed. Veelal was Autostart aan en battery optimization uit voor die app voldoende. (Xiaomi)
Trouwens, het idee van het slotje systeem is, dat je hem juist weg mag swipen, hij blijft door dat slotje alsnog in het geheugen, ookal zie je hem niet meer in je recents.

"App pinning

When you open recent apps tray, drag your app downwards – it will be locked. So even if you clear recent apps it will not clear from the background. Drag downwards again to clear your app from the background."

[Reactie gewijzigd door Xfade op 22 juli 2024 21:36]

[SanderBos]

Dat is dan toch anders bij OnePlus, als ik je tenminste goed volg, nadat ik een app heb gelockt (wat dus al via menutje gaat en niet drag downwards), dan blijft 'ie in de lijst van recent apps staan, zowel als ik hem probeer weg te swipen naar boven als ik de clear all knop gebruik (die er bij OnePlus ook al anders uitziet, maar beter). De enige manier volgens mij waardoor ik er dan in de recent app lijst vanaf kom (visueel gezien bedoel ik) is weer het menutje openen en ontgrendelen.