We're trying to figure out the best way of telling users how to change their battery settings (which, for the avoidance of doubt, are usually on by default; and sometimes revert back to default on OS updates); some kind of annoying modal popup in the app before they begin a run, perhaps.
What can I say? These Android manufacturers are prioritising numbers they can put on a spec sheet over the end-user experience on entire categories of legitimate fitness and audio apps. We have no recourse and no way to get on their whitelist. Maybe Google could threaten the manufacturers, but that would be a nuclear-level response.
Yet another thing third-party app developers have to deal with.
The best way to do that is to remotely figure out on which devices the app is getting killed by sending data push notification messages and an in-app ack mechanism. And then show users an annoying popup message the next time they launch to make sure that they whitelist the app. We faced the same problem while building Flock, a team messenger and the details are outlined here.
Background services management was let loose in Android till 6.0; with doze mode & Job scheduler it has vastly improved.
I think manufacturers shouldn't start killing apps themselves, as shaming apps which abuse background services, eat power inconsistently by displaying notification & allowing user to 'force stop' the app themselves does the job as in OxygenOS.
For all the flak iOS gets regarding multitasking, I was impressed by their uncompromising attitude towards background services from the start, even when I was bashing my head during iOS development to implement features on par with android version. The background operations should be completed within 3 minutes, but there's no guarantee that it will not be killed before that!
That seems to be exactly what TFA notes in various per-manufacturer segments (the color blocks with poop emoji are clickable and provide manufacturer-specific information and complaints) e.g. for Nokia:
> every [background] process gets killed after 20 minutes regardless it is actually supposed to be running and doing a useful job for the user.
or for OnePlus:
> Not only did users need to enable extra settings to make their apps work properly, but those settings even get reset with firmware update so that apps break again and users are required to re-enable those settings on a regular basis. […] On some OnePlus phones there is also a thing called App Auto-Launch which essentially prevents apps from working in the background.
Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?
> This app kills apps in the most brutal way we have seen so far among Android vendors.
You can't detect that your application was kill -9'd. I don't think you can detect that "PowerSavingAppG3" is running either (I'd guess it's running as root and you're not), so you can't even infer from its existence that your application will be traumatically killed in short order.
Both would show a last good status and no good exit.
1. Create an empty file when the application launches
2. When the application terminates, write the reason for termination into the file.
3. When the app launches again, read the file. If it was empty, then you were SIGKILL'd, or you crashed.
"Might have been killed, might have crashed" is not helpful, and the inability to know is the very issue at hand here. You can't know whether your application crashed, the user forcefully killed it or you fell afoul a background killer. What now, do you start spamming the user anyway?
You might be able to write the word "bad" in a file, and then clear the file if your app closes nicely. If you start and find the word "bad" in the file, then you know you were killed. A slight variation of what you suggested.
Details outlined here : hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a
onCreate - check "running" flag, then set to true
onDestroy - set flag to "ended"
If onCreate saw the flag was already "running" before it was set, then you have a crash to recover from or a kill to notify the user about.
The point is that this is entirely Google's fault and yet it's the devs who have to clear up the mess and take the blame, or alternatively we bombard the users with technical fixes and explanations. Quite clearly neither of these options is where we should be with a mature OS on a mass consumer device.
Now I'm getting all angry again just thinking about it. Time to up my meds.
The third party controlling your user's experience is forcibly killing your application while it's in use as intended. This somehow means you are misunderstanding UX?
People are suggesting ways to detect it and teach the user how to stop it, because they have no automated solution to this problem.
What misunderstanding would that be exactly? App developer has to find a way to help customers work around an issue they cannot resolve themselves. Seems reasonable to me.
Pulling the nuclear option for something with clear workarounds (or which only impacts peripheral features) is unacceptable.
Eg. Blocking legit services and obscure errors popping up.
Ps. Love zombies run
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.
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 
Both these APIs are pretty old... is there something I'm missing?
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.
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.
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.
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.
(In fact, why are you running a stream-oriented application over such an unreliable connection at all?)
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.
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.
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.
My Android tablet is on a stable WiFi network at home...
Weechat and weechat-android are great choices here. Best CLI and Android IRC clients I've used, and I've tried quite a few.
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 ;) ).
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 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.
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.
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.
All android phones I've owned had this option.
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.
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.
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...
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).
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.
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.
They would find a way, because money.
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.
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.
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.
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.
I think about 1/3 of all our support requests are about the app being killed in the background on specific phones. The part of the app that does the actual scheduling of the alarms is a big mess with lots of device & API level exceptions. Debugging alarm problems is a nightmare.
We often advice users on what phone to buy and tell them to avoid specific brands. Sometimes users even need to buy a new phone to be able to have reliable alarm signals.
I understand why manufactures are doing this. But it really degrades the user experiences for our users quite a bit and is a significant cost (in terms of support load + extra development) for us as an app vendor.
Really hope that Android 8+ incentive manufactures to just use the standard Android mechanisms: they seems to work quite well in my experience. You can run things in the background, but only if it has a user interaction as a result: i.e an alarm notification. The user can then determine if this is wanted or not directly from the notification itself.
Unfortunately it is not much better on the Apple side of things with local push notifications limits.
I really don't. User has power to uninstall or replace app that is in his opinion using too much power. There is no need for manufacturers to intervene. They should only display warning about app using too much power. But it seems killing app is so much easier for them.
If Samsung kills the apps, the app maker gets a bad review. If Samsung doesn't kill the apps, Samsung gets a bad review. I know which one I would pick if I was Samsung. At that point it's up to the user to decide if that choice is something they want to subscribe to.
that's why I mentioned, they could display some notification when app is using battery heavily (similar to ANR).
>The majority of people don't know how or even want to be an administrator on their phone.
Exactly same thinking as those device manufacturers. user = idiot (let's kill apps for him, what could go wrong, right?) This kind of thinking brought us here.
However, the implementations of the API are questionable.
Some calls to that API on some OEMs device round alarms to the nearest minute, some to the nearest ten minutes.
WHY? What benefit does that serve?
Having lived in China for a few months with an Android phone I can with absolute certainty tell you that this is needed over there. The amount of garbage apps, even from big companies like baidu is enourmous!
And without a Google playstore, or play services, or play safety thing it is an absolute wild-west of background alarms, API calls, battery draining and whatnot.
Like are apps setting alarms for every 3 seconds or something for no reason??
Not literally "alarms", like the ones that ring?
Without this restriction, how long before an app maker schedules their alarm every millisecond?
Edit: It's become the new '911'... Family Guy Joke!
Also some manufacturers cancel alarms when the user swipes away an app (which some users do constantly to keep the recent apps list "clean")
I appreciate that in some cases apps need to be in the notification bar in order to remain running. I also appreciate those like Tasker that have the option to hide their icons or use "empty" icons (so nothing shows).
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.
There is a quite clear usage pattern to support this behaviour: unless I explicitly say so, I don't want apps on their own to "do stuff" no more than I want my Ubuntu to "do stuff" while I'm doing something else. I only want the application to respond when I'm viewing it.
On Ubuntu, I always disable stuff like evolution server and automatic indexing after a fresh installation. At least you can do that on Ubuntu, that isn't necessarily always possible on locked-down systems. I'm happy that Android is quite usable these days because of Doze and background task killing.
Hell there are comments in this thread testifying that these built-in "battery savers" even kill the built-in alarm application.
is this a bug that sometimes happens? how rare is it?
Alarm scheduled wakeups get rounded to a minute in power saving mode though.
You using Ubuntu so you’re fine with wasting time setting up stuff that’s just supposed to work, but most users are not
Case in point:
I have a galaxy S9 but there should be the same or similar setting on yours.
I think the problem is, that many users do not know which apps require more energy due to the specific problem they solve and which apps are just badly engineered. So to let the user decide every case is a bad option (+ decision fatigue). Letting the developers decide is even worse, as they would simply say, that their app requires as much energy as they need. So the vendor thinks he has to make that decision (as they don't want their phone to being perceived as having a bad battery life), who neither knows anything about the specific app nor about the use-case (probably the worst option).
I think the system should simply report battery offenders (above the threshold of a well-engineered instant messaging app for example) to the user in a manner of 'App X used Y% of your battery in the last 24 hours. By limiting the battery usage, the app might not function as it is supposed to be. Do you want to limit the battery usage of this app?'
That way, most developers would have a chance to build good apps which do not get reported and users would stay in control.
I am pretty sure that my stock Android 8 is doing that already
- Skype - always killed
- Slack - always killed
- Whatsapp - sometimes killed, rarely
- Telegram - never killed
- FB Messenger - never killed
All these are fully featured apps with tons of different functionality.
Telegram and FBM never ever trigger "this app is draining your battery" while Skype triggers it regularly when I sometimes start it on phone.
I'm going to generalize and say that probably some apps are simple bad and need to be fixed instead of granting them exceptions and allowing to be battery hogs.
Though they were moving away from that model to a model where apps alive for more than a certain time interval in background were killed. So apps which you use the most heavily are more likely to be penalized.
This isn't climate change debate, it's easy to check.
If you aren't facing issues then these apps are probably already a part of the whitelist on your device.
The system you’re saying “evolved out of the manufacturers”, runtime permission requests, is from “core Android” all they way back at 6.0
And the problem has almost never been users blindly revoking permissions, it’s blindly granting permissions.
The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission.
And Android already has built in “active” battery management with Doze, if anything manufacturers are ruining it with poorly coded “optimizers” that do dumb things like kill their own alarm apps...
And even if Android did add a permission to allow an app to do whatever it wants in the background and kill the battery as much as it wants, manufacturers can’t be bothered to write optimizers that don’t kill a music playing app while the user listens to music, why would they bother respecting a permission they didn’t make?
If I wasn't clear, this is what I meant. Users ignore and accept permissions blindly on install.
> if Android did add a permission to allow an app to do whatever it wants
I'm not suggesting this at all. I'm suggesting that permissions systems, as granulated as they are, only make sense to developers and are mostly ignored by users.
> The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission.
I agree with the parent comment on this. Some permissions queries should be available on first use, rather than (or in addition to) on install.
This sounds like it should be an app permission: is this app allowed to run in the background or not?
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.
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.
Slack would be fine, I guess.
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.
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!
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.
1. They are not enabled by default
2. Their settings screen explicitly states what the modes do
3. They can extend battery life significantly
The most aggressive mode is called Ultra Stamina, and it works by basically turning the phone into dumbphone mode -- complete without any internet connectivity, calls, SMS and alarm clock only -- and the phone has no problem lasting a week.
I use these modes extensively when going backpacking for several days, as I do not have to carry any power banks, which saves precious gramms :)
edit: punctuation, grammar
Calling Sony "toxic" for including a useful OPT-IN feature to extend battery life? Pfff...
Of course, then you have the issue of finding a quality midrange or higher end phone with a removable battery in the first place. They are an endangered species due to the thinness war.
I prefer external charging bricks -- if you upgrade your phone, you might need to buy a new cable with an external brick, but you are more likely to need a replaceable battery with a new form factor or output.
The way I read GP he disabled everything except calls, SMS and alarms.
Which kinda makes sense, you want something for authorities to track you in case you end up missing and unable to call for help yourself.
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.
a) I wholeheartedly want this behaviour. The phone lasts 2-3 days without recharging, and I no longer fear leaving home with 30% battery.
b) It's not an app that kills background apps. It's Android's own Background Activity Manager, where apps that are not whitelisted can't wake up the CPU. They run only when the CPU wakes up for some other reason (screen-on qualifies but it's not the only opportunity).
I had to get used to it. In one instance the alarm didn't wake me up, because it is not whitelisted to wake up the CPU. After enabling the correct apps, I maintain pretty much the same great battery life and all app functionality I want.
My grandma is 89 now, she uses Whatsapp, Youtube and whatnot and I am not kidding but within 2 months she had:
- AVG antivirus (an ad told her she had a virus)
- She had batterylife for 7 hours before a charge was needed due to shitty apps
- Ads on her lock screen?!
- Ads on her homepage
After 6 months and 3 house calls to fix her phone we gave up and she got my aunts old iPhone 5s with a new battery.
It runs iOS 12 now and it runs flawlessly and protects her from all the stuff I mentioned.
From a guy that has always had Android: most users need iOS level protection. Just simple facts.
*Speaking in terms of launch MSRP.
The important part was that the 4 year old iPhone 5s had the latest iOS and still works better than a new €250 Android.
I wonder how they'll deal with the new gesture nav (both iOS and Android), because I think that's possibly more confusing to a layman.
If you disable the background activity manager, under Settings | Battery, you get the same battery life you do on iOS (about a day, give or take).