Does this feature affect notifications?
More specifically, could this be the reason I've recently not received Discord notifications for DMs?
Android vendors, don’t kill my app
321–330 of 414 posts
Re: Android vendors, don’t kill my app
#322It is really important to point out when cell manufacturers "improve" Android in a way that breaks apps. They are doing this for the improved battery stat. But if even a few users are dissuaded from buying their headset because it has a poor compatibility rating they will find better solutions. How about a bigger battery or one that can be exchanged? Or a more power efficient phone. Both are possible.
Re: Android vendors, don’t kill my app
#323Earlier quoted context omitted.
So you are saying that behind visible list of apps that are either "optimized" or excluded there is another hidden list where app that is "optimized" could be actually excluded? Ok, that can be a working hypothesis. Why is Skype not excluded the same way then? Or Slack? Millions use them and MS surely has money to promote their app this way. Why Whatsapp is not excluded? It's owned by FB.
There used to be a hidden list. I was the head of android dev for flock , a team messenger and we had gotten in touch with OnePlus who added us to the whitelist. More details here : https://hackernoon.com/notifications-in-android-are-horribly... 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 heavi…
Interesting information. I'm not doubting you here but want to clarify one thing, to understand. After you contacted Oneplus and were added to whitelist, do you still see that your app is showing as "optimized" in the settings but app behavior changed and it is no longer killed in background? And that same is applicable to other major software?
Re: Android vendors, don’t kill my app
#324Counterpoint:
Battery life consumption rarely comes up as a feature bullet-point for an app writer, because visibility on whether a given app is a battery hog is low (both for developers and users). There are a couple of reasons iOS was so draconian about background processes for most of its history, and this was one of them. This ecosystem shift puts pressure back on developers to get creative and ask hard questions about how much energy they really need to consume for their tasks.
One issue is that these first furtive steps in that direction may not be putting the tools in the developers' hands to do that well. But everything in software starts at an early phase.
(It'll be interesting to see whether the market prioritizes battery life by getting the phones implementing these features or app richness by treating these phones as "damaged" and routing around them. This site certainly helps customers make that choice).
Re: Android vendors, don’t kill my app
#325Earlier quoted context omitted.
From a usability perspective, this sounds crazy. Is is responsible of me to recommend Android to my non-technical friends?
It's not a usability problem. It's an option I'm very glad to have. 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).
If you're not a power user and you're only getting one day from a charge on an iPhone, you may want to investigate the health of your battery.
Re: Android vendors, don’t kill my app
#326Earlier quoted context omitted.
Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged. 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?
As TFA notes (in the Nokia section, possibly others): > 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 o…
Sure you can:
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.
Re: Android vendors, don’t kill my app
#327Earlier quoted context omitted.
Getting messages should not/does not have anything to do with running in the background.
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 a…
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.
Re: Android vendors, don’t kill my app
#328Earlier quoted context omitted.
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.
> sending push notifications when your app needs 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.…
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."
Re: Android vendors, don’t kill my app
#329Earlier quoted context omitted.
Can I run XMPP or IRC on an iphone by now or does it still only receive messages when foregrounded?
Slack receives messages with no problem. If XMPP/IRC can’t provide that, it’s not iOS’ problem.
I don't know why you were downvoted; it's a solid-and-concise critique of the difference in protocols.
Re: Android vendors, don’t kill my app
#330Earlier quoted context omitted.
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?
> 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 o…
You've definitely made the case that you don't want an iOS device.
... the market appears to be making the case that you are not the average consumer, but that's an independent variable.