It seems to be that these vendors ship builds of Android with aggressive battery-optimized defaults that breaks applications that rely on being able to run in the background.
Most push notifications are spam, and even when they aren't, they are usually from self-important apps that think they are the most important thing running on your phone.
The only push notifications I want are messages from humans.
See - messengers use push notifications to let you know about messages from humans. Most users of messengers get (understandably) upset if they don't receive notifications for incoming messages.
Note that you can always block notifications for apps you chose. The problem here is the other way around: You do want notifications, but even though you disable battery optimizations and some other things for the app you're using you can't get push notifications to be delivered reliably. That's a pain.
I actually like the move to kill background tasks. Don't get me wrong I think they're great when they're needed. But if I only installed the app because the mobile site is crippled I don't want it to destroy my battery polling for content changes when I only open the app once in a blue moon.
Killing background tasks is great and Android does that automatically to save battery usage. But these manufacturers have implemented their own functionality on top of Android which cripples even critical messaging applications like WhatsApp, Slack, Gmail by not delivering Instant Messages notifications instantly.
I want all the notifications. This was a question about timing. I don't want them to do the constant polling required for the notifications to appear instantly.
I don't want WhatsApp (owned by Facebook) to run in the background on my phone at all times. I don't trust them, especially after Instagram (also owned by Facebook) started using the camera by itself on my phone, without my permission.
The irony: Many manufacturers factory-whitelist apps like WhatsApp, Skype, sometimes Telegram. That means that smaller messengers get killed (=no more new message notifications) and users complain to the developer because "with WhatsApp everything works fine"...
These days the app doesn’t run in the background when receiving an FCM push notification (unless it’s already awake). The message is created by a separate Google Play Services process. It’s only when you click the notification does the target app’s process get woken up.
IMO, the best way to solve this is with an explicit “Let this app run in the background” permission, rather than implementing all these “smart” features which are incredibly non-deterministic. Which leads to developer & user frustration alike.
Take the example of the new “App Bucketing” battery saving feature in Android 9, plus a banking app and WhatsApp....
App Bucketing will basically restrict your background processing based on how often you interact with the app. So for your banking app (where you usually want immediate spending notifications), because you don’t really open the app that often, it’s going to start throttling your notifications (and prevent it from running arbitrary background jobs).
But for WhatsApp on the other hand - because you’ll likely open it more often - it will have full permissions to run in the background any time.
If as a user you wanted to prevent arbitrary WhatsApp background jobs and get instant banking notifications - well tough luck!
I think you misunderstood the core issue here - it's not that the USER can decide what runs. It's that the USER cannot override those settings and decide that something can run and function if required. There are special whitelists for apps that are allowed exceptions (e.g. Facebook and other common apps are usually allowed to work) and others are killed against the Android API guarantees (e.g. you install Signal messaging app and you don't receive messages because Huawei didn't whitelist the app).
> I think you misunderstood the core issue here - it's not that the USER can decide what runs. It's that the USER cannot override those settings and decide that something can run and function if required. There are special whitelists for apps that are allowed exceptions (e.g. Facebook and other common apps are usually allowed to work) and others are killed against the Android API guarantees (e.g. you install Signal messaging app and you don't receive messages because Huawei didn't whitelist the app).
I blame it on stock Android. Phone manufacturers probably don't want to spend money on OS changes but Android doesn't do the right thing by default so they have to make changes.
The right thing to do is to deny apps launching at startup, apps running in background, and apps getting network access. Let the user say yes or no. Your use case for signal is different from mine. Maybe I just want to see messages when I open the app?
And worse, what they're doing confuses android's own code into thinking the apps are crashy.
So if you run e.g. (new JobInfo.Builder(1234, name)).setRequiresCharging(true).setRequiresDeviceIdle(true)... to do something heavy (like reindexing an on-device database) while the phone is charging, that job will simply not be run on some phones. You have to check whether it's been run at app startup, and if necessary run it while the user is actively using your app.
The right way to solve this is with explicit permissions (similar to iOS). Rather than arbitrarily and sporadically crippling apps with opaque limitations.
Google & manufacturerers have gone too far in the quest for the Holy Grail of extending battery life. To the point where it’s negatively affects the user experience quite often (there are quite a few examples in these comments).
It makes Android overall seem more buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications).
One other big issue is that push-based wake-ups on Android don’t work reliably. For example, on iOS, if you want to wake up the app in the background when you come in range of an iBeacon, you can do so (with user permission), and it just works. Meaning you don’t need to run a special arbitrary background job (which is much less battery efficient).
On Android - BLE wakeups are so incredibly unreliable that entire classes of apps are becoming less and less viable. And without the loophole of running background jobs to manually scan for beacons, users (and developers) are basically shit out of luck.
In that case you wouldn’t opt-in to beacon notifications.
But there are many people with varying use-cases - some of whome want reliable BLE detections on their devices. And if they opt-in to these notifications, then it’s a shitty experience when it doesn’t actually work as intended.
It makes Android overall seem more buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications).
Do instant messaging apps really need to be running to listen for notifications? Why isn’t listening for notifications being handled by one central Android process that then dispatches it and launches the app if necessary?
That’s exactly how it works - but this service itself is throttled.
And, in Android 9, “App Buckets” will increase/decrease throttling depending on your usage of the app.
For example, an app that you don’t open regularly, but do want receive timely notifications from (like a banking app, or calendar/scheduling app), might only get 1 window a day where it receives notifications.
There is a difference between a notification that is sent to the user just to tell them something and then the user can take action (meaning no need to wake up the app) and a notification to the app for the app to do something in the background.
The former should always get to the user, the latter on iOS is controlled by both the OS based on an algorithm and by the user who can specifically turn off background processing on a per app basis on iOS.
Yes this is very true. Some apps like Truecaller just destroy the battery like there is no tommorow. Most other app including some games keep running just to tell me when it's time to collect my mystery box.
Point being the majority of the apps are badly coded to poll or drain battery, send unnecessary notifications.
This reminds me of the popup blocker thing in web browsers. While there were some legitimate uses most of the time it's abused so every browser blocked it.
Interestingly though it is possible to remotely detect which users are facing this problem and send them instructions on how to add an app to the device's whitelist. I faced this exact problem in my previous company Flock, and built services to detect and inform users which substantially brought down user complaints.
But how did you guys deal with the situation where FCM delivers and displays a notification without waking your app up. In that case, if the user dismisses the notification without opening it, then it will count as delivered by FCM, but not as delivered by your app, right? Which isn’t actually the case.
What we observed was that in cases of devices like xiaomi and oneplus, the app goes into a state of being force killed. So even if the notification sent is one without a data payload ( in which case the app is not woken up ) , the notification will not be displayed to the user.
To get around this issue we sent all messages with a data payload to ensure that the app is woken up(or atleast the system tries to wake it up).
The apps are not allowed to do background process. But can register a callback to be called when is in background. But there is no guarantee it will be called for sure.
For some cases, there is a 100% guarantee, especially for Bluetooth. I think we never lost a >sample< in the background so far (where I can't say the same for the Android).
In iOS, you have a few narrow cases where you're allowed to run in the background; some of which are specified to only maybe run.
In Android, you're technically allowed to run whenever you feel like it, but starting with Android 6, Google started limits, but I don't think apps get much feedback about when they might run, or if they can access the network when they do run. And the multitude of OEMs that are all dieing to make their product stick out means it's really a crapshoot; some oems were trying to do this before Google's release of the feature, some enable Google's version, but very aggressively, etc.
I understand the intent of these features, but there really needs to be a better way. Some apps do real, useful, work in the background, and it's not great for users when that can't happen. Many apps should probably only run when they're in the foreground. Either way, the app should be informed, so it can do the best it can, including informing users why it's not working and being able to direct users to where they can fix it, if desired.
> I understand the intent of these features, but there really needs to be a better way. Some apps do real, useful, work in the background, and it's not great for users when that can't happen. Many apps should probably only run when they're in the foreground. Either way, the app should be informed, so it can do the best it can, including informing users why it's not working and being able to direct users to where they can fix it, if desired.
This is why Android allows you to still run unrestricted if you show a persistent notification (as long as there's enough RAM). The whole point of the link you're commenting on is that some OEMs break this API.
As a developer, you are aware of the limitations so that you can work with them. E.g. when your app is closing down you have X ms to wrap your work up. But you can also request a longer task, or request the app to work in the background in certain scenarios. And as there is only 'one iOS', it will always work as 'agreed on'.
It seems like in Android the developer just assumes their app will be able to run in the background, except some versions just decides to kill it based on their own agendas.
> It seems like in Android the developer just assumes their app will be able to run in the background, except some versions just decides to kill it based on their own agendas.
That hasn't been true for some versions now. Yes, there's a mode where apps can run in the background without restrictions, but that hasn't been true for most apps for years now.
You can, for certain classes of application, and for certain types of tasks (like background downloads). It’s entirely managed by the OS, and is often reduced or suspended entirely under Low Power mode. But Apple allows for other kinds of wake notifications and is usually pretty good with Push Notifications due to carrier partnerships. That said, Apple does intentionally make certain apps a lot harder: https://stackoverflow.com/questions/35388086/is-there-a-way-... And... well, it rarely allows apps that duplicate built-in functionality on the App Store. So most iOS users stick to default apps. But at least one app takes advantage of Apple allowing the microphone in the background to create a “smart” alarm clock which Apple has featured as the App of the Day: Sleep Cycle alarm clock http://www.sleepcycle.com
And... well, it rarely allows apps that duplicate built-in functionality on the App Store.
This is such an old meme and there are plenty of existence proofs that it isn’t true. There are third party apps for every single app on iOS including navigation, podcasts, mail, music players, calendars, password managers (with integration APIs specifically for them as of iOS 12), weather, notes, etc.
You can't make your own App Store, you can't ship your own browser -- https://developer.apple.com/app-store/review/guidelines/#sof... -- you have to use HLS, you can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications". "Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected."
I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already.
I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already.
There is a difference between "I want to write a podcast app" and "I want to duplicate Overcast and just change a few icons"
And your first quote was "don't ship something we ship", which is quite different from "don't just reskin an existing app".
Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers.
You can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications".
Well unless you think that Apple added the APIs that I linked to and added settings to allow you to disable background processing (that doesn’t apply to the categories) you mentioned, which do you think is the more appropriate interpretation to what is allowed - the rules or the API documentation?
> I haven't followed the scene closely, but isn't it the same behavior as Apple? Can you even do background tasks in iOS?
This is about OEMs breaking the guarantees of the OS. Yes, Apple restricts your background processing time, but it will still reliably deliver APNS push notifications or keep your running if it's actively providing turn-by-turn nav, background calls or something that API deliberately allows you to do.
With Android, the issue is that OEMs listed on that site break guarantees that Android API gives you. Your app suddently stops receiveing push notifications because it's not on the whitelisted "golden set" - breaking smaller messengers like Signal. Or the OEM "battery saver" kills off Google Maps while it's running turn-by-turn during your drive. Issues like that, which are significantly different than having Doze mode save your battery. Or you schedule a sync job once per day on Wifi (which JobScheduler API gives you the ability to do) and Huawei decides to just break the API and not run it.
I had problems with synchronization between my OnePlus 3 and my Fitbit tracker (it'd work fine for an hour or a day and then just stop), but those problems went away when I upgraded to a OnePlus 6T. Regarding slack notifications and similar things, all I can say is that they sometimes appear a few seconds later than on my active desktop, but I don't find that delay to be a problem.
I had problems with my FitBit and other Bluetooth devices on my OP3 running stock firmware but these have all been resolved since I moved to LineageOS. Battery life seems better too (although I haven't explicitly measured).
We are encountering tremendous problems with OnePlus while keeping up the Bluetooth connection in the background with our Heath Tracker. Seems it might be related to the situation described in the linked page by OP.
tl;dr The author would like to run his app in the background without notifying the user about it, because otherwise the author would just add add an ongoing notification, which would allow the app to run in the background forever on all platforms.
I'm not sure this is the case, the website talks about propietary "battery savers", not about the standard Android one. I find it completely possible that they kill apps regardless of ongoing notifications.
I wouldn't necessarily ascribe anything shady here (which I got a bit of from your comment, if that was intended).
I found this helpful in debugging an issue I've had with my OnePlus - namely, many apps that I'd like to get notifications from abruptly stop getting them after a while, and I have to reopen them to get notifications. Today alone I had to manually open Facebook Messenger and Venmo in order to get notifications from them - this seriously degrades the functionality of those apps since opening Messenger multiple times a day still isn't apparently sufficient to exempt it from being "optimized".
Not really no. It's more problematic, a good amount of vendors doesn't allow applications to run in the background and it's not a matter of notifications.
It's a big issue with IM apps like Conversations or calendars and contacts synchronisation apps like DAVx5
There is much scope for abuse if things are relaxed, but all kinds of very serious use cases become somewhere in between “very difficult and/or unreliable” and “impossible” due to these techniques. For example: email clients, chat clients, calendars, even alarms sometimes.
The first affected things tend to be synchronisation jobs, but it’s distressingly common for these systems to break things so that notifications just mysteriously stop working outright—with no diagnostics of any form for user or developer.
Or how about emergency notifications? I live out in a rural area and it’s bushfire season; I want the VicEmergency app’s notifications pronto so that, if a threatening fire starts nearby I can get out quick.
If this were the solution, I'd have to have a notification that I can't swipe away for email, Telegram, Wire, navigation while navigating, music player while playing, alarm clock when an alarm is set... So say I'm driving with music, that's five useless notifications. The app can ask me on first launch if I want it to do this or not, rather than being permanently in my face about it.
The notification area is becoming increasingly useless (for actual notifications). Since upgrading from 4.4 to 7.0 last year, this has been bugging me quite a bit and I haven't yet found a solution. I was much happier with the old OS, but security updates...
But then it hides all notifications. I still want to know when I received a new email or message.
Again, Cyanogenmod based on Android 4.4 was better here: I could selectively hide notifications with certain contents. In Android 7, I can only choose not to display notifications from a certain app. I still have to write something that reads notifications and kill them selectively, but then I guess such a service would get killed as well without its own annoying notification... (The "you must update google play services to use this app" notification (which is a falsehood) is also annoying the crap out of me, another issue I didn't have on 4.4.)
I didn't actually know the wake lock would still work if you hide an app's notifications, I thought the notification was the prerequisite for not getting killed.
Your TL;DR is wrong and it completely misses the core issue the website is describing. It's about OEMs breaking core Android API guarantees in cases where the OS (by documentation) allows you to run in the background for short bursts during so-called Doze maintenance interval.
Only issue I have on my OnePlus 3T is Slack. I'm constantly missing or getting late notifications. And I tried fixing the issues with their support, but it didn't lead anywhere. They tried their best, but I can't blame the phone vendor because I have a dozen more apps with notifications, services and whatnot running quite well.
I've been out of Android app development for some time, but I hang out with a few Android developers, they usually have most of the issues with Samsung, they say that there are often some quirks that have to overcome. That mostly corresponds to my outdated experience.
Whether it's an Android issue or specific to OnePlus, I've noticed I have to reconfigure Slack as a "non-battery-optimised" app after each app update.
EDIT: More info on the subpage: "To avoid the system to automatically revert the not optimized setting, you must also lock the app into the ‘Recent App’ list." https://dontkillmyapp.com/oneplus
It also for me explains a lot about about the problems I've had with Fitbit notifications. They use an always running background task, and have a long list of troubleshooting steps to disable/re-enable the service repeatedly and after every Fitbit app update.
> If you keep your phone on silent you don't care if it delays fetching messages until you actually turn on your screen anyway...
That doesn't follow. All I want is my phone to be quiet; I don't stop caring about timely notifications because of this. Also, just because my phone is on silent doesn't mean vibration is turned off and, in the case of my iPhone, the notifications go to my Apple Watch.
I only looked at Nokia but it shows an embarrassing solution to the problem of users not having enough control over their phones. It should be effortless for users to control what apps can run and how much power they can use in the background.
It is time for the vendor neutral cell sized tablet with only a data module to avoid the draconian telecom monopoly protection regulations.
I watch the evolution (and evolution is the right word here, given the complete lack of intelligent design) of Android APIs with a kind of morbid fascination; a ritual dance between inept API designers with the foresight of a two year old spotting an ice cream vendor across a busy street and app developers who (driven by management) have to buy into the fact that their life saving and community transforming app (CRUD app for ordering fast food or something like that) must support 34 kinds of real time notifications.
The default mail app on my recent-ish Samsung flagship phone notifies me of new email anywhere from 30 minutes to 1 hour late. I used to depend on K9 Mail for business on the go, but it was even worse: notifications were often several hours late. Android was dropping the IMAP connection and not allowing the app to reconnect for a routine poll.
There doesn't seem to be any general-purpose email app on Android that can actually notify me at a reasonable interval (less than 10 minutes, if not immediately). Even after disabling every power-saving feature I could find, Samsung is still killing and crippling their own default app.
I understand that it takes a bit of battery to poll an IMAP server every few minutes. But if I want an app to be able to poll an IMAP server in the background at the cost of having to charge my phone a little more often, that's my choice. Besides, my old phone didn't have this problem and its battery still lasted a whole day.
What's even more infuriating is that the phone allows preinstalled social networking apps that I don't even use to continue running in the background while it happily kills the apps I actually need.
I got weirder behaviour from the stock Android email app: I discovered it's sending emails weeks late. When I discovered this, I found one email that was several months old lingering in my outbox.
Probably not related to this, but still incredibly weird, not to mention seriously broken.
The social media apps will almost certainly use Googles push notification service, which is the only background notification allowed.
Your imap client is trying to hold a TCP connection open to your server, which isn't allowed.
There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of apps can be listening for notifications at once, with no system resource overhead.
Secondly, imagine every app wanted to have a TCP connection open to it's own server. TCP must generally go through your wifi/3g providers NAT. That NAT gateway will drop idle connections, with the rules on which connections are dropped varying for every type of router and provider. In general, if you want reliable delivery, you're going to have to send some packet down a TCP connection every 5 minutes, although some providers it can be up to every 3 hours. If every app applies it's own heuristics to figure out how often to send a keep-alive message, and you have hundreds of listening apps each with their own connection, and no synchronisation between them, your phone will end up waking up every few seconds for some app to send a keep-alive.
Instead, Google keeps open just one connection. They have a serverside database of all network providers to know which ones drop connections when (BTW, this is a big advantage of using your cable providers default modem. If you have your own modem, this mechanism won't be accurate). It can then wake up and send just one keep-alive at the exact correct time.
From the server side, Google can batch messages to clients. It can decide that receiving 8 new marketing emails is important enough to sync to your phone, but only if the phone will be waking up for some other reason. Then when a snapchat message comes in, both the mail app and snapchat will be notified by a single wakeup of the phone.
Overall, it's a very good design. There are only 2 big downsides:
1) It's centralized. Nobody else can run a notification server. They have a monopoly on delivering notifications.
2) Their server isn't very good. It doesn't have the capability for example to simultaneously listen on 3G and wifi. It sometimes gets overloaded and unnecessarily delays messages. Their database of network providers is sometimes a bit off, meaning your phone is sending keep-alives every 30 minutes, while the connection times out after 20 minutes, meaning there is a 33% chance your message will get delayed by up to 10 mins.
Yeah, I don't really expect a mobile O/S to keep connections open indefinitely. It's hard enough to do that when the phone is awake and on the move, much less sleeping.
The O/S should, however, honor an app's request to wake up every 5-15 minutes to open a new connection, do some things with it, and go back to sleep. Especially if the user has given explicit permission to let the app in question use all the battery it wants. Periodic wakeup is what most email apps expect when they're set to "polling" mode. It used to work perfectly until about two years ago. It doesn't work anymore on recent Samsung phones. The system just ignores the wakeup schedule set by the app.
I'm not sure anyones written it up yet. You can see it for yourself if you run adb logcat on a sleeping phone. Try running it on different networks and see the keep alive period. (you'll have to turn off all push notification sources, because a push message counts as a keep alive too).
K-9 Mail works instantly for me (OnePlus One on Cyanogen). When I buy a beverage at my hackerspace, I hear the pling from the confirmation email within a few seconds of the purchase.
First I though "Is Nokia bad or good? Then I saw 'bad vendor score'" so I figured they are the worst. Then I got confused about all the vendors having the same score, but a different colour. Then I saw that some of the circles are slightly darker than the others... This type of visual communication hurts my brain too much.
It seems that just as bad apps they are trying to shield their website is also badly written and the simple picture of poop is linked from whatever of the 7 third-party sites with spying javascript code they are using and is blocked by adblock. Circles for me too.
Ah that explains it. I was under the impression that I was looking at a simple website, not some super fancy front-end application. I block all external domains with ublock-origin.
Since when do you need to serve emojis from a third party? I thought you can just insert them straight into your HTML. Or is that not cool enough?
For me this problem is very real. For example I got my mother a Pocofone F1 (by Xiaomi). Everything works fine, WhatsApp notifications arrive but there are some apps which just get crushed by Xiaomi's battery saver.
Audible's lock-screen widget for example just does not show up unless you enable/disable 2-3 battery saving and notification settings after installing the app. I think this incantation can't be expected even from advanced users. Normal users will just give up and live with terrible UX, complain to the dev or switch to another app. The same goes for fitbit, getting it to sync in the background involves a similar mixture of battery saving and notification settings which are labeled in a way that noone would dare to change them or have questionable defaults. None of this was an issue on the Nexus 5X. To me it looks like Xiaomi has a whitelist of apps which get special defaults when installing so they work fine while others which are not on this whitelist don't get this treatment.
I can understand the benefits of aggressive battery saving especially as there are apps which behave badly but the state it has come to now is terrible UX and is just another frustration instead if actually delivering a benefit to the user. This seems to me like "optimisation" for the sake of benchmarks and marketing claims.
If they didn't do this sort of aggressive system management, I'm wondering what the negative effects would be for them as a brand. I doubt it would be about benchmarks, those are generally done on clean systems at least for review purposes. Likewise Marketing is mainly about features.
I suppose it must be genuinely about the user experience and brand perception by device owners. If the phone slows down and the battery drains fast users will blame the phone manufacturer, while if apps crash or app features don't work users will blame the app vendor even though the reality in both cases would be the other way around.
The first thing I do on any Xiaomi phone is to install Lineage OS - because MIUI is just unusable for me. Lineage 16 release for Poco F1 is very stable although it's not an official release yet.
Another anecdote: my wife and a colleague at work (so 2 different people I know) have Xiaomi Note fives, and this model kills the stock alarm clock app! Regularly for both these people the alarm does not go off. My wife keeps an old Nokia candy bar phone around as a backup alarm it has happened so often. There's a workaround, maybe just placebo?, for this too: you can go to the recent apps screen and pin the app. But any kind of system update seems to undo the fix. I imagine your audible lock-screen widget will have the same issue, that system updates break the fix, and MIUI updates quite regularly.
I have a Xiaomi A1, with a more stock version of Android, and so far this has not been an issue. But I noticed in the recent Pie update that it mentioned "battery improvements". I've had no problem with battery before now, it lasts all day easily and I get home with 70% or so. I hope it doesn't start killing the alarm clock at night, when it's plugged in to charge, just to save battery.
MIUI has always known for aggressive sleep patterns, considering Pocofone is an India targeted device & WhatsApp is the go-to social media platform in India; It's intriguing that they haven't fixed such issues.
This is the Android multitasking lead finally coming fully circle. Android had multi tasking much earlier and in a more powerful way by allowing apps to start their own serivices and do pretty much whatever they wanted, but this is the unfortunate logical result - apps that agressively kill other apps, installed by the handset manufacturers, to protect users from badly written apps that drain the battery in the services.
Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks (audio playback, downloads, alarms, notifications) to the OS, and made clear guarantees about the circumstances under which the APIs would work.
I think the locked environments we have on phones is the reason we see a lot of trash apps. You don't have this development on more open platforms. At least no to that degree. So both, Apple and Google are at fault here.
It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.
The locked environment may prevent users from removing branded crapware installed by vendors, but it's not its cause. Popularity is.
If Gentoo Linux (just to name one we wouldn't expect Joe User to know) became popular as Android on cellphones, we would see in no time vendors trying to cram their crapware into every platform running Gentoo as well, but its open nature would allow users to remove unwanted stuff, so vendors would use any tactic to make it less open in order to force users to run their crap, get more brand exposition, steal personal data etc.
Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems. In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.
> only a closed system with a single gatekeeper that can avoid this problem at scale
I guess you are hinting at Apple phones but this works only because the gatekeeper is acting in good faith. Then again why do you need a single gatekeeper?
> Right, so 'open' Gentoo would get forked into a hundred locked down, obfuscated, proprietary flavours with all the same problems.
That's the beauty of the GPL: one can't lock down a GPLed distro that way.
> In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.
Those who s/freedom/security/g tend to rm -rf / and get neither freedom nor security.
"That's the beauty of the GPL: one can't lock down a GPLed distro that way."
True, but its strength is also its weakness in this context: anyone can keep the distro open but add some "vital" code that is closed and does what they want without anyone noticing. The GPL doesn't prevent closed code from running on open source machines, it just sets limitations on imposing limitations (which makes it so great IMO), so a module that displays advertising, tracks users or steals personal data can easily be implemented inside a closed app, blob, device driver etc. and unless I missed something the GPL can do nothing if that module was compiled using non GPLed compilers, linked against non GPLed libraries etc.
In other words, if I take a non GPLed compiler and a set of non GPLed libraries that set no obligation to open the resulting code if I distribute the output, I can write anything and add it to a Linux distro then distribute them together without any legal obligation to publish the source and reveal the internals of my code. That would be the case for suspicious code inside blobs and drivers.
Someone please correct me if I'm wrong.
Of course the community can fork in no time, but imagine a very popular piece of hardware which could work only with that closed blob.
> In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.
PC hardware is available from arbitrarily many vendors and you can install stock Windows or Linux on pretty much all of it. Many of the OEMs preinstall their various spyware, but you don't have to buy from them to begin with, and even then they can't stop you from removing it.
The primary difference in the phone market is the lack of open source drivers, so you can't install stock Android on your arbitrary phone because it needs the specific weird kernel it came with. But basically everybody hates that -- even the OEMs, because they neither want to be blamed for not providing updates nor want to have to actually provide them themselves. So it's slowly changing.
And even now, as a customer, there are unlocked devices available that will run stock Android, all you have to do is buy one of them.
The point is trash apps don't have to be a problem as long as the platform is managed properly. Anyway your trash app is probably someone else's fun entertainment.
I just doubt that "managed" platforms are delivering what they have promised and think that the quality of apps on more open systems is generally better by a few magnitudes without exaggerating too much.
And no, the trash app I am talking about exists to prey on unaware users by being an obvious fake or by extracting information about location, contacts and configuration.
"Managed" platforms accelerated this phenomenon in my opinion.
Isn't it also the consequence of taking the control away from the user? Why can't I whitelist which applications I want to allow to run in the background? Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually?
By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privacy perspective. Of course Google considers that you leaking your personal info is a feature so that part probably won't change, but they should at least care about the two other points.
Should also see if the killer apps are phoning home every time they kill anything, along with info about which app is killed on whose phone at what time. Becuase, you know, analytics.
And yeah, the permissions model in Android vs Apple is different, but multi tasking in particular feels the same. i.e. Apple has fine grained permissions on demand for contacts, microphone, camera, location, etc, and requires that all apps gracefully degrade when permissions is denied.
But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the background, no user permission is required. I think Apple does check that background APIs are not misused as part of the review process, though - I don’t think you could implement a tracking socket masquerading as a background download, for instace.
As I understand it, on iOS third part apps don’t actually do any tasks in the background, most such services are actually implemented by platform services provided by Apple that the third part apps request or subscribe to. So for example apps request an Apple service to do a background download on their behalf. Or the app subscribes to a notification feed that wakes it up when triggered to handle the notification, but the app doesn't do a download or wait for notifications itself.
Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication.
This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way.
EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.
For some basic use cases, like notifications and downloads, there is a special system or api that allows your app to do that in the background without actually running.
If you want to play audio or track gps in the background you need to do things yourself though.
Technically, you could have an app that plays silent audio in the background to keep from getting killed and then do something else, but that would get flagged by the review process.
But, if I recall correctly, VLC will continue a background file transfer session from its built in web server on iOS if you play a movie in the background. Otherwise it will be killed after 10 minutes.
I think they've wisened up to that trick. My girlfriend and I use a guided meditation app that has long silences in the audio. If the screen is off, her phone kills the app after about thirty seconds of silence, making the app practically useless.
I was going to report a bug to the app suggesting they include some ultrasonic or subsonic audio to defeat this mechanism, but it's just an arms race at that point. The phone will start looking at the total power in the audible spectrum to decide whether to kill the app or something.
This kind of thing is infuriating and prevents apps from doing anything outside of the box, stifling innovation and making users frustrated.
> Why do I still have to grant an application all the permissions it requests when I install it instead of being able to turn them on or off individually?
I don't think this is true in the later releases is it?
I get a lot more ad-hoc permission requests these days, and there's much more control in the application settings (the android app settings, not the settings the app presents).
It is true to some extent since Marshmellow. But apps can tell when their permissions are denied, so some of them straight out refuse to start unless you give it all the permissions it wants. This is especially problematic when a new version of an app holds your data hostage and refuses to start unless you give it a ridiculous new permission.
The Play Store has no requirement that apps degrade gracefully when permissions are denied. So the result is usually the same as pre-Marshmellow. You just get more annoying popups.
I miss Cyanogenmod where I could deny a permission (e.g. contacts) and the app would have no idea it was denied (it would receive an empty list of contacts).
No, it’s the consequence of permitting background tasks at will. Apple took some heat, and there is learning curve associated with doing it their way, but they actually thought it through and created an energy-efficient architecture that addresses common use cases. And apps that don’t fit those use cases - what are they doing with your device?
Slack works because of push notifications. A random IRC app can't handle push notifications for you because they aren't the IRC server and aren't running a bouncer for you. On the other hand, the IRC server can't handle push notifications for you because they don't have an app signed with Apple's key sending the notifications.
Basically protocols as a general thing can't work on iOS, only individual apps/services which get to read all your messages and access your login credentials work.
> Basically protocols as a general thing can't work on iOS, only individual apps/services which get to read all your messages and access your login credentials work.
Which I think is a reasonable requirement for a chat service, especially on mobile.
"Use a bouncer" might be the answer there. All engineering is compromise, and needing a bit more compromise to support legacy applications is not unreasonable.
(In fact, why are you running a stream-oriented application over such an unreliable connection at all?)
My XMPP client works perfectly on my Android phone. Prompt and reliable notifications of new messages. Better than most "Push Message" based clients I've used for other chat services.
It's consistently the last in battery usage as well.
Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.
>Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.
No, but the other 6 billion people on the planet do.
Every modern phone today will give you a list of the apps that take the most juice, and yet somehow for some reason people still install facebook. We might need to protect users from themselves.
Or users could start holding facebook accountable for shitty battery life.
I don't understand why phone manufacturers need to add features to protect facebook users from facebook. facebook has the money to build an app that isn't shit.
The "which apps are using battery" feature is easily useable by novice users.
However most phone vendors incorrectly assume "background connections" will drain battery life despite evidence to the contrary.
Phone vendors have a vested interest though in forcing developers to use their proprietary "push" feature for syncing to phones, they say it's for "battery life" but really its about vendor lock in.
A well engineered app can sync over its own TCP connection just fine and not hurt battery life, but then such an app can work on any device, not just blessed Android builds that have access to GCM.
> This is what the push message API in iOS is for. It wakes up the app when messages come in.
IRC isn't reliant on a proprietary push message API, though (be that provided by Apple or Google).
I'm sure there are long-lived bouncer plugins that will integrate with said APIs, but the core IRC protocol is not suited to or designed for devices that aren't capable of a long-lived connection.
I think the point being made is that’s a terrible use of resources, not only are you keeping the app running, but you are also forcing the power hungry LTE radio to stay on more.
This idea that the end device should do all the work is not a sustainable approach. There should be a server side component that is handling this for you and sending push notifications when your app needs to wake up for new data.
How do you think push notifications work? There isn't some magic in LTE to wake up your phone. Your phone needs to keep a connection open in the background and periodically wake up the modem to check for new information.
I use Conversations (XMPP client) on Android, it keeps a plain old TCP connection open in the background and honestly it does not much battery at all. It's consistently at the bottom of battery usage according to my phone.
Do push notifications take advantage of knowledge of the physical layer of the network?
It's a lot cheaper to keep an LTE radio on in a low-wattage "ping me if you need me" mode and trust the 'infinite-power' landside terminal to notify you of messages than to wake it up once every N seconds to loudly ping a cell tower "HEY LET ME KNOW IF I HAVE ANY MESSAGES KTHX."
There’s a very distinct difference between having a persistent connection that only transmits data when there’s something notable vs having a connection that constants pushes a kitchen sink of data that may or may not be needed. Sure, if you sent a push notification on every single message and status change on the IRC server, it’d likely use the same amount of (or maybe more) battery, but who does that?
If you want a messaging app to work well, it should send and receive messages when the phone has network connectivity and power. Power is a prerequisite for running in the foreground, but network connectivity is not. Some people may in fact want messaging apps to only work while in the foreground and network available, but I suspect that's less desired.
If you're trying to run standard irc and appear online as much as possible, that's not going to work in iOS without a bouncer to stay online for you and send push messages to send notifications and allow the app to run for a bit to download the messages.
It's probably not a bad idea on Android too, it's technically possible to run as a background service and stay connected, but there's a lot of uncertainty, because other services can crowd you out, and you're at the whim of Google and oems with power management these days.
And also, it's the 21st century and we don't need chat protocols to be client-side-liveness chatty to "stay on" when the entire cellular network is architected to find devices and route messages to them.
IRC isn't a well-designed protocol for this use case, and a "land-side" bouncer that bridges the chatty protocol to a lazier protocol ought to be more energy-efficient overall.
That's fine. you are "free" to hack your own version of Android that modifies the APIs to disregard power-management best practices.
... and maybe your own hardware to run them on. But I wouldn't expect any major player competing against other companies to do the work for you when the outcome is supporting some chat protocols that most people don't use.
(Otherwise, if you're expecting vendors to do it for you, you get to expect the lecture that comes with that expectation, in the form of APIs designed to minimize the ease of doing the wrong-for-the-average-utility-of-the-platform thing. Your cell radio could probably be adjusted to operate as a spark-gap transmitter also, but I don't expect them to provide an easy API for that either ;) ).
> And apps that don’t fit those use cases - what are they doing with your device?
What I, the owner of my device, have directed them to do.
Apple's approach makes easy things difficult (because one must use their APIs) and difficult things impossible (because Apple have decided that purchasers of their devices shouldn't be permitted to do things Apple wishes them not to do).
I want a general-purpose computer that I own & control in my pocket, not some stripped-down communicator owned & control by someone else.
On my phone (android), going to apps>selecting app I want to run in the background>battery>background usage I can allow the app to run unrestricted in the background.
My understanding from the OP website is that this is ineffective for certain popular phone vendors' customizations. In particular, the Nokia phone listed comes preinstalled with an app that aggressively shuts down any running process, whitelisted or not, if the screen has been off for 20 minutes. There's simply no way to stop this behavior apart from gaining root and uninstalling the battery "saving" app, or flashing a stock Android image that doesn't contain it.
The Nokia one is egregious, but their second worst vendor (OnePlus) allows users to whitelist individual apps, though there's a bug right now where that setting gets reset randomly.
This isn't about protecting the user from badly written and battery draining apps. Almost all of the mentioned manufacturers ship their devices with a long list of pre-installed and whitelisted services, including Facebook and other spyware.
As a developer myself, it is just annoying do deal with and just not scalable if you have to explain each user individually how to turn of these "optimizations" (if that's even possible).
It’s also not scalable if every app starts running background processes on an operating system without “virtual memory” - yes, I know there is a difference between virtual memory and swapping to the disk.
Even stock android does not guarantee that background services can run indefinitely, but Google at least provides clear rules what process may run how long in the background and under which circumstances it is killed. I have no idea why the manufacturers are allowed to blatantly break those rules and still brand their operating system Android.
>> "Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks"
iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does.
_Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained.
As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail.
Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps.
_Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc).
There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.
Isn't that the same kind of excuse-making you're dinging the Android world for? "OK, fine, the experience sucks by default but it works fine if you just do this and this and this". Android has all those sorts of features too.
It's just a hard problem. App developers are bad, and do bad things. OSes can't protect against all bad behavior. Phone manufacturers do have a vested interest in protecting their users from bad apps. Users do actually benefit from this on balance.
Users don't benefit from lazy ham-fisted hacks. There is no benefit to killing an app without notifying it in any way, or killing a background app that is using 0.2% of available memory and 0.0% of CPU just because it has been open for a long time.
> There is no benefit to killing an app without notifying it in any way
Sigh. There can be on balance. Bad apps get killed, users don't see as many dead phones. A few false positives get killed too, to great annoyance of their authors (and potentially users, but it's mostly the app authors upset here, be honest).
Whether that's worth it or not depends on the numbers involved, not your personal definition for "ham-fisted" or the existence of a better solution.
All I'm saying is that app vendors aren't the only parties involved here, and that the problem being addressed is real, and quite important.
Can you explain the advantage in killing the app without notifying it? You're going to kill the app because it's consuming 500MB of memory, fine, send it SIGTERM or equivalent and then give it two minutes to orderly shut down before you send SIGKILL. Not doing it that way has a cost and no apparent benefit to "balance" it with.
> Can you explain the advantage in killing the app without notifying it?
Um.. "The app uses less energy." Is that a serious question?
Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.
> Um.. "The app uses less energy." Is that a serious question?
For the two minutes between when you ask it to shut down and when you kill it? Even assuming that's a meaningful amount of energy savings (probably not), you could just kill it at the same time as you would have regardless but ask it to shut down two minutes before that.
> Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.
All value is relative. You can make anything sound good by comparing it to something arbitrarily worse, but that doesn't prove anything. Riding a donkey is better than walking on foot but I wouldn't want to have to travel from New York to LA on one.
The question is whether it's better than the good known existing alternatives, not whether it's better than the bad ones.
Background refresh doesn't work if the user "force closes" the app, i.e. they go to the task manager and swipe it away. Anecdotally, it's super common for people to do this as they have read somewhere that it helps battery life (not untrue, but also not really effective). So if you were writing an e-mail app you wouldn't be able to guarantee that you'll actually deliver e-mail to users, which feels kind of important.
Sounds like user error at that point, I would popup a message after the next force quit saying that doing so will pause email notification until the app is reopened.
How on earth would that be a feature? If you have to show a popup on launch for something like that then it's a user experience failure, no matter if it's your fault or Apple's. Either way, it means the user has to treat your app differently to every other app on their phone. That is bad.
"It's user error" is a weak excuse if any kind of significant number of users are doing it.
I think most users expect to receive notifications from apps (especially communication apps) even if the app doesn't appear in the App Switcher carousel. What people expect from their phones and computers are wildly different here.
An app that has been force quit can still receive remote notifications just fine. I don't think the average users knowledge is so nuanced that they understand the distinction between a remotely-sent notification that always appears and a locally generated one that's the result of a background process that doesn't.
The feature in my mind was an easy way to temp silence an app without going into settings.
I still think of it as user error if they force quit an app but still expect it to run in the background. Why force quit it?
I could see how it could be a UX failure for the OS but I don't think we can blame the dev for that. Apple should clarify what force quit does. I think the advent of webapps that don't really exist on your phone at all also causes confusion: the app has been updated with more content each time you use it, even if it's not running in the background, but to the user that's indistinguishable from the app running in the background.
But it comes down to this: if a user explicitly kills an app, should it keep running in the background?
If the answer is "yes", then what you're really saying is users shouldn't be able to kill apps if the app doesn't want to be killed.
I get that some users don't know what killing an app means but do it anyway for some reason.
But that's not a problem with background refresh. E.g., maybe iOS could warn/explain about the implications of killing an app (with a checkbox so you can opt-out of further warnings).
Edit: just realized I left the word “not” out just above, which reverses it’s meaning
The problem is that nothing is self-evident. An app that sends remote notifications to notify you of an e-mail looks exactly the same as one that locally generates a notification as a result of background processing. But the former will work after being swiped away from the app switcher and the latter won't.
I just don't think it's reasonable to expect the average use to "get" that.
I think that's an over fatalistic interpretation. You're implying that giving more power to users inevitably results in them harming themselves and therefore should not be done, instead the OS vendor should make explicit APIs for everything and only whitelist "allowable" things.
My problem with that is that it kills all innovation and creativity - only the OS vendor can come up with a "new" whitelisted activity. Anybody else is out of luck. Inevitably that means you simply can't get niche applications because what Google or Apple sized company is going to invest in something only 10,000 people might use? I might be idealistic, but I firmly believe that it's possible to both grant power to end users (as in, enable app developers to have a very large amount of control) AND deliver a good end user experience. It requires a lot of good design and discipline and it's definitely hard, but that's not an excuse to give up and hand over all control to the OS vendor.
I'm confused. Is this something that occurs all the time, or only when I turn on Battery Saver? Because I love Battery Saver mode. Unless you're a communications app (messaging, phone, email) I don't need your app running when I'm not actively using it.
> Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds.
Wait, do you really need a background task for alarms?
(why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?
No, you don't need a background task for alarms. There is a JobScheduler API for that.
The aggressive battery settings of most vendors only interfere with badly coded apps to begin with, apps that use background tasks when they should be using more appropriate APIs.
what the jobscheduler api is supposed to be used for isn't clear in the docs so people tend to default to creating services(the old way of doing background activities) instead.
https://docs.microsoft.com/en-us/xamarin/android/platform/an...
compare microsoft's documentation of the same thing with google's documentation and you will see where the failing happens. in comparison intentservices(the old way of doing bg tasks recommended by everyone) are documented the same way by both google and microsoft and so that gets used instead.
On some Xiaomi devices the stock alarm clock - the Google one - regularly fails to trigger alarms. If Google themselves cannot code an Android alarm clock that works with these aggressive battery saving anti-features there's little hope for anyone else.
No, I have an A1 and it doesn't have these problems. Note 5 definitely did the random alarm fail thing. The Note 5 kills other apps too like step counter or calendar event notifications. Maybe those apps are "badly coded" or whatever, but on a Moto G that sort of shenanigans didn't happen and the same apps worked great with no terrible battery life.
>apps that use background tasks when they should be using more appropriate APIs.
But some tasks do need to run in background, don't they? Specifically, sports tracking apps. Had a lot of issues with those on on various phones; now I simply don't switch out of the tracking app at all while it's running (otherwise, I can never be sure it simply won't be tombstoned in the background).
My Galaxy S6 was really aggressive for closing apps that it thought might impact battery life. Specifically, it was always closing one app I used to record my workouts in the gym. Very annoying.
The whole damn page you're commenting on exists because those APIs are broken by OEMs. You schedule execution, the alarm doesn't trigger. Did you look at the page before commenting? :(
(assuming the claims on the site are correct, since I have no first-hand data on it) You really don't get that some people think apps like alarm clocks, sleep tracking, GPS logging, ... are useful and should be allowed to run if the user chooses them? To me, a phone that can't reliably run an application for a few hours is fairly useless.
My alarms go off just fine (although I vaguely remember it not going off once or twice a few updates ago), my activity tracker works fine[0] and syncs periodically. I don't use GPS constantly. Signal notifications were also delayed a few updates ago, but now everything runs smoothly.
I find it a worthy sacrifice to make for a sturdy Android One phone with solid performance and a battery that can last two days on medium usage. My activity tracker lasts weeks without charging (comparable to a Kindle).
[0] Worth pointing out that my activity tracker was also developed by Nokia (before they've sold their health division to Withings), so it may receive some special treatment.
I read a comment on Reddit [0] from a Nokia user that had a large file transfer using Solid Explorer killed twice because he left the phone unattended and the screen shut off. It worked when he kept the screen on.
Would you mind testing if background file transfers work as standard and with manual battery optimization whitelisting?
I have had SO many problems with my Android version of a background-running app I made. I've even made a PDF guide just like this page for my customers. Glad to see it's "not just me" - hopefully the vendors will start waking up.
The solution to this should be user experience billing.
If your app wants to run a background service which degrades the users battery, you are degrading the user experience for that user, and all the other apps they use.
Another app on the same phone which is very power efficient will still not get used if the battery is dead!
App developers who use up the phone battery should be required to compensate those who use it sparingly.
Google could set up a market for 'milliamp-hours', where each mAh used up by an app is worth $0.00001c. Apps will put money in the pot (subtracted from ad revenue) proportional to how much power they use, and be handed out to all apps based on app usage (how many hours in the foreground for example).
Ehm, no?! I want more control over what runs not less. It's my electricity on my phone, I certainly don't need someone else auctioning it off like my phone is a billboard.
Your idea basically means that apps that spam ads can use more power, even if they're used less. And free or paid apps without ads couldn't afford to run at all. How does this help the user?
android needs to stop being treated as garbage by google. take the reins, full control - monetarily fine OEMs who make their own garbage modifications to the underlying OS and actively harm the user experience. no timely updates? fine. garbage ux reported by vast majority of users? fine. basically re-implement nintendo's seal of approval for games but with the help of crowd-sourced reviews. we have the technology.
but no instead we'll probably get fuschia and android will be deprecated lmao
413 comments
[ 5.3 ms ] story [ 318 ms ] threadIt seems to be that these vendors ship builds of Android with aggressive battery-optimized defaults that breaks applications that rely on being able to run in the background.
The only push notifications I want are messages from humans.
Note that you can always block notifications for apps you chose. The problem here is the other way around: You do want notifications, but even though you disable battery optimizations and some other things for the app you're using you can't get push notifications to be delivered reliably. That's a pain.
https://dontkillmyapp.com/nokia
Slack would be fine, I guess.
IMO, the best way to solve this is with an explicit “Let this app run in the background” permission, rather than implementing all these “smart” features which are incredibly non-deterministic. Which leads to developer & user frustration alike.
Take the example of the new “App Bucketing” battery saving feature in Android 9, plus a banking app and WhatsApp....
App Bucketing will basically restrict your background processing based on how often you interact with the app. So for your banking app (where you usually want immediate spending notifications), because you don’t really open the app that often, it’s going to start throttling your notifications (and prevent it from running arbitrary background jobs).
But for WhatsApp on the other hand - because you’ll likely open it more often - it will have full permissions to run in the background any time.
If as a user you wanted to prevent arbitrary WhatsApp background jobs and get instant banking notifications - well tough luck!
I blame it on stock Android. Phone manufacturers probably don't want to spend money on OS changes but Android doesn't do the right thing by default so they have to make changes.
The right thing to do is to deny apps launching at startup, apps running in background, and apps getting network access. Let the user say yes or no. Your use case for signal is different from mine. Maybe I just want to see messages when I open the app?
But yeah I agree, the user should be in control.
So if you run e.g. (new JobInfo.Builder(1234, name)).setRequiresCharging(true).setRequiresDeviceIdle(true)... to do something heavy (like reindexing an on-device database) while the phone is charging, that job will simply not be run on some phones. You have to check whether it's been run at app startup, and if necessary run it while the user is actively using your app.
Google & manufacturerers have gone too far in the quest for the Holy Grail of extending battery life. To the point where it’s negatively affects the user experience quite often (there are quite a few examples in these comments).
It makes Android overall seem more buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications).
One other big issue is that push-based wake-ups on Android don’t work reliably. For example, on iOS, if you want to wake up the app in the background when you come in range of an iBeacon, you can do so (with user permission), and it just works. Meaning you don’t need to run a special arbitrary background job (which is much less battery efficient).
On Android - BLE wakeups are so incredibly unreliable that entire classes of apps are becoming less and less viable. And without the loophole of running background jobs to manually scan for beacons, users (and developers) are basically shit out of luck.
But there are many people with varying use-cases - some of whome want reliable BLE detections on their devices. And if they opt-in to these notifications, then it’s a shitty experience when it doesn’t actually work as intended.
Never have, got 'location related alerts' a few times before I figured out how to switch them all off, without ever having opted in.
To be fair I have no idea if these were BLE related, but they were annoying.
Do instant messaging apps really need to be running to listen for notifications? Why isn’t listening for notifications being handled by one central Android process that then dispatches it and launches the app if necessary?
And, in Android 9, “App Buckets” will increase/decrease throttling depending on your usage of the app.
For example, an app that you don’t open regularly, but do want receive timely notifications from (like a banking app, or calendar/scheduling app), might only get 1 window a day where it receives notifications.
The former should always get to the user, the latter on iOS is controlled by both the OS based on an algorithm and by the user who can specifically turn off background processing on a per app basis on iOS.
Point being the majority of the apps are badly coded to poll or drain battery, send unnecessary notifications.
This reminds me of the popup blocker thing in web browsers. While there were some legitimate uses most of the time it's abused so every browser blocked it.
https://hackernoon.com/notifications-in-android-are-horribly...
But how did you guys deal with the situation where FCM delivers and displays a notification without waking your app up. In that case, if the user dismisses the notification without opening it, then it will count as delivered by FCM, but not as delivered by your app, right? Which isn’t actually the case.
But they have an arguably better push notification system which seems to use less battery and work better with sleeping apps.
In Android, you're technically allowed to run whenever you feel like it, but starting with Android 6, Google started limits, but I don't think apps get much feedback about when they might run, or if they can access the network when they do run. And the multitude of OEMs that are all dieing to make their product stick out means it's really a crapshoot; some oems were trying to do this before Google's release of the feature, some enable Google's version, but very aggressively, etc.
I understand the intent of these features, but there really needs to be a better way. Some apps do real, useful, work in the background, and it's not great for users when that can't happen. Many apps should probably only run when they're in the foreground. Either way, the app should be informed, so it can do the best it can, including informing users why it's not working and being able to direct users to where they can fix it, if desired.
This is why Android allows you to still run unrestricted if you show a persistent notification (as long as there's enough RAM). The whole point of the link you're commenting on is that some OEMs break this API.
It seems like in Android the developer just assumes their app will be able to run in the background, except some versions just decides to kill it based on their own agendas.
That hasn't been true for some versions now. Yes, there's a mode where apps can run in the background without restrictions, but that hasn't been true for most apps for years now.
This is such an old meme and there are plenty of existence proofs that it isn’t true. There are third party apps for every single app on iOS including navigation, podcasts, mail, music players, calendars, password managers (with integration APIs specifically for them as of iOS 12), weather, notes, etc.
Unacceptable: https://developer.apple.com/app-store/review/guidelines/#una... Spam: https://developer.apple.com/app-store/review/guidelines/#spa... Copycats: https://developer.apple.com/app-store/review/guidelines/#cop...
You can't make your own App Store, you can't ship your own browser -- https://developer.apple.com/app-store/review/guidelines/#sof... -- you have to use HLS, you can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications". "Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected."
I'm not saying the rules aren't much improved from what they used to be -- it's been years since the simple advice was "don't ship something we ship," but ... at its core, it's still somewhat true. You have to ship an original app -- and all of the app categories you mentioned have truly original apps on the App Store already.
There is a difference between "I want to write a podcast app" and "I want to duplicate Overcast and just change a few icons"
And your first quote was "don't ship something we ship", which is quite different from "don't just reskin an existing app".
https://developer.apple.com/app-store/review/guidelines/#cop...
Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers.
You can't use background features except for approved categories: "VoIP, audio playback, location, task completion, local notifications".
https://developer.apple.com/library/archive/documentation/iP...
This is about OEMs breaking the guarantees of the OS. Yes, Apple restricts your background processing time, but it will still reliably deliver APNS push notifications or keep your running if it's actively providing turn-by-turn nav, background calls or something that API deliberately allows you to do.
With Android, the issue is that OEMs listed on that site break guarantees that Android API gives you. Your app suddently stops receiveing push notifications because it's not on the whitelisted "golden set" - breaking smaller messengers like Signal. Or the OEM "battery saver" kills off Google Maps while it's running turn-by-turn during your drive. Issues like that, which are significantly different than having Doze mode save your battery. Or you schedule a sync job once per day on Wifi (which JobScheduler API gives you the ability to do) and Huawei decides to just break the API and not run it.
For example, push notifications are handled by one system process, and will only open the relevant app when the user clicks it.
I found this helpful in debugging an issue I've had with my OnePlus - namely, many apps that I'd like to get notifications from abruptly stop getting them after a while, and I have to reopen them to get notifications. Today alone I had to manually open Facebook Messenger and Venmo in order to get notifications from them - this seriously degrades the functionality of those apps since opening Messenger multiple times a day still isn't apparently sufficient to exempt it from being "optimized".
It's a big issue with IM apps like Conversations or calendars and contacts synchronisation apps like DAVx5
Some example: https://github.com/siacs/Conversations/issues/2771
The first affected things tend to be synchronisation jobs, but it’s distressingly common for these systems to break things so that notifications just mysteriously stop working outright—with no diagnostics of any form for user or developer.
Or how about emergency notifications? I live out in a rural area and it’s bushfire season; I want the VicEmergency app’s notifications pronto so that, if a threatening fire starts nearby I can get out quick.
The notification area is becoming increasingly useless (for actual notifications). Since upgrading from 4.4 to 7.0 last year, this has been bugging me quite a bit and I haven't yet found a solution. I was much happier with the old OS, but security updates...
Again, Cyanogenmod based on Android 4.4 was better here: I could selectively hide notifications with certain contents. In Android 7, I can only choose not to display notifications from a certain app. I still have to write something that reads notifications and kill them selectively, but then I guess such a service would get killed as well without its own annoying notification... (The "you must update google play services to use this app" notification (which is a falsehood) is also annoying the crap out of me, another issue I didn't have on 4.4.)
I didn't actually know the wake lock would still work if you hide an app's notifications, I thought the notification was the prerequisite for not getting killed.
I've been out of Android app development for some time, but I hang out with a few Android developers, they usually have most of the issues with Samsung, they say that there are often some quirks that have to overcome. That mostly corresponds to my outdated experience.
EDIT: More info on the subpage: "To avoid the system to automatically revert the not optimized setting, you must also lock the app into the ‘Recent App’ list." https://dontkillmyapp.com/oneplus
Makese sense no since I have a Oneplus.
The UI makes it very clear if you have it enabled, it explicitly tells you what it does and I never missed anything because of it.
If you keep your phone on silent you don’t care if it delays fetching messages until you actually turn on your screen anyway...
That doesn't follow. All I want is my phone to be quiet; I don't stop caring about timely notifications because of this. Also, just because my phone is on silent doesn't mean vibration is turned off and, in the case of my iPhone, the notifications go to my Apple Watch.
My phone is almost always silent because of our dogs, but I have it lying on my desk and see when something has arrived due to the blinking indicator.
It is time for the vendor neutral cell sized tablet with only a data module to avoid the draconian telecom monopoly protection regulations.
There doesn't seem to be any general-purpose email app on Android that can actually notify me at a reasonable interval (less than 10 minutes, if not immediately). Even after disabling every power-saving feature I could find, Samsung is still killing and crippling their own default app.
I understand that it takes a bit of battery to poll an IMAP server every few minutes. But if I want an app to be able to poll an IMAP server in the background at the cost of having to charge my phone a little more often, that's my choice. Besides, my old phone didn't have this problem and its battery still lasted a whole day.
What's even more infuriating is that the phone allows preinstalled social networking apps that I don't even use to continue running in the background while it happily kills the apps I actually need.
Probably not related to this, but still incredibly weird, not to mention seriously broken.
Your imap client is trying to hold a TCP connection open to your server, which isn't allowed.
There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of apps can be listening for notifications at once, with no system resource overhead.
Secondly, imagine every app wanted to have a TCP connection open to it's own server. TCP must generally go through your wifi/3g providers NAT. That NAT gateway will drop idle connections, with the rules on which connections are dropped varying for every type of router and provider. In general, if you want reliable delivery, you're going to have to send some packet down a TCP connection every 5 minutes, although some providers it can be up to every 3 hours. If every app applies it's own heuristics to figure out how often to send a keep-alive message, and you have hundreds of listening apps each with their own connection, and no synchronisation between them, your phone will end up waking up every few seconds for some app to send a keep-alive.
Instead, Google keeps open just one connection. They have a serverside database of all network providers to know which ones drop connections when (BTW, this is a big advantage of using your cable providers default modem. If you have your own modem, this mechanism won't be accurate). It can then wake up and send just one keep-alive at the exact correct time.
From the server side, Google can batch messages to clients. It can decide that receiving 8 new marketing emails is important enough to sync to your phone, but only if the phone will be waking up for some other reason. Then when a snapchat message comes in, both the mail app and snapchat will be notified by a single wakeup of the phone.
Overall, it's a very good design. There are only 2 big downsides:
1) It's centralized. Nobody else can run a notification server. They have a monopoly on delivering notifications.
2) Their server isn't very good. It doesn't have the capability for example to simultaneously listen on 3G and wifi. It sometimes gets overloaded and unnecessarily delays messages. Their database of network providers is sometimes a bit off, meaning your phone is sending keep-alives every 30 minutes, while the connection times out after 20 minutes, meaning there is a 33% chance your message will get delayed by up to 10 mins.
The O/S should, however, honor an app's request to wake up every 5-15 minutes to open a new connection, do some things with it, and go back to sleep. Especially if the user has given explicit permission to let the app in question use all the battery it wants. Periodic wakeup is what most email apps expect when they're set to "polling" mode. It used to work perfectly until about two years ago. It doesn't work anymore on recent Samsung phones. The system just ignores the wakeup schedule set by the app.
It took a few seconds for that to be visible when I visited the page, initially only showing as large dots.
Each vendor has 1-5 poop emojis with Nokia having 5 and Stock Android only 1
Since when do you need to serve emojis from a third party? I thought you can just insert them straight into your HTML. Or is that not cool enough?
Audible's lock-screen widget for example just does not show up unless you enable/disable 2-3 battery saving and notification settings after installing the app. I think this incantation can't be expected even from advanced users. Normal users will just give up and live with terrible UX, complain to the dev or switch to another app. The same goes for fitbit, getting it to sync in the background involves a similar mixture of battery saving and notification settings which are labeled in a way that noone would dare to change them or have questionable defaults. None of this was an issue on the Nexus 5X. To me it looks like Xiaomi has a whitelist of apps which get special defaults when installing so they work fine while others which are not on this whitelist don't get this treatment.
I can understand the benefits of aggressive battery saving especially as there are apps which behave badly but the state it has come to now is terrible UX and is just another frustration instead if actually delivering a benefit to the user. This seems to me like "optimisation" for the sake of benchmarks and marketing claims.
I suppose it must be genuinely about the user experience and brand perception by device owners. If the phone slows down and the battery drains fast users will blame the phone manufacturer, while if apps crash or app features don't work users will blame the app vendor even though the reality in both cases would be the other way around.
I have a Xiaomi A1, with a more stock version of Android, and so far this has not been an issue. But I noticed in the recent Pie update that it mentioned "battery improvements". I've had no problem with battery before now, it lasts all day easily and I get home with 70% or so. I hope it doesn't start killing the alarm clock at night, when it's plugged in to charge, just to save battery.
Apple took a lot of flak for not having multitasking, but to they credit they took the time to build explicit APIs that allowed apps to handoff certain whitelisted tasks (audio playback, downloads, alarms, notifications) to the OS, and made clear guarantees about the circumstances under which the APIs would work.
It is not the API, it is not threading capabilities. Just shitty and locked environments. So define as many additional rules as you like. Won't change much.
I guess you are hinting at Apple phones but this works only because the gatekeeper is acting in good faith. Then again why do you need a single gatekeeper?
I mean you can disagree, that's fine, in which case just say so.
That's the beauty of the GPL: one can't lock down a GPLed distro that way.
> In fact it's only a closed system with a single gatekeeper that can avoid this problem at scale, because it's the only way to maintain clear lines of responsibility.
Those who s/freedom/security/g tend to rm -rf / and get neither freedom nor security.
True, but its strength is also its weakness in this context: anyone can keep the distro open but add some "vital" code that is closed and does what they want without anyone noticing. The GPL doesn't prevent closed code from running on open source machines, it just sets limitations on imposing limitations (which makes it so great IMO), so a module that displays advertising, tracks users or steals personal data can easily be implemented inside a closed app, blob, device driver etc. and unless I missed something the GPL can do nothing if that module was compiled using non GPLed compilers, linked against non GPLed libraries etc. In other words, if I take a non GPLed compiler and a set of non GPLed libraries that set no obligation to open the resulting code if I distribute the output, I can write anything and add it to a Linux distro then distribute them together without any legal obligation to publish the source and reveal the internals of my code. That would be the case for suspicious code inside blobs and drivers. Someone please correct me if I'm wrong.
Of course the community can fork in no time, but imagine a very popular piece of hardware which could work only with that closed blob.
PC hardware is available from arbitrarily many vendors and you can install stock Windows or Linux on pretty much all of it. Many of the OEMs preinstall their various spyware, but you don't have to buy from them to begin with, and even then they can't stop you from removing it.
The primary difference in the phone market is the lack of open source drivers, so you can't install stock Android on your arbitrary phone because it needs the specific weird kernel it came with. But basically everybody hates that -- even the OEMs, because they neither want to be blamed for not providing updates nor want to have to actually provide them themselves. So it's slowly changing.
And even now, as a customer, there are unlocked devices available that will run stock Android, all you have to do is buy one of them.
They would find a way, because money.
And no, the trash app I am talking about exists to prey on unaware users by being an obvious fake or by extracting information about location, contacts and configuration.
"Managed" platforms accelerated this phenomenon in my opinion.
By dumbing things down that way Google created this situation IMO, it's bad from a quality, usability and privacy perspective. Of course Google considers that you leaking your personal info is a feature so that part probably won't change, but they should at least care about the two other points.
But for multitasking there isn’t really any fine grained permissions - as long as the app is doing a whitelisted task in the background, no user permission is required. I think Apple does check that background APIs are not misused as part of the review process, though - I don’t think you could implement a tracking socket masquerading as a background download, for instace.
Very often on iOS when you see a notification 'from an app' or something in the background is completed 'by an app', in fact the app didn't do any of it. This means fine grained permissions for background processing aren't really an issue on iOS, because such behavior is managed and guaranteed by Apple. It only matters when there's a security or privacy implication.
This is why background activities came so much later to iOS, because Apple had to very carefully think through and implement all the background services apps would require in an efficient and secure way.
EDIT: To be clear there are some exceptions but I'm not sure exactly what they are.
If you want to play audio or track gps in the background you need to do things yourself though.
The Facebook app used to play a silent audio track to stay active in the background, until they got called out: https://www.reddit.com/r/iphone/comments/3opxhm/facebook_app...
But, if I recall correctly, VLC will continue a background file transfer session from its built in web server on iOS if you play a movie in the background. Otherwise it will be killed after 10 minutes.
I was going to report a bug to the app suggesting they include some ultrasonic or subsonic audio to defeat this mechanism, but it's just an arms race at that point. The phone will start looking at the total power in the audible spectrum to decide whether to kill the app or something.
This kind of thing is infuriating and prevents apps from doing anything outside of the box, stifling innovation and making users frustrated.
I don't think this is true in the later releases is it? I get a lot more ad-hoc permission requests these days, and there's much more control in the application settings (the android app settings, not the settings the app presents).
The Play Store has no requirement that apps degrade gracefully when permissions are denied. So the result is usually the same as pre-Marshmellow. You just get more annoying popups.
I miss Cyanogenmod where I could deny a permission (e.g. contacts) and the app would have no idea it was denied (it would receive an empty list of contacts).
I'm pretty much fine with this, though the data-hostage situation you describe does seem bad.
You're right that from a user control perspective, the cyanogenmod approach is likely best.
If XMPP/IRC can’t provide that, it’s not iOS’ problem.
Basically protocols as a general thing can't work on iOS, only individual apps/services which get to read all your messages and access your login credentials work.
Which I think is a reasonable requirement for a chat service, especially on mobile.
(In fact, why are you running a stream-oriented application over such an unreliable connection at all?)
Weechat and weechat-android are great choices here. Best CLI and Android IRC clients I've used, and I've tried quite a few.
My Android tablet is on a stable WiFi network at home...
It's consistently the last in battery usage as well.
Honestly I don't need the OS to protect me from poorly engineered apps, I just need it to correctly blame the apps so I know which ones to stop using.
No, but the other 6 billion people on the planet do.
I'd guess a FTP and a linux file-server would solve all your filesharing woes as well.
No dev making a mass market device or software should build as if the 1% graybeard engineer is gonna be the only user, that's a lot more user hostile.
Every modern phone today will give you a list of the apps that take the most juice, and yet somehow for some reason people still install facebook. We might need to protect users from themselves.
I don't understand why phone manufacturers need to add features to protect facebook users from facebook. facebook has the money to build an app that isn't shit.
However most phone vendors incorrectly assume "background connections" will drain battery life despite evidence to the contrary.
Phone vendors have a vested interest though in forcing developers to use their proprietary "push" feature for syncing to phones, they say it's for "battery life" but really its about vendor lock in.
A well engineered app can sync over its own TCP connection just fine and not hurt battery life, but then such an app can work on any device, not just blessed Android builds that have access to GCM.
IRC isn't reliant on a proprietary push message API, though (be that provided by Apple or Google).
I'm sure there are long-lived bouncer plugins that will integrate with said APIs, but the core IRC protocol is not suited to or designed for devices that aren't capable of a long-lived connection.
This idea that the end device should do all the work is not a sustainable approach. There should be a server side component that is handling this for you and sending push notifications when your app needs to wake up for new data.
How do you think push notifications work? There isn't some magic in LTE to wake up your phone. Your phone needs to keep a connection open in the background and periodically wake up the modem to check for new information.
I use Conversations (XMPP client) on Android, it keeps a plain old TCP connection open in the background and honestly it does not much battery at all. It's consistently at the bottom of battery usage according to my phone.
It's a lot cheaper to keep an LTE radio on in a low-wattage "ping me if you need me" mode and trust the 'infinite-power' landside terminal to notify you of messages than to wake it up once every N seconds to loudly ping a cell tower "HEY LET ME KNOW IF I HAVE ANY MESSAGES KTHX."
There’s a very distinct difference between having a persistent connection that only transmits data when there’s something notable vs having a connection that constants pushes a kitchen sink of data that may or may not be needed. Sure, if you sent a push notification on every single message and status change on the IRC server, it’d likely use the same amount of (or maybe more) battery, but who does that?
In that case, having the app run the background really does seem like a waste when compared to leaving the OS to do this task.
If you're trying to run standard irc and appear online as much as possible, that's not going to work in iOS without a bouncer to stay online for you and send push messages to send notifications and allow the app to run for a bit to download the messages.
It's probably not a bad idea on Android too, it's technically possible to run as a background service and stay connected, but there's a lot of uncertainty, because other services can crowd you out, and you're at the whim of Google and oems with power management these days.
IRC isn't a well-designed protocol for this use case, and a "land-side" bouncer that bridges the chatty protocol to a lazier protocol ought to be more energy-efficient overall.
... and maybe your own hardware to run them on. But I wouldn't expect any major player competing against other companies to do the work for you when the outcome is supporting some chat protocols that most people don't use.
(Otherwise, if you're expecting vendors to do it for you, you get to expect the lecture that comes with that expectation, in the form of APIs designed to minimize the ease of doing the wrong-for-the-average-utility-of-the-platform thing. Your cell radio could probably be adjusted to operate as a spark-gap transmitter also, but I don't expect them to provide an easy API for that either ;) ).
What I, the owner of my device, have directed them to do.
Apple's approach makes easy things difficult (because one must use their APIs) and difficult things impossible (because Apple have decided that purchasers of their devices shouldn't be permitted to do things Apple wishes them not to do).
I want a general-purpose computer that I own & control in my pocket, not some stripped-down communicator owned & control by someone else.
... the market appears to be making the case that you are not the average consumer, but that's an independent variable.
All android phones I've owned had this option.
As a developer myself, it is just annoying do deal with and just not scalable if you have to explain each user individually how to turn of these "optimizations" (if that's even possible).
iOS's support for background tasks is still shit. This is why some apps have been abusing the location API to ensure that background tasks don't get killed. Apple deserved all the flak it got and it still does.
_Example 1:_ fetch email (without push) for any non-Apple email app will not work reliably, because the app can get killed. You have to rely on Apple's built-in notification support, but this means that a server-side connection needs to be maintained.
As a result, if you want reliable mail delivery without using Apple's Mail, you have no way but to share your username and password with third-party app servers which you don't trust. For example: Airmail or Canary Mail.
Of course, Apple's own Mail has no such restrictions because it is a special part of the OS. This is no surprise however, since Apple has been actively hostile to alternatives for their own apps.
_Example 2:_ backing up photos and videos (with Dropbox, Google Drive, etc).
There's no way to ensure that your photos get backed up without making an effort to keep the app active, in the foreground, with the screen on, or without the app developer abusing the location API, which Dropbox has been doing.
Example 2 should work fine with the background mode declared [2]
Both these APIs are pretty old... is there something I'm missing?
[1] https://developer.apple.com/documentation/uikit/core_app/man...
[2] https://developer.apple.com/documentation/foundation/url_loa...
2. no, it does not work for background uploads, here are screenshots of Dropbox's configuration and Dropbox is not alone in doing this ;-)
Step 1: https://www.dropbox.com/s/b7vylhljg2fwtb8/2019-01-14%2015.02...
Step 2: https://www.dropbox.com/s/c9knz2zz6zs28l5/2019-01-14%2015.04...
It's just a hard problem. App developers are bad, and do bad things. OSes can't protect against all bad behavior. Phone manufacturers do have a vested interest in protecting their users from bad apps. Users do actually benefit from this on balance.
Users don't benefit from lazy ham-fisted hacks. There is no benefit to killing an app without notifying it in any way, or killing a background app that is using 0.2% of available memory and 0.0% of CPU just because it has been open for a long time.
Sigh. There can be on balance. Bad apps get killed, users don't see as many dead phones. A few false positives get killed too, to great annoyance of their authors (and potentially users, but it's mostly the app authors upset here, be honest).
Whether that's worth it or not depends on the numbers involved, not your personal definition for "ham-fisted" or the existence of a better solution.
All I'm saying is that app vendors aren't the only parties involved here, and that the problem being addressed is real, and quite important.
Um.. "The app uses less energy." Is that a serious question?
Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.
For the two minutes between when you ask it to shut down and when you kill it? Even assuming that's a meaningful amount of energy savings (probably not), you could just kill it at the same time as you would have regardless but ask it to shut down two minutes before that.
> Again you seem to be arguing that there are better ways to solve this problem. There no doubt are. That doesn't mean the existing solution doesn't have value.
All value is relative. You can make anything sound good by comparing it to something arbitrarily worse, but that doesn't prove anything. Riding a donkey is better than walking on foot but I wouldn't want to have to travel from New York to LA on one.
The question is whether it's better than the good known existing alternatives, not whether it's better than the bad ones.
There you go: bug turned into a feature.
"It's user error" is a weak excuse if any kind of significant number of users are doing it.
If I force quit an app on my computer, it no longer runs and does things.
I still think of it as user error if they force quit an app but still expect it to run in the background. Why force quit it?
I could see how it could be a UX failure for the OS but I don't think we can blame the dev for that. Apple should clarify what force quit does. I think the advent of webapps that don't really exist on your phone at all also causes confusion: the app has been updated with more content each time you use it, even if it's not running in the background, but to the user that's indistinguishable from the app running in the background.
But it comes down to this: if a user explicitly kills an app, should it keep running in the background?
If the answer is "yes", then what you're really saying is users shouldn't be able to kill apps if the app doesn't want to be killed.
I get that some users don't know what killing an app means but do it anyway for some reason.
But that's not a problem with background refresh. E.g., maybe iOS could warn/explain about the implications of killing an app (with a checkbox so you can opt-out of further warnings).
Edit: just realized I left the word “not” out just above, which reverses it’s meaning
I just don't think it's reasonable to expect the average use to "get" that.
My problem with that is that it kills all innovation and creativity - only the OS vendor can come up with a "new" whitelisted activity. Anybody else is out of luck. Inevitably that means you simply can't get niche applications because what Google or Apple sized company is going to invest in something only 10,000 people might use? I might be idealistic, but I firmly believe that it's possible to both grant power to end users (as in, enable app developers to have a very large amount of control) AND deliver a good end user experience. It requires a lot of good design and discipline and it's definitely hard, but that's not an excuse to give up and hand over all control to the OS vendor.
you may get linux on your hardware but goodluck getting hardware vendors to support linux even on a supposedly "linux compatible" device in any way
> Yes, even Samsung - a dominant vendor in the Android market - is using nasty battery saving technique which may kill background processes and render alarm clocks useless. See below for workarounds.
Wait, do you really need a background task for alarms?
(why) isn't there a system-level service to notify and wake up your app at a pre-defined time or interval?
there is. But, defining services is extremely easy and so people often just roll their own. Plus, it's academic.
The aggressive battery settings of most vendors only interfere with badly coded apps to begin with, apps that use background tasks when they should be using more appropriate APIs.
https://developer.android.com/topic/performance/scheduling
But some tasks do need to run in background, don't they? Specifically, sports tracking apps. Had a lot of issues with those on on various phones; now I simply don't switch out of the tracking app at all while it's running (otherwise, I can never be sure it simply won't be tombstoned in the background).
My S8 seems a lot less extreme in this regard.
This is the best thing for me. Iam fed up of the notification loop of apps that I have to eventually delete.
Thank god for telling me to buy a Nokia next time.
My alarms go off just fine (although I vaguely remember it not going off once or twice a few updates ago), my activity tracker works fine[0] and syncs periodically. I don't use GPS constantly. Signal notifications were also delayed a few updates ago, but now everything runs smoothly.
I find it a worthy sacrifice to make for a sturdy Android One phone with solid performance and a battery that can last two days on medium usage. My activity tracker lasts weeks without charging (comparable to a Kindle).
[0] Worth pointing out that my activity tracker was also developed by Nokia (before they've sold their health division to Withings), so it may receive some special treatment.
Would you mind testing if background file transfers work as standard and with manual battery optimization whitelisting?
[0] https://www.reddit.com/r/Nokia/comments/afkuh4/dontkillmyapp...
If your app wants to run a background service which degrades the users battery, you are degrading the user experience for that user, and all the other apps they use.
Another app on the same phone which is very power efficient will still not get used if the battery is dead!
App developers who use up the phone battery should be required to compensate those who use it sparingly.
Google could set up a market for 'milliamp-hours', where each mAh used up by an app is worth $0.00001c. Apps will put money in the pot (subtracted from ad revenue) proportional to how much power they use, and be handed out to all apps based on app usage (how many hours in the foreground for example).
At this point you discover it costs more to render an ad to the user (and especially to download it) than it pays the app developer ...
Your idea basically means that apps that spam ads can use more power, even if they're used less. And free or paid apps without ads couldn't afford to run at all. How does this help the user?
but no instead we'll probably get fuschia and android will be deprecated lmao
Google has no motivation to make sure that the ecosystem is good as long as they can sell ads and collect user data.