This is one of those subtle ways the Play Store protects its monopoly. Sure, you technically can install an app without using Google Play Services, but notifications won't work.
But to not be misleading, that does not mean you will not get notifications in apps that need them. The F-Droid version of Telegram will still notify you when someone writes you, and mail programs will still show a notification about incoming mail. There are alternative solutions.
And there is microG, to hook into the Google way of doing things.
How do Chinese users get around this problem? I don't have Play Services on my phone and Telegram notifications work just fine (because it keeps its own background connection anyway). Maybe they're reinventing the wheel in every application like Telegram does?
This is the most significant hurdle to do proper decentralized smartphone applications today. Me and some friends were sketching on something that could be used for grassroots movements and peer-to-peer marketplaces - push notifications is the one thing making it practically untenable.
I still see apps that poll from time to time. Most of them require keeping a notification active to prevent their service from getting shut down. Surely under such a regime you could send a "push" notification to the phone. Not sure how easy it is to listen on android though.
As in, you can pop up a notification from local events? It did several years ago the last time I programmed on it. I'd be surprised if it didn't today. But a poll->local notification isn't technically a push notification.
It does. You have to keep one running (with it being impossible to dismiss) if you want to prevent your application from being shut down. That's what GP is talking about.
This is not a great analogy... Games require your immediate attention so you know why you are killing battery life and accept that fact. Services that run in the background are invisible and will drain your battery over time. In some cases this is normal required behavior, but if everyone were to have their own background process running your device would become useless very fast. These seemingly draconian policies have to protect likely outcomes as well as edge cases.
That’s something that is hidden from users, they put their phone in their pocket and two hours later their battery charge is substantially diminished. They don’t understand why or how to stop it.
They know playing a game for hours straight reduces battery charge.
You're posting shallow dismissals while seemingly having no idea what you're talking about.
The complaint about location in the article is about Google's tendency to bug you to turn on GPS and leave it on, happily draining the battery but for Google's own surveillance purposes. Having a GPS fix is not a requirement of the cell network.
Cell tower triangulation is something the network can do as a result of your phone connecting to cell towers. While connecting to a cell tower is mandatory for cell communication, an open baseband could make it a point to only connect to one tower at a time (although a single tower will still have some location information due to sector antennas).
> Hey Google, why not shutdown location and frequent play service updates as they aren't helping my phone battery either
Doesn’t mention GPS. That may be what the author meant, but certainly could be written far clearer.
Still, Google isn’t using GPS all the time, their power management strategy can’t allow that. It’s likely only using it when its deemed necessary. Android is tuned to balance offer users the most functionality possible with longest battery life. If it did not iOS would destroy it in battery life tests.
Triangulation is necessary to determine which tower to connect to and when to switch to a new tower. It’s why they are called “cellular” phones.
> It’s likely only using [GPS] when its deemed necessary
The entire point is that Google encourages you to leave the setting on, meaning you'll be doing GPS fixes more than what the user actually considers necessary.
> Triangulation is necessary to determine which tower to connect to and when to switch to a new tower.
No, it's really not. It's hard to even figure out what you're trying to describe here.
Yes, the baseband sees the signal strength from each nearby tower to know when to switch between them. But the baseband doesn't itself have a map of cell towers. If the list of visible towers is used for client positioning, it happens on the application processor. The work of deriving a location from the towers is not necessary for cell network communication.
Your points on the actual details of what how cellphones work is exactly right, but it’s trivial to calculate location from those values. My point was that your phone is not powering up any additional hardware, or doing anything extra in software to burn battery life to estimate your location, the information is already there. The phones application processor is already monitoring them if only to keep your radio strength meter display accurate.
And Google should encourage you to keep GPS on if they do a good job managing its power usage. Users aren’t always going to know when the app they are using is going to work better with more precise location data. This is a user friendly feature.
Circling back around, the author is still wrong that allowing installed apps to run unrestricted background network processes is anything like the OS carefully managing location accesses to minimize power usage.
On the other hand, when I used Android (2010s), I remembered using tools that required root – or even custom OS builds – just so I could prevent apps (like Facebook) from running in the background and draining my battery doing who-knows-what network activity. In this case, I much prefer today's heavy-handed platform restrictions on background processes to yesteryear's permissive but perpetual battery-drained Android ecosystem.
Surely they could have put in a switch in a sub sub sub menu that allows the user to still have the freedom to have apps with background processes though?
The thing I hate is megacorps slowly infringing and removing device/OS freedoms in the name of some stated "good cause" (security, malware prevention, battery life, etc.).
I don’t see the authors point, battery life is important. A phone is not a Unix server or a desktop PC. This is the same reason iOS doesn’t allow apps to have arbitrary background execution time.
And phones know your location virtually 100% of the time because of cell tower triangulation. That’s part of being a phone, not a google hypocrisy.
You can leave a socket open in the background (although you do need a periodic keep alive but the period can be pretty long.) to receive push messages without draining the battery (as long as the server doesn’t spam it.).
The real problem is pushing everyone towards unconfigurable closed software that would otherwise abuse full access to the device. Because people can’t trust what they run on their phones the apps can’t be given any more privileges than a random web page.
People can't trust it anyway because most people are not developers, programmers or able to read code, debug binaries or even have a concept of hardware and software.
The solution on more open OSes is to require apps to publish their source code and engage with the developer community before making them easily installable. (Ex: most Linux distributions)
Solution to 'what' exactly? Unless you require all users to also be software engineers before they are allowed to buy a device that's not really solving anything, is it? Shifting the point of trust around changes nothing, and you can't shift it to the users because they are users, not developers.
The answer (even as politically unpopular as it may be) is regulation. Either the industry should come up with their own regulations (like the ESRB for video games) or the government should come up with regulations (like GDPR). That’s how every industry levels the playing field for consumers who can’t actually be as informed as they need to be (or don’t have a choice even if they’re informed).
Unless everyone is a software engineer and can read the code of all the software they’re running and where their data is going, “open source” isn’t going to fix the problem. And expecting everyone who uses a phone or computer to know the details of its software implementation is highly unrealistic (even as a software engineer, do you know how your doctor’s medical billing and coding software works? Unless you work at Epic, probably not). So there needs to be some regulatory body who actually is informed and can certify that software companies are following the rules.
I trust Apple more than I trust a regulator. Apple has to respond to customer preferences, a regulator can force them to make the user experience worse for things the customer doesn’t value.
Now do I trust Google more than a regulator? That’s a much closer question.
1) if a class of users can’t be trusted to evaluate software in even the most basic ways then they shouldn’t be allowed to install native apps at all. At this point PWAs and smartphone apps have equivalent access (except on iOS.)
2) I was arguing for shifting the point of trust to volunteers from the community. In particular I was thinking of the Debian project but there are other examples.
> You can leave a socket open in the background (although you do need a periodic keep alive but the period can be pretty long.) to receive push messages without draining the battery (as long as the server doesn’t spam it.).
This only works on a platform where apps can run in the background indefinitely. Small memory, limited CPU, and battery life means apps have short life-spans on phones.
This is why there is a push notification service for mobile platforms.
The author was complaining about Google running a daemon in the background to track current device location, which is a necessary part of it being a phone.
What Google does with that info is an entirely separate issue.
And please let me know when Google or Apple starts advertising their phones as Unix servers and tout the ease of installing HTTP servers on them. They are sold as phones and that makes security and battery life critically important.
I'm afraid the location daemon must have went a bit over my head. What part of such a daemon is necessary for a phone? Did Nokia 3310 also have such a daemon? "What Google does with that info" - does this daemon send data back to Google?
> And please let me know when Google or Apple starts advertising their phones as [..]
Circular logic. They chose to lock-down and hobble phones, and because their advertising doesn't include user freedom, you think that makes them justified in infringing on that freedom? Especially when they pulled every anti-competitive trick in the book, and invented a few new ones, to kill any competing phone OSs?
Yes, every cell phone has something like this daemon. Google “cellular phone” to learn how cell phones need to triangulate nearby cell towers to determine which offers best service, and when to switch to a new one.
Please let me know when a phone manufacturer starts advertising the benefits of user freedom such as rampant malware stealing your personal information, dropping calls and bricking your phone.
The first iPhone didn’t allow apps at all. When it was introduced the expectation for phones were they were safe and secure. If the iPhone wasn’t it would have failed. It’s like you are arguing automobile manufacturers don’t advertise that their cars are safe to drive, so obviously it isn’t a feature important to customers.
And anyone can compete with a phone OS. You can fork Android for gods sake.
> Please let me know when a phone manufacturer starts advertising...
They're advertising smartphones, not just phones. And the expectation of what a smartphone is is defined entirely by the Apple/Android duopoly. So even your claim that smartphones imply locked-down is circular.
> benefits of user freedom such as rampant malware stealing your personal information, dropping calls and bricking your phone.
So you're just choosing to ignore linux? And are you seriously using "stealing your personal information" as a contrast to what Google has been caught doing with Android? (Or MS with Win10, if we go beyond phones).
> And anyone can compete with a phone OS. You can fork Android for gods sake.
But I'm sure you'll be able to come up with more reasons why only giant multinationals should have a say in how smartphones work. I'm glad your kind wasn't as prominent when PCs were getting off the ground, or we'd need special developer licenses to run compilers, and anyone that complained would get shut down with "Intel/AMD don't advertise hacker boxes, but PCs!"
And your only argument so far has been "Smartphones don't respect user freedom because we don't expect them to. We don't expect them to because they don't.", with a dash of the freedom-security false dichotomy thrown in.
It's funny how he's even imagined implementing his own push server. Only because Android. On iOS people have already taken for granted that you must go through APNS.
Also, this is not just about push. The problem is that Apple and Google de facto own the edge user interface: phones.
One of my friends has one of these and says it's horribly unstable and the LTE usually doesn't work. I imagine there's still a lot of work to be done to make it usable for technical people, much less non-technical people.
It's because Apple's contract with developers was always a tightly limited execution context, sometimes things get added or taken away, but the shape is the same. Background execution was originally forbidden and is now tightly regulated.
Android has moved from a mostly unrestricted environment to one that's pretty restrictive. Which means things have been taken away, and things that would have worked in gingerbread can't work today. And it's big things with reasonable use cases too: background exection and network access used to be pretty reliable (minus wifi tended to turn off with the screen), now it's not --- if Google push doesn't work, no notifications until the user starts the app or Google lets you run; you used to be able to use a usb camera from an app, now you can't with latest Android, so keep an old phone for inspection cameras.
I understand unfetered background execution is problematic, but it's also useful.
Not if you have an ISP, that won't ever support IPv6. There are a lot of us (in the US) in that boat. It's hard to play with unavailable tech.
edit: removed stuff about Push via SIP, that might be too incorrect to be helpful.
Also removed some pondering about trying msg.exe over IPv6. I was probably fishing for trouble there.
They're going to have to move to IPv6 : with Europe running out of IPv4 addresses, and a lot of third-world countries never having had enough of the in the first place, soon enough an IPv4-only connection won't be considered a real Internet connection any more...
This is mostly about mobile devices, where IPv6 and/or avoiding NAT don't solve the main problems.
You'd need mobile IPv6, and background applications that don't get killed while listening to a socket. As far as I know, neither of those are commonly available.
It's a standard, but it still requires a push service, aka FCM. It's not like the web browser is listening on an open port and the server is connecting to it. eg. if you go to https://gauntface.github.io/simple-push-demo/, you can see that the endpoint is fcm.
This is for locally generated notifications only. Push messages are different, last time I checked Mozilla operates a free service to relay push notifications.
I suppose the OP should comment, but I read that although local push was tried there was a wider view about using walled services. the Push API does solve that.
Apple is even worse. There is a singular service, there’s, and using it costs $100/year. Rate doesn’t matter ... and Mozilla can run theirs for free.
I’m just glad my pinephone shipped and everything on my phone actually makes sense now (even if I have to compile things and write a few config files.)
Apple has an obligation to its customers to make their phones work as well as possible. Customers complain all the time about mysterious battery draining behaviors, and blaming various apps. Having millions install some cool new notifications service without realizing it’s actually a battery draining service just multiplies those problems.
> Having millions install some cool new notifications service without realizing it’s actually a battery draining service just multiplies those problems.
This is pure FUD reasoning though. You can’t say “no you can’t have that because it could possibly be bad trust me” without any evidence that it would be a major issue. The more locked down a phone is the more people need Apple/Google.
It’s not FUD and it’s not without evidence. What you’re describing was the actual reality in handheld computing before iOS.
Look at early Android or Windows Mobile or Palm or heck even your own modern-day laptop. Battery-draining background applications aren’t FUD and don’t require any additional evidence because that’s the reality on basically every platform except iOS and modern Android.
But at the same time there would still be review processes that could detect such apps. This is just assurance on Apples part they don’t have to babysit devices, not some huge benefit to the consumer. There is a consumer benefit but a small one.
In the past you could run any push service you wanted, and battery life was worse with many apps. There's also another current (/recent) example on this post https://news.ycombinator.com/item?id=24462028.
> An alternative is requiring developers to engage with the community and convince them there’s no ill intent.
This is a pretty tough alternative. No developer is going to say "I have ill intent here"; are you confident you have the ability to make that decision on your own? I'm not confident I do. I can't look at the code of most of the stuff I run on my phone. Some people would say "then stick to all open source software," but I don't have the time or expertise to audit the code of all -- or even most -- of the applications I run. Maybe other people will, but there's no guarantee they'll find anything bad (whether malicious or just buggy) very quickly -- and we're talking about cloud stuff here, which means there's a server none of us can audit involved in the process.
Apple and Google having "blessed" push notification systems is certainly a tradeoff on multiple levels, from it being a single point of failure to being another server you can't audit and a single company you have to trust to at least some limited degree. But having the notifications integrated at the OS level reduces the number of people and systems involved in delivering those notifications, at least theoretically reducing the number of bad actors -- and, as many people have observed here, also lets these notifications be optimized for battery life in a way that's probably not possible if you have dozens of apps running their own background processes rather than simply asking to be notified by the system one. The alternatives are a different set of tradeoffs. That doesn't necessarily make them worse, but it definitely doesn't automatically make them better.
> And where is the option for those of us who don’t mind less battery in exchange for actually getting prompt notifications for services we use?
The alternate scenarios give you less battery, but don't guarantee actually getting prompt notifications for services you use, do they? They just give you different points of failure. Actually, they might even give you the same points of failure. When a DoorDash notification shows up on my iPhone late -- or as it did the other day, inexplicably 20 minutes early, leaving me standing in Silicon Valley's smoke-filled air quizzically looking for my chicken order -- is that Apple's fault, or is it DoorDash's fault? After all, the notification isn't starting on Apple's server. If the problem is with DoorDash, which the early notification had to be, then if DoorDash could bypass Apple's notification system all that would give me is an incorrect notification delivered with fewer network hops.
> And where is the option for those of us who don’t mind less battery in exchange for actually getting prompt notifications for services we use?
You always have the option to build your own phone. With easily available components and open source software it’s never been easier. And with cheap and flexible Chinese manufacturing, Kickstarter and Patreon it’s never been easier to manufacture your own phone design.
Otherwise, your demands don’t reflect the needs of the vast majority of Google and Apple customers. The world doesn’t revolve around your unique desires.
> You always have the option to build your own phone.
That sounds factually false to me.
Seems to me that I can't do it. Others have tried, how's that going?
For a start I don't think the components are easily available. Both software and hardware.
> "With easily available components and open source software"
For me the modern definition of a phone is "a device that can make voice calls, message people on their required messaging network, and give me access to my bank accounts".
I don't think I can actually do that with easily available components and open source software right now. It would be interesting to be proved wrong.
Steve Jobs couldn’t build a phone. But he could build a team that could build a phone. You don’t have the resources of Apple (he didn’t at the start either, just Woz), but you have Patreon and Kickstarter.
The main difference between you and Steve Jobs is he didn’t waste his day complaining in the internet about problems, he actually did something to offer solutions for them.
The Pinephone is lovely, but it cannot provide what I defined as a modern phone, unfortunately.
I cannot message people on their required messaging platforms, and I cannot access my bank account with it.
That means if I used a Pinephone I would need to carry two phones.
This is not someone "complaining" as though to do nothing. It is someone stating the current situation and what needs to be changed.
I would dearly like to change this, but your suggestion implies that it's realistic and easy, which is far from the current truth.
> Steve Jobs couldn’t build a phone. But he could build a team that could build a phone. You don’t have the resources of Apple (he didn’t at the start either).
For the same, simple definition of a modern phone, another gigantic company, Microsoft, tried and failed. It really isn't easy.
Microsoft failed at smartphones because they didn’t offer a compelling unique benefits to the marketplace.
Why not add the missing features you need to Pinephone? It just requires writing software. I’m not going to blow smoke up your arse and tell you that you are going to find a large market, but you could make something compelling and unique to a large enough audience to fund through a Patreon or Kickstarter.
What I will tell you that while every entrepreneurial activity I’ve started has not succeeded, (in fact most have failed), I’ve learned valuable things from every single one. It is one of the greatest ways to learn new technologies, markets and skills.
> Why not add the missing features you need to Pinephone? It just requires writing software.
No, it does not "just" require writing software.
- Potentially writing software and reverse engineering will allow me to message people on their required messaging platforms. Matrix is getting there. Maemo on Nokia N900 was excellent at this, but that was a different time; messaging has become more complicated since then.
But, though I'm a fine software engineer, it is not feasible to write software to provide all the features I defined as essential in a modern phone:
- No amount of writing software will allow me to access my bank account, which requires an Android or iOS app on an unjailbroken device to the best of my knowledge. No, a web browser does not work, it must be the app (crazy but true). Yes I could reverse engineer and crack the existing app to port it, but that would be foolish given the application.
As I said, I would love to be proven wrong on this.
Obviously I could switch banks, although that's not without its own difficulties and arguably if I have to switch banks, the new device doesn't meet my definition of a modern phone.
The problem is not a software-writing problem.
This is what I meant by Microsoft couldn't do it. Even though Windows phone was pretty good, it wasn't enough to be pretty good. It needed the essential apps that only 3rd parties could write, and not enough 3rd parties decided to write them. That was not in Microsofts locus of control, just as it isn't in mine.
Eventually things may change, if Pinephone and its relatives become more popular or if fashions change. But not at the moment. At the moment, if I got one I would need to carry two devices. (I had two Nokia N900s btw, I'm no stranger to open source phones.)
Until the PinePhone gets 5Ghz, its unusable for me. I live in an apartment and 2.4Ghz has like 15% packet loss and only has 2Mbps downloads with stuttering and slow loads.
> Apple is even worse. There is a singular service, there’s, and using it costs $100/year.
You say this like it's some egregious burden. Compared to the cost of building an app and shipping it $100/ year is a fraction of a drop in the bucket. It's less than 1 developer hour.
If you are capable of building an app with push service, the cost is trivial. If you aren't capable, it's irrelevant.
$100 is actually a really big deal in developing countries and lower-income areas. How many of us started working on software to experiment with for free growing up? Arbitrary cost barriers like this are honestly an impediment to learning, and in my opinion, even harmful to Apple in this case. Why wouldn't they want more people to learn iOS programming and Swift programming.
The cost to learn to program on Apple's platforms is the cost of an iPad or Mac. The $99/ year is only required if you want to deploy an app to the App Store or use Apple's cloud services.
You can use a mac from school or work and iPhones/iPads are as low as $300-$400. But paying $100 just for trying to publish an app is not worth it for many people. Android and Windows stores have lower and regionally adjusted prices.
I will get downvoted for saying this, but I don't care: STOP defending Apple. The amount of egregious things Apple has done over the years is amazing. Not only do they charge developers for publishing apps EVERY year, but they also make up arbitrary rules in the name of "Privacy" or "Better user experience". Oh Please. You want to give people Privacy? Use open protocols for your shitty iCloud so that people KNOW just how much data you are are giving your Siri-shit voice assistant. Want better user Experience? Let me transfer music and ebooks to MY iPhone without having to use your joke of software called iTunes. And trust me, I used to be a big fan of theirs. But after they started glueing everything to their "computers", I had a wake-up call. The macbook used to be a great product, and then they started glueing everything to it and shoving the iCloud into it. Slowly, they killed their own product.
So please, stop defending them. They are doing really shitty things that will just become stains in computing history.
I'm not "defending Apple" here, I'm pointing out simple economics. A typical app costs upwards of $50,000 in developer time to build. Even if you are building your own app, we're talking about a person with valuable skills investing months of their personal time. This idea that for a typical developer $99 is a huge burden is just not an issue.
This is true if you love Apple or hate them deep in your soul for a million burning reasons.
And not everyone lives in the US. How much do you think it costs in USD for an app developer in a developing country to create an app, and how much is that $99/year as a percent of yearly income?
The ability to just develop and deploy experiments to the wild was one of the greatest propellants of my career when I was younger though.
If I started my career in the current era, there is no chance I would have been able to afford to develop in the Apple ecosystem (not just yearly subscription, which is crazy to me, but also the cost of the hardware as you point out).
This is true enough in the US, but is prohibitively expensive in a ton of markets worldwide (maybe half the world population). Then again, the requirement to have a Mac to develop iOS apps is even more financially onerous...
I'm really curious how Push Notification, App LifeCycle, Localisation Services, Background App/Services, etc. are going to be implemented on Linux phones.
Is each app going to be killed when not in foreground ? Or are they all going to keep running ?
Is there going to be special API for background download manager, notification listening, music playing, etc. or is each app going to keep running in background and do its own stuff like on Desktop ?
For Google & Apple things are super easy : they do what they want.
But For Linux Phones, people from KDE, Gnome, Wayland, Purism, etc. will have to agree on services & APIs which might take lots of time
It might work to generally limit CPU and network resources usable by processes not actively foregrounded in the GUI. Linux cgroups is good for this sort of thing.
A bit like some browsers do to timers in non-foreground tabs.
It would simplify development quite a bit if this solution ends up being sufficient for battery life. No need to think about onCreate, onResume, onPause, onStop, onRestart , etc. like on Android.
But RAM might also be a problem if the phone keeps everything in background & isn't allowed to kill any app when it needs to
The phone is suspended when the power button is pressed. Reciving network traffic (ex responses to IDLE on an open IMAP connection) wakes it up and there’s a service that suspends it again fairly quickly if the power button hasn’t been pressed. Another service manages an RTC alarm so that programs expecting pushed data can reestablish sockets if they die (since that won’t necessarily wake the phone.) The only disadvantage to this scheme is that there are more keepalive messages sent (so you should limit the number of services expecting push messages to just a few.)
Mine runs a normal X11 DE (fluxbox) so the apps run in the background just like they do on my laptop. If something wakes the phone up too often just kill it.
I’m still working out the kinks but it seems to get decent battery life this way. No need for some special API.
How can you listen to network events while being suspended ? I thought that on linux suspend = all user processes stopped. Does it somehow wake up every nth second to check if there a new message from the network ?
Another pointlessly aggressive rant. Like it or not, FCM provides unified push mechanism, aggregating communications for every app using it and ensuring least resource usage . Open Push, or whatever it would be, will need to make sure all apps used same server(s) and, preferably, single connection kept alive, otherwise some apps will get notifications , others wont, and it will be seemingly random.
It's currently on the main page of Hacker News with 61 points and lots of attention turned to it. Sadly, as long as people find this needlessly aggressive tone appropriate, we'll keep seeing this kind of stuff everywhere. It's like clickbait, fewer people would click on this if this was titled 'I have some issues with cloud messaging', I know I wouldn't.
Ever tried to send a push notification to your phone? How hard can it be? - At least locally, KDE Connect(https://kdeconnect.kde.org/) got you covered.
One of the more insidious things Google has done here is that they force you to use the Firebase SDK to implement Cloud Messaging / Push Notifications.
This SDK has "Google Analytics for Firebase" enabled by default, and they use dark patterns to make it seem like having Analytics enabled is required: https://imgur.com/a/Nk2KhFo
Of course, if you do enable analytics, then Google sucks up your customer data (including in-app purchase behavior!) for their own data collection and advertising purposes. Also, you're required to tell your users this is happening, but of course developers don't know this. (More dark patterns in how Google reveals that they steal your analytics data for themselves: https://imgur.com/a/R0K71Zn)
When you go to add the SDK, Analytics gets added by default. The setup flow makes it seem to be required. But also the previous screens (when creating a Firebase account) appear to imply that Cloud Messaging won't work correctly without analytics.
> Instead, they have this warped reasoning where they don't allow any program to run in background, except theirs, "to save the battery".
Looking at the landscape of shit software out there, I find this justification entirely plausible. If iOS & Android didn't lock this down, phones would be running 4-5 different poorly implemented push platforms (or more). Battery performance on mobile would be utter crap.
There is a big balancing act going on here. People want phones that do the thing they are supposed to do. They also want battery life to be excellent and the device to be secure by default. It's impossible to give 3rd party devs 100% access and meet those 2 demands.
How many end users prefer to adjust their phone background CPU activity alert threshold just so that some developers can use a different push notification framework?
This reads like a comment written by someone not aware of the depth of the problem.
The post is Android-centric because in typical Android fashion, a passable concept is implemented is the most disjointed way varying scross devices.
Limiting excessive background communication? Thats a good thing.
Killing useful apps like media players in the background repeatedly until you end up with 1 star reviews because people don't realize their own phone is killing apps?
Intentionally breaking well defined OS scheduling guarantees?
Silently breaking functionality that users rely on?
> Not only did users need to enable extra settings to make their apps work properly, but those settings even got reset with firmware updates. So apps break again and users are required to re-enable those settings on a regular basis.
What's funny/sad is their edit only applies to vanilla Android. Other manufacturers have manufacturer-specific settings needed to whitelist apps, because they're not respecting the contract Android provides on background processing
-
And maybe the most insulting part is the fact that the apps that consistently show up as higher energy users on people's devices... like Facebook...
Are normally exempt! These "optimizers" usually exclude any app deemed "too big to make fail".
So it actually undoes an enormous amount of good that would otherwise be done, and shows it's hardly being done with actual results in mind
These optimizers have existed since the early days of Android, but advanced users understood that intentionally breaking apps wasn't the right way to go about saving battery.
Manufacturers picked them up, in large part because clueless users who like the sound of the idea (right up until it starts killing their music or making their alarms fail to ring) were installing them
Some of them even feel like anti-competitive implementations.
Huawei has an implementation that can't be controlled by the user on some devices! So only apps on the pre-installed Huawei whitelist can run in the background period, and that list includes their homegrown apps and a few major ones like Facebook. Good luck if you have a small app with useful functionality.
I don't think you quite grasp what I meant by balancing act. This is an issue which the 2 biggest companies in tech have been fighting for 15 years (and Microsoft fought and failed to solve prior to that).
This is arguably one of the biggest problems in tech and as devices get smaller and more personal, it's only going to get trickier. Your watch battery isn't going to last all day when you are running a crypto currency miner which is disguised as a media player.
> The decision came in response to the Chinese phone maker's decision to cut off all background apps except its own, which stops VLC's audio playback, VideoLAN said in a tweet.
Here's a real, not made up, not founded in a slippery slope from allowing music to allowing crypto mining, example of what these manufacturers are doing to users and devs alike.
-
It's not about battery life, it's about flexing their power to seem like they're doing something, while ensuring their bundled apps are the best option for a wide range of tasks
In fact, you can look at the manufacturer list and come to that conclusion yourself.
The manufacturers at the top of the list of breaking optimizers are mostly selling devices heavily subsidized by bundled services. Even Samsung is more aggressive on cheaper devices that target BRIC markets because they need revenue from bundled services.
-
Google is the only exception to the rule... until you realize their devices are just following the guarantees Android makes.
And they still manage to have some of the best battery life on the market.
That's because it's not even as simple as just blindly killing background apps.
When you kill these background apps, users get in the habit of opening the apps back up manually to not miss updates.
Repeatedly waking the radio is more battery consuming than if the OS just keeps it's promises and smartly wakes these apps.
It's not like they get infinite processing time anyways, having this stuff be managed intelligently instead of just taking a sledgehammer to the concept of background processing is better for everyone involved but a manufacturer that wants their music app to be the only functional one...
I have absolutely no idea what any of this has to do with my original point or my reply.
Android OEMs have bad battery life because they install their own services and layers of nonsense over the top of Android. That doesn't change the fundamental issue here.
> This reads like a comment written by someone not aware of the depth of the problem.
> Oh please.
> Or you don't understand that?
What I understand is that your posts have wandered between being dismissive, condescending, and argumentative. I've ignored that to this point, but since you've been insisted on being consistently so in 3 messages straight, I'm calling you on it.
If you have a point other than being argumentative, it's not well made.
You're complaining that my replies have nothing to do with the original point... then typing up a screed about my tone?
Especially after starting your initial reply to me with
>I have absolutely no idea what any of this has to do with my original point or my reply.
Do you know what dismissive means?
-
If I come across as dismissive it's because you really don't seem to know what you're talking about, and if anything this attempt to deflect from the fact just cements that.
Me telling you that your comment comes across as being written by someone not aware of the depth of the problem is exactly what it sounds like, you said things that strongly implied you were not aware of the deeper background to this post.
If you choose to take it as a personal slight, be my guest.
-
Likewise if you're going to play the "music players can be crypto miners" card I'm going to be dismissive of that too, it's a lazy attempt to distract from the problem.
Of course apps can be bad actors. Jumping to the most fear-mongery example possible is just that... fear mongering.
For every app mining cryptocurrency, there's 10 more that are just poorly behaved in respect to battery life.
Trying to act like OEM's attempts to lock down background apps should be dictated by the former rather than the latter is something I'll gladly dismiss. It's nonsense.
So you’re saying OEMs take no efforts to optimize for battery life. That’s kind of an extreme position to take. We know they are working on battery life because updates have extended battery life in deployed assets.
What? No? Where did I say "OEMs take no efforts to optimize for battery life"? Usually you try and be subtle about a strawman, no?
I said overbearing app killers aren't optimizing for battery life.
Do you think that's the only knob for battery life? I'm currently working on an unreleased Android device at our company, the number of knobs we have to turn for battery life is insane. Throttling behavior, optimizing existing services, screen off behavior, etc.
App killers don't work, again, that's why vanilla Android devices consistently top battery life charts. Forcing apps to start up more often, breaking user functionality, it's not a real solution.
The defaults scope of background processing is already very tight on Android, breaking that already limited scope for little to negative gain isn't helping anyone but themselves.
It's not even that, simply having open sockets with heartbeats (and then re-opening them once the connection breaks or you switch networks) isnt efficient with 5+ different sockets always open listening for notifications, and that's if every app is coded the same way to operate extremely efficiently.
It would not be technically impossible to have all 5+ wake up at the same time and activate the radio at the same time, even with different packets to different destinations.
And it would not be impossible to coordinate the return timings to match either.
Or even better, to have just one low-level packet shared among them all, with a mobile operator or backbone protocol that fans them out and in, analogous to multicast and IGMP but designed for push/keepalive systems.
There are no insurmountable technical obstacles. Just challenges.
There is negligible consequence for power consumption too, with a suitable API.
But rather than design for everyone, as we would have seen in the utopian days of the internet, it's much easier to run a single walled-garden service, and it fits with the "you must go through us for everything" model used by many of the device's other services.
Utopian days of the internet? Where a bug in a prank can spread a worm that takes down most of the known internet?
The same security mindset that allowed for the utopian days is not only long gone, it could survive in an age where my banking and medical info is online.
The attitude that different vendors can create independently run services is still alive, now with better security.
But not on major mobile devices, at the moment.
In the banking world, it appears to be getting slightly more open. There are more independent feeds and open standards than there used to be. This is a mixed benefit as there are also more "middleman" sites that want to read your banking data to help you visualise it better, and some of them might not be doing it just for the benefit of the account holder.
No matter how good the push implementation is, it is still best to only have one connection that the phone has maintain. 5 great push services still takes 5 times the battery that 1 great push service would take.
> 5 great push services still takes 5 times the battery that 1 great push service would take.
This is true with current implementations, but it doesn't have to be true.
Coordinated CPU wakeups and radio packet timings would mean the power consumption from waking the radio would be not much larger with 5 apps than 1.
It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and it doesn't have to go through one shared cloud service provider as it is now.
> It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and
It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.
> it doesn't have to go through one shared cloud service provider as it is now.
This is more true, for example you could have an open protocol and an app could register with the push daemon. It would be impossible to consolidate push notifications or throttle them for bad actors though.
> It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.
A single daemon, or a single kernel, it doesn't really matter which.
I'm thinking a few socket() options. The kernel already coordinates coarse-grained timer wakeups between processes; it's not that outrageous to think it could nudge multiple pinging sockets towards each other then coalesce timings.
The underlying mobile network registration for notifications is already quite low level.
> It would be impossible to consolidate push notifications or throttle them for bad actors though
At least at the moment, I don't think there's a need to consolidate push notifications into the same packet for different apps. The rate of notifications isn't high enough to matter.
For keepalive pings (if the underlying radio network can't provide events to piggyback on), and consolidating pushes (if that is needed), voluntary cooperation on timings among good actors would allow incoming packets to arrive around the same time, and the mobile base station could, if a protocol was agreed, queue and coordinate the transmission time of those packets as a group, or coalesce them into a specially-addressed packet representing the group.
For throttling bad actor pushers, the device itself (kernel or daemon) could block sockets and source IPs that are sending too fast.
Presumably there's already some mechanism in place for things like SYN attacks. If there isn't, bad actors already have a way to drain your battery.
The savings are from letting radio go to idle. If you have more than one (ideally non-cooperating) services that are keeping the radio permamently on, you won't ever get to idling and say good bye to battery.
I'm skeptical that Microsoft, Apple, and Google have all failed at this, but some dude on HN has a simple solution. I think you need to expand on your concept a bit before I take it seriously.
What does the software solution look like that distinguishes between a crypto miner and a media player?
How can you tell when an app legitimately needs access to files from another app versus being malware of some sort?
Not sure if you're a programmer, but you can have a centralised local service that listens multiple channels over a standard API and wakes up the respective app. Some quota management on top can ensure fair share. And of course, allow the user to prioritise any app they want.
It sucks that mainstream os'es have spent the last decade on a race to the bottom, to control & reduce possibility.
There are bad actors abound but many users were navigating the environment semi-ok, checking for information on how bad their apps were acting.
The clampdown is both for the user but also enormously user hostile. We can try to pin down how justified or not it is, but it bloody sucks either way & I am worried, really worried, with current events like Mozilla & Apple teaming up to decry webmidi & ambient light sensing as enemies. Yes they have some risk? But mostly this comes off as farce to me, & spun with heavy marketing "be afraid" FUD.
> There are bad actors abound but many users were navigating the environment semi-ok, checking for information on how bad their apps were acting.
I truly hope Pine phone picks up share (and performance/ functionality) so people who want this level of control over what their phone runs have a platform.
A lot of people don't know how to manage their phones. I know how to manage performance on my computer but would prefer to not have to do the same on my phone. I suspect I'm not the only computer professional who wants to leave that sort of administrative detail to their work life and not have to deal with a phone that crashes due to a poorly written app.
I suspect this is why the iPad is so popular. It has much of the power people expect from a PC, but removes much of the headaches associated with them.
My feeling here is there is space for managed platforms such as the phone and the iPad; less managed platforms like the Windows/ MacOS; and truly open platforms like Linux. I'm not sure open platforms are very well suited to phones myself, but I'm not against them either.
Not clamping dawn is user hostile. These are phones and messaging platforms that are under constant attack by bad actors. Semi-ok means the bad actors have succeeded many times on hundreds of millions of devices.
Stop mistaking your unique desires for those of the vast majority of smartphone users. Very few care about alternate push notification services, or sideloading, they are happy to use the default app stores and services.
You're being close minded. Neither of us have any idea what would have happened if computing was left open, if the doors didn't keep getting closed, & the presumption that I'm greedy & everyone want & must have stupid, as not just a foregone conclusion, but that this was the only possible path towards that conclusion, that no space could have been created, is tragic to see in people.
Looking at the piles of malware which litter the Windows PC world and the web, we have a pretty good idea of what would have happened if smartphones were left wide open. Also, Android started far more open than it is now. Over the years been getting more and more restrictive in terms of security because privileges were abused. In the early years Android battery life was particularly bad because of bad performing software.
Even with the restrictions in place, Facebook and other apps have been caught abusing privileges to get more CPU rights and burn up battery life (and get collect user information).
There has to be space for more. General purpose computing getting snuffed out under the new security regime is accepting the abyss, & we must strive for more.
I'd say that things would get terrible if Linux were the popular OS, that we'd become a target for malware, & that we are not now.
Except since our community actually knows stuff & we have users interests at hearts & it's open source, places like Debian would be largely immune to most of the horseshit.
Story seems pretty much the same with Web push notifications. You send a json to the temporary url provided by the browser push api.
1. From client get a push url.
2. Pass that to your app server for future use.
3. Send notification json to that url.
4. That url points to the specific browser vendor's Push notification server, and when it recieves a notification from your app server. It relays the message to the client.
We just need an SMTP extension that says ‘this email is a notification. Delete after x days’. The rest of the mechanism is there. Apple and google will follow. Emails may not be instant but most notifs are not urgent. I know there are 1000 other protocols out there, but email is the only one that s widely used and hasn’t been bastardized or wallgardened
Things like this explain some devs I encounter solve networking things which could be done on a LAN level using multicast for instance instead through the cloud.
My biggest problem with FCM is how hostile it is to open source and self-hosted services. If you want to push a message to a phone, you don't just need to be registered with Google; you need to be the app developer. App developers cannot allow third parties to push to their app, because they'd have to give them their FCM credentials, which is a no-no.
So the only way to get push notifications on, say, apps that provide a client for generic protocols or self-hosted services, is for either the app developer to run a proxy gateway (which inevitably runs into scalability issues forcing them to start charging for it or require registration with free quotas), or for you to create your own build of the app. I ended up having to do that with Linphone, rebuild it under my own app ID with my own FCM creds, just so I could get push notification integration with my own SIP server instead of having to keep a background SIP connection open to receive calls.
This is completely silly, with the only free endgame being everyone has to compile their own apps and have one app installed for every potential provider, even if they share a protocol.
There's probably no wish to monetize, just to distribute working apps for free.
You're right that the issue is easily addressed with a proxy.
But now you need to maintain and pay for a proxy in perpetuity, for other people to use who aren't paying anything.
Even if it's cheap, maybe you don't have the time. It will break occasionally. Knowing there are people who may depend on it 24x7x365 is burdensome too. You'd like to have vacations.
It's not very open source friendly if other people can't just take your software and run it themselves without depending on you.
Those other people can avoid depending on you by registering themselves with FCM, but having to do that is not open source or self-hosted friendly either, which was the GP's point.
Any end-user tech that requires a listening port on the internet will:
A: Never work, because NAT isn't going away (even with increased IPV6 adoption). Even locally it will work less and less because "block all incoming connections" host firewall configs will eventually become the norm.
B: Be a security risk waiting to happen (EX: Chromecasts using UPNP to expose themselves to the internet, which were immediately blasted with broadcasts from one of PewDiePie's wretched fans).
I've never looked deeply into this notification thing but people seem to conflate saving the battery and having only one notification server.
If energy used by firing up the CPU frequency plus the 4G radio to send some packet is the main battery drainer, why not just synchronize the poll of multiple notification servers?
The CPU will be waked up, a few data packets will go to a few notification servers, then in the common case of no notification everything goes back to sleep.
If it's the network that wakes up the phone when some packets are there (as WiFi energy saving does), if synchronized in time (NTP goog enough) it should also work and be energy efficient.
Probably naive, curious about real world measurements in this area :)
Technically there is a workable solution somewhere close to what you describe, and it should cost tiny extra power usage vs the fully centralized design.
But imagine you are a company running one of the big mobile platforms. You could invest effort in the APIs and OS behavior to do this, and the payoff would be loosening your grip on the ecosystem. Tough to justify to those watching the ROI.
Just one issue - there are timers on connections regulating how long a connection can be kept alive before a packet is required. Larger timeouts are better for phones, but require more resources on the servers/networks.
Google/Apple work directly with carriers to extend the timeouts for their push services so the phones aren't required to send keepalive packets every 30 seconds to keep the connection alive. Carriers won't be willing to do that for every random server out there.
This is just one of many ways these push services are carefully designed/operated to save as much battery life as possible. If you had more than one notification service, battery life would degrade to the worst performing one (the radio would be forced to wake up to keep every notification service alive... Even if the Google one could go minutes between the keepalive packets)
(Another is the way Google batches low priority notifications... Sending a push message won't immediately wake up a phone - it delays to try to batch as many messages as possible. This scheme breaks down if messages aren't all routed through a single server)
GCM doesn't work in China, so the Android ecosystem there is very different from the world.
Before manufacturers come up with there GCM alternative, each apps actually have there own service to handle push messaging. It is fine when the number of apps is small, but drains a lot of battery when it gets larger. So manufacturers started to introduce some aggressive strategy to kill background processes to save batteries, but it also makes small developers' app less usefull. It is because apps from big corporations usually get a pass, while others will be killed. Now, as far as I know, manufacturers have their own GCM alternative now as an alliance.
So I think even if you don't have it, you eventually need one, because it is too inefficient to let each apps handle this by themselves.
Funny to see “saving battery” in scare quotes. People actually do care about that! And they care about that a hell of a lot more than getting push notifications from the LAN.
This article is just lame. OP couldn't seem to figure it out but you can implement a background service.
>why not shutdown location and frequent play service updates as they aren't helping my phone battery either
They do. The recommendation is to use the location library that batches GPS use instead of manually calling it per app. The playstore uses heuristics to know when to query for updates and when to download. Its better that the OS batches these sorts of things.
There may be some valid critique but this article is devoid of anything useful.
176 comments
[ 3.3 ms ] story [ 208 ms ] threadAnd there is microG, to hook into the Google way of doing things.
> A self-hosted push notification service.
That’s something that is hidden from users, they put their phone in their pocket and two hours later their battery charge is substantially diminished. They don’t understand why or how to stop it.
They know playing a game for hours straight reduces battery charge.
It’s called cell tower triangulation and your phone needs to do it constantly, or you can’t receive or send calls.
The complaint about location in the article is about Google's tendency to bug you to turn on GPS and leave it on, happily draining the battery but for Google's own surveillance purposes. Having a GPS fix is not a requirement of the cell network.
Cell tower triangulation is something the network can do as a result of your phone connecting to cell towers. While connecting to a cell tower is mandatory for cell communication, an open baseband could make it a point to only connect to one tower at a time (although a single tower will still have some location information due to sector antennas).
Doesn’t mention GPS. That may be what the author meant, but certainly could be written far clearer.
Still, Google isn’t using GPS all the time, their power management strategy can’t allow that. It’s likely only using it when its deemed necessary. Android is tuned to balance offer users the most functionality possible with longest battery life. If it did not iOS would destroy it in battery life tests.
Triangulation is necessary to determine which tower to connect to and when to switch to a new tower. It’s why they are called “cellular” phones.
The entire point is that Google encourages you to leave the setting on, meaning you'll be doing GPS fixes more than what the user actually considers necessary.
> Triangulation is necessary to determine which tower to connect to and when to switch to a new tower.
No, it's really not. It's hard to even figure out what you're trying to describe here.
Yes, the baseband sees the signal strength from each nearby tower to know when to switch between them. But the baseband doesn't itself have a map of cell towers. If the list of visible towers is used for client positioning, it happens on the application processor. The work of deriving a location from the towers is not necessary for cell network communication.
And Google should encourage you to keep GPS on if they do a good job managing its power usage. Users aren’t always going to know when the app they are using is going to work better with more precise location data. This is a user friendly feature.
Circling back around, the author is still wrong that allowing installed apps to run unrestricted background network processes is anything like the OS carefully managing location accesses to minimize power usage.
Edit: the article references this HN thread, which I'm sure we'll end up rehashing: https://news.ycombinator.com/item?id=22310319
The thing I hate is megacorps slowly infringing and removing device/OS freedoms in the name of some stated "good cause" (security, malware prevention, battery life, etc.).
And phones know your location virtually 100% of the time because of cell tower triangulation. That’s part of being a phone, not a google hypocrisy.
The real problem is pushing everyone towards unconfigurable closed software that would otherwise abuse full access to the device. Because people can’t trust what they run on their phones the apps can’t be given any more privileges than a random web page.
Unless everyone is a software engineer and can read the code of all the software they’re running and where their data is going, “open source” isn’t going to fix the problem. And expecting everyone who uses a phone or computer to know the details of its software implementation is highly unrealistic (even as a software engineer, do you know how your doctor’s medical billing and coding software works? Unless you work at Epic, probably not). So there needs to be some regulatory body who actually is informed and can certify that software companies are following the rules.
Now do I trust Google more than a regulator? That’s a much closer question.
2) I was arguing for shifting the point of trust to volunteers from the community. In particular I was thinking of the Debian project but there are other examples.
This only works on a platform where apps can run in the background indefinitely. Small memory, limited CPU, and battery life means apps have short life-spans on phones.
This is why there is a push notification service for mobile platforms.
The reason apps have to have short lifetimes on people’s phones is because they’re encouraged to install untrusted software as native apps.
Why, because Google says so? I am ever so grateful they make those decisions for me.
> And phones know your location virtually 100% of the time because of cell tower triangulation.
Well if the cell service provider knows your location, what's the harm in letting Google in on it as well, right?
What Google does with that info is an entirely separate issue.
And please let me know when Google or Apple starts advertising their phones as Unix servers and tout the ease of installing HTTP servers on them. They are sold as phones and that makes security and battery life critically important.
> And please let me know when Google or Apple starts advertising their phones as [..]
Circular logic. They chose to lock-down and hobble phones, and because their advertising doesn't include user freedom, you think that makes them justified in infringing on that freedom? Especially when they pulled every anti-competitive trick in the book, and invented a few new ones, to kill any competing phone OSs?
Please let me know when a phone manufacturer starts advertising the benefits of user freedom such as rampant malware stealing your personal information, dropping calls and bricking your phone.
The first iPhone didn’t allow apps at all. When it was introduced the expectation for phones were they were safe and secure. If the iPhone wasn’t it would have failed. It’s like you are arguing automobile manufacturers don’t advertise that their cars are safe to drive, so obviously it isn’t a feature important to customers.
And anyone can compete with a phone OS. You can fork Android for gods sake.
They're advertising smartphones, not just phones. And the expectation of what a smartphone is is defined entirely by the Apple/Android duopoly. So even your claim that smartphones imply locked-down is circular.
> benefits of user freedom such as rampant malware stealing your personal information, dropping calls and bricking your phone.
So you're just choosing to ignore linux? And are you seriously using "stealing your personal information" as a contrast to what Google has been caught doing with Android? (Or MS with Win10, if we go beyond phones).
> And anyone can compete with a phone OS. You can fork Android for gods sake.
You can - if you can survive being locked out of the Google Play store walled garden while you build up your own ecosystem (which Google tried to keep secret): https://ec.europa.eu/commission/presscorner/detail/en/IP_18_...
But I'm sure you'll be able to come up with more reasons why only giant multinationals should have a say in how smartphones work. I'm glad your kind wasn't as prominent when PCs were getting off the ground, or we'd need special developer licenses to run compilers, and anyone that complained would get shut down with "Intel/AMD don't advertise hacker boxes, but PCs!"
And your only argument so far has been "Smartphones don't respect user freedom because we don't expect them to. We don't expect them to because they don't.", with a dash of the freedom-security false dichotomy thrown in.
I hope you'll forgive me if I'm not convinced.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
https://news.ycombinator.com/newsguidelines.html
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
https://news.ycombinator.com/newsguidelines.html
Also, this is not just about push. The problem is that Apple and Google de facto own the edge user interface: phones.
The technical part is not the hardest part; it's the "everything else".
It hasn’t taken off yet because it’s only barely started shipping.
Android has moved from a mostly unrestricted environment to one that's pretty restrictive. Which means things have been taken away, and things that would have worked in gingerbread can't work today. And it's big things with reasonable use cases too: background exection and network access used to be pretty reliable (minus wifi tended to turn off with the screen), now it's not --- if Google push doesn't work, no notifications until the user starts the app or Google lets you run; you used to be able to use a usb camera from an app, now you can't with latest Android, so keep an old phone for inspection cameras.
I understand unfetered background execution is problematic, but it's also useful.
edit: removed stuff about Push via SIP, that might be too incorrect to be helpful. Also removed some pondering about trying msg.exe over IPv6. I was probably fishing for trouble there.
In 2030 we won't have native IPv6 and it won't be on the drawing board.
You'd need mobile IPv6, and background applications that don't get killed while listening to a socket. As far as I know, neither of those are commonly available.
However, the Push API refers to a recommended IETF protocol for providing the push service: https://tools.ietf.org/html/rfc8030
I’m just glad my pinephone shipped and everything on my phone actually makes sense now (even if I have to compile things and write a few config files.)
And where is the option for those of us who don’t mind less battery in exchange for actually getting prompt notifications for services we use?
Apple has an obligation to its customers to make their phones work as well as possible. Customers complain all the time about mysterious battery draining behaviors, and blaming various apps. Having millions install some cool new notifications service without realizing it’s actually a battery draining service just multiplies those problems.
This is pure FUD reasoning though. You can’t say “no you can’t have that because it could possibly be bad trust me” without any evidence that it would be a major issue. The more locked down a phone is the more people need Apple/Google.
Look at early Android or Windows Mobile or Palm or heck even your own modern-day laptop. Battery-draining background applications aren’t FUD and don’t require any additional evidence because that’s the reality on basically every platform except iOS and modern Android.
This is a pretty tough alternative. No developer is going to say "I have ill intent here"; are you confident you have the ability to make that decision on your own? I'm not confident I do. I can't look at the code of most of the stuff I run on my phone. Some people would say "then stick to all open source software," but I don't have the time or expertise to audit the code of all -- or even most -- of the applications I run. Maybe other people will, but there's no guarantee they'll find anything bad (whether malicious or just buggy) very quickly -- and we're talking about cloud stuff here, which means there's a server none of us can audit involved in the process.
Apple and Google having "blessed" push notification systems is certainly a tradeoff on multiple levels, from it being a single point of failure to being another server you can't audit and a single company you have to trust to at least some limited degree. But having the notifications integrated at the OS level reduces the number of people and systems involved in delivering those notifications, at least theoretically reducing the number of bad actors -- and, as many people have observed here, also lets these notifications be optimized for battery life in a way that's probably not possible if you have dozens of apps running their own background processes rather than simply asking to be notified by the system one. The alternatives are a different set of tradeoffs. That doesn't necessarily make them worse, but it definitely doesn't automatically make them better.
> And where is the option for those of us who don’t mind less battery in exchange for actually getting prompt notifications for services we use?
The alternate scenarios give you less battery, but don't guarantee actually getting prompt notifications for services you use, do they? They just give you different points of failure. Actually, they might even give you the same points of failure. When a DoorDash notification shows up on my iPhone late -- or as it did the other day, inexplicably 20 minutes early, leaving me standing in Silicon Valley's smoke-filled air quizzically looking for my chicken order -- is that Apple's fault, or is it DoorDash's fault? After all, the notification isn't starting on Apple's server. If the problem is with DoorDash, which the early notification had to be, then if DoorDash could bypass Apple's notification system all that would give me is an incorrect notification delivered with fewer network hops.
Most of the garbage people have on their phones (DoorDash included) is better as a web page.
You always have the option to build your own phone. With easily available components and open source software it’s never been easier. And with cheap and flexible Chinese manufacturing, Kickstarter and Patreon it’s never been easier to manufacture your own phone design.
Otherwise, your demands don’t reflect the needs of the vast majority of Google and Apple customers. The world doesn’t revolve around your unique desires.
That sounds factually false to me.
Seems to me that I can't do it. Others have tried, how's that going?
For a start I don't think the components are easily available. Both software and hardware.
> "With easily available components and open source software"
For me the modern definition of a phone is "a device that can make voice calls, message people on their required messaging network, and give me access to my bank accounts".
I don't think I can actually do that with easily available components and open source software right now. It would be interesting to be proved wrong.
https://www.pine64.org/pinephone/
Steve Jobs couldn’t build a phone. But he could build a team that could build a phone. You don’t have the resources of Apple (he didn’t at the start either, just Woz), but you have Patreon and Kickstarter.
The main difference between you and Steve Jobs is he didn’t waste his day complaining in the internet about problems, he actually did something to offer solutions for them.
I cannot message people on their required messaging platforms, and I cannot access my bank account with it.
That means if I used a Pinephone I would need to carry two phones.
This is not someone "complaining" as though to do nothing. It is someone stating the current situation and what needs to be changed.
I would dearly like to change this, but your suggestion implies that it's realistic and easy, which is far from the current truth.
> Steve Jobs couldn’t build a phone. But he could build a team that could build a phone. You don’t have the resources of Apple (he didn’t at the start either).
For the same, simple definition of a modern phone, another gigantic company, Microsoft, tried and failed. It really isn't easy.
Why not add the missing features you need to Pinephone? It just requires writing software. I’m not going to blow smoke up your arse and tell you that you are going to find a large market, but you could make something compelling and unique to a large enough audience to fund through a Patreon or Kickstarter.
What I will tell you that while every entrepreneurial activity I’ve started has not succeeded, (in fact most have failed), I’ve learned valuable things from every single one. It is one of the greatest ways to learn new technologies, markets and skills.
No, it does not "just" require writing software.
- Potentially writing software and reverse engineering will allow me to message people on their required messaging platforms. Matrix is getting there. Maemo on Nokia N900 was excellent at this, but that was a different time; messaging has become more complicated since then.
But, though I'm a fine software engineer, it is not feasible to write software to provide all the features I defined as essential in a modern phone:
- No amount of writing software will allow me to access my bank account, which requires an Android or iOS app on an unjailbroken device to the best of my knowledge. No, a web browser does not work, it must be the app (crazy but true). Yes I could reverse engineer and crack the existing app to port it, but that would be foolish given the application.
As I said, I would love to be proven wrong on this.
Obviously I could switch banks, although that's not without its own difficulties and arguably if I have to switch banks, the new device doesn't meet my definition of a modern phone.
The problem is not a software-writing problem.
This is what I meant by Microsoft couldn't do it. Even though Windows phone was pretty good, it wasn't enough to be pretty good. It needed the essential apps that only 3rd parties could write, and not enough 3rd parties decided to write them. That was not in Microsofts locus of control, just as it isn't in mine.
Eventually things may change, if Pinephone and its relatives become more popular or if fashions change. But not at the moment. At the moment, if I got one I would need to carry two devices. (I had two Nokia N900s btw, I'm no stranger to open source phones.)
My friend has one with an ATT sim, and calls+SMS works just fine on postmarketOS. The UI is really sluggish though.
You say this like it's some egregious burden. Compared to the cost of building an app and shipping it $100/ year is a fraction of a drop in the bucket. It's less than 1 developer hour.
If you are capable of building an app with push service, the cost is trivial. If you aren't capable, it's irrelevant.
Theres no market of second hand developer licenses.
So please, stop defending them. They are doing really shitty things that will just become stains in computing history.
This is true if you love Apple or hate them deep in your soul for a million burning reasons.
If I started my career in the current era, there is no chance I would have been able to afford to develop in the Apple ecosystem (not just yearly subscription, which is crazy to me, but also the cost of the hardware as you point out).
Why the hell do I have to pay $100 a year to use a computer I own? Why are you defending this!?!
Is each app going to be killed when not in foreground ? Or are they all going to keep running ?
Is there going to be special API for background download manager, notification listening, music playing, etc. or is each app going to keep running in background and do its own stuff like on Desktop ?
For Google & Apple things are super easy : they do what they want.
But For Linux Phones, people from KDE, Gnome, Wayland, Purism, etc. will have to agree on services & APIs which might take lots of time
A bit like some browsers do to timers in non-foreground tabs.
But RAM might also be a problem if the phone keeps everything in background & isn't allowed to kill any app when it needs to
The phone is suspended when the power button is pressed. Reciving network traffic (ex responses to IDLE on an open IMAP connection) wakes it up and there’s a service that suspends it again fairly quickly if the power button hasn’t been pressed. Another service manages an RTC alarm so that programs expecting pushed data can reestablish sockets if they die (since that won’t necessarily wake the phone.) The only disadvantage to this scheme is that there are more keepalive messages sent (so you should limit the number of services expecting push messages to just a few.)
Mine runs a normal X11 DE (fluxbox) so the apps run in the background just like they do on my laptop. If something wakes the phone up too often just kill it.
I’m still working out the kinks but it seems to get decent battery life this way. No need for some special API.
How can you listen to network events while being suspended ? I thought that on linux suspend = all user processes stopped. Does it somehow wake up every nth second to check if there a new message from the network ?
This SDK has "Google Analytics for Firebase" enabled by default, and they use dark patterns to make it seem like having Analytics enabled is required: https://imgur.com/a/Nk2KhFo
Of course, if you do enable analytics, then Google sucks up your customer data (including in-app purchase behavior!) for their own data collection and advertising purposes. Also, you're required to tell your users this is happening, but of course developers don't know this. (More dark patterns in how Google reveals that they steal your analytics data for themselves: https://imgur.com/a/R0K71Zn)
Can also be distributed via doc browsers like Dash, e.g. if censored from the web.
This would be a "vendor documentation annotation" service not controlled by vendor.
Enabling it in your project like you show on the screen does basically nothing as long as you don't have analytics SDK in your app.
https://imgur.com/a/Fl919Wm
This is stated right before the steps you show. Only the one who doesn't read will blindly add analytics.
Looking at the landscape of shit software out there, I find this justification entirely plausible. If iOS & Android didn't lock this down, phones would be running 4-5 different poorly implemented push platforms (or more). Battery performance on mobile would be utter crap.
There is a big balancing act going on here. People want phones that do the thing they are supposed to do. They also want battery life to be excellent and the device to be secure by default. It's impossible to give 3rd party devs 100% access and meet those 2 demands.
The post is Android-centric because in typical Android fashion, a passable concept is implemented is the most disjointed way varying scross devices.
Limiting excessive background communication? Thats a good thing.
Killing useful apps like media players in the background repeatedly until you end up with 1 star reviews because people don't realize their own phone is killing apps?
Intentionally breaking well defined OS scheduling guarantees?
Silently breaking functionality that users rely on?
Making alarms fail to ring?
Not as useful.
It's to the point there's literally a website dedicated to worksrounds: https://dontkillmyapp.com/
Look at at this entry for OnePlus
> Not only did users need to enable extra settings to make their apps work properly, but those settings even got reset with firmware updates. So apps break again and users are required to re-enable those settings on a regular basis.
What's funny/sad is their edit only applies to vanilla Android. Other manufacturers have manufacturer-specific settings needed to whitelist apps, because they're not respecting the contract Android provides on background processing
-
And maybe the most insulting part is the fact that the apps that consistently show up as higher energy users on people's devices... like Facebook...
Are normally exempt! These "optimizers" usually exclude any app deemed "too big to make fail".
So it actually undoes an enormous amount of good that would otherwise be done, and shows it's hardly being done with actual results in mind
These optimizers have existed since the early days of Android, but advanced users understood that intentionally breaking apps wasn't the right way to go about saving battery.
Manufacturers picked them up, in large part because clueless users who like the sound of the idea (right up until it starts killing their music or making their alarms fail to ring) were installing them
Some of them even feel like anti-competitive implementations.
Huawei has an implementation that can't be controlled by the user on some devices! So only apps on the pre-installed Huawei whitelist can run in the background period, and that list includes their homegrown apps and a few major ones like Facebook. Good luck if you have a small app with useful functionality.
This is arguably one of the biggest problems in tech and as devices get smaller and more personal, it's only going to get trickier. Your watch battery isn't going to last all day when you are running a crypto currency miner which is disguised as a media player.
A non-user modifiable app killer isn't the fine line separating us from media app currency miners.
How are Google's devices keeping OS guarantees while delivering some of the best in class battery life figured on Android
Also, imagine seriously implying it's ok they blanket-kill user installed media players because there's a chance they might be currency mining?
https://www.cnet.com/news/vlc-for-android-blacklists-huawei-...
> The decision came in response to the Chinese phone maker's decision to cut off all background apps except its own, which stops VLC's audio playback, VideoLAN said in a tweet.
Here's a real, not made up, not founded in a slippery slope from allowing music to allowing crypto mining, example of what these manufacturers are doing to users and devs alike.
-
It's not about battery life, it's about flexing their power to seem like they're doing something, while ensuring their bundled apps are the best option for a wide range of tasks
In fact, you can look at the manufacturer list and come to that conclusion yourself.
The manufacturers at the top of the list of breaking optimizers are mostly selling devices heavily subsidized by bundled services. Even Samsung is more aggressive on cheaper devices that target BRIC markets because they need revenue from bundled services.
-
Google is the only exception to the rule... until you realize their devices are just following the guarantees Android makes.
And they still manage to have some of the best battery life on the market.
That's because it's not even as simple as just blindly killing background apps.
When you kill these background apps, users get in the habit of opening the apps back up manually to not miss updates.
Repeatedly waking the radio is more battery consuming than if the OS just keeps it's promises and smartly wakes these apps.
It's not like they get infinite processing time anyways, having this stuff be managed intelligently instead of just taking a sledgehammer to the concept of background processing is better for everyone involved but a manufacturer that wants their music app to be the only functional one...
Android OEMs have bad battery life because they install their own services and layers of nonsense over the top of Android. That doesn't change the fundamental issue here.
You understand me replying to you and talking about how they're not balancing anything but personal gain and optics is relevant to that?
Or you don't understand that?
> Oh please.
> Or you don't understand that?
What I understand is that your posts have wandered between being dismissive, condescending, and argumentative. I've ignored that to this point, but since you've been insisted on being consistently so in 3 messages straight, I'm calling you on it.
If you have a point other than being argumentative, it's not well made.
Especially after starting your initial reply to me with
>I have absolutely no idea what any of this has to do with my original point or my reply.
Do you know what dismissive means?
-
If I come across as dismissive it's because you really don't seem to know what you're talking about, and if anything this attempt to deflect from the fact just cements that.
Me telling you that your comment comes across as being written by someone not aware of the depth of the problem is exactly what it sounds like, you said things that strongly implied you were not aware of the deeper background to this post.
If you choose to take it as a personal slight, be my guest.
-
Likewise if you're going to play the "music players can be crypto miners" card I'm going to be dismissive of that too, it's a lazy attempt to distract from the problem.
Of course apps can be bad actors. Jumping to the most fear-mongery example possible is just that... fear mongering.
For every app mining cryptocurrency, there's 10 more that are just poorly behaved in respect to battery life.
Trying to act like OEM's attempts to lock down background apps should be dictated by the former rather than the latter is something I'll gladly dismiss. It's nonsense.
I said overbearing app killers aren't optimizing for battery life.
Do you think that's the only knob for battery life? I'm currently working on an unreleased Android device at our company, the number of knobs we have to turn for battery life is insane. Throttling behavior, optimizing existing services, screen off behavior, etc.
App killers don't work, again, that's why vanilla Android devices consistently top battery life charts. Forcing apps to start up more often, breaking user functionality, it's not a real solution.
Android already has built-in management of background services and has had it for half a decade: (https://developer.android.com/training/monitoring-device-sta...)
The defaults scope of background processing is already very tight on Android, breaking that already limited scope for little to negative gain isn't helping anyone but themselves.
And it would not be impossible to coordinate the return timings to match either.
Or even better, to have just one low-level packet shared among them all, with a mobile operator or backbone protocol that fans them out and in, analogous to multicast and IGMP but designed for push/keepalive systems.
There are no insurmountable technical obstacles. Just challenges.
There is negligible consequence for power consumption too, with a suitable API.
But rather than design for everyone, as we would have seen in the utopian days of the internet, it's much easier to run a single walled-garden service, and it fits with the "you must go through us for everything" model used by many of the device's other services.
But not on major mobile devices, at the moment.
In the banking world, it appears to be getting slightly more open. There are more independent feeds and open standards than there used to be. This is a mixed benefit as there are also more "middleman" sites that want to read your banking data to help you visualise it better, and some of them might not be doing it just for the benefit of the account holder.
This is true with current implementations, but it doesn't have to be true.
Coordinated CPU wakeups and radio packet timings would mean the power consumption from waking the radio would be not much larger with 5 apps than 1.
It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and it doesn't have to go through one shared cloud service provider as it is now.
It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.
> it doesn't have to go through one shared cloud service provider as it is now.
This is more true, for example you could have an open protocol and an app could register with the push daemon. It would be impossible to consolidate push notifications or throttle them for bad actors though.
A single daemon, or a single kernel, it doesn't really matter which.
I'm thinking a few socket() options. The kernel already coordinates coarse-grained timer wakeups between processes; it's not that outrageous to think it could nudge multiple pinging sockets towards each other then coalesce timings.
The underlying mobile network registration for notifications is already quite low level.
> It would be impossible to consolidate push notifications or throttle them for bad actors though
At least at the moment, I don't think there's a need to consolidate push notifications into the same packet for different apps. The rate of notifications isn't high enough to matter.
For keepalive pings (if the underlying radio network can't provide events to piggyback on), and consolidating pushes (if that is needed), voluntary cooperation on timings among good actors would allow incoming packets to arrive around the same time, and the mobile base station could, if a protocol was agreed, queue and coordinate the transmission time of those packets as a group, or coalesce them into a specially-addressed packet representing the group.
For throttling bad actor pushers, the device itself (kernel or daemon) could block sockets and source IPs that are sending too fast.
Presumably there's already some mechanism in place for things like SYN attacks. If there isn't, bad actors already have a way to drain your battery.
The savings are from letting radio go to idle. If you have more than one (ideally non-cooperating) services that are keeping the radio permamently on, you won't ever get to idling and say good bye to battery.
What does the software solution look like that distinguishes between a crypto miner and a media player?
How can you tell when an app legitimately needs access to files from another app versus being malware of some sort?
There are bad actors abound but many users were navigating the environment semi-ok, checking for information on how bad their apps were acting.
The clampdown is both for the user but also enormously user hostile. We can try to pin down how justified or not it is, but it bloody sucks either way & I am worried, really worried, with current events like Mozilla & Apple teaming up to decry webmidi & ambient light sensing as enemies. Yes they have some risk? But mostly this comes off as farce to me, & spun with heavy marketing "be afraid" FUD.
I truly hope Pine phone picks up share (and performance/ functionality) so people who want this level of control over what their phone runs have a platform.
A lot of people don't know how to manage their phones. I know how to manage performance on my computer but would prefer to not have to do the same on my phone. I suspect I'm not the only computer professional who wants to leave that sort of administrative detail to their work life and not have to deal with a phone that crashes due to a poorly written app.
I suspect this is why the iPad is so popular. It has much of the power people expect from a PC, but removes much of the headaches associated with them.
My feeling here is there is space for managed platforms such as the phone and the iPad; less managed platforms like the Windows/ MacOS; and truly open platforms like Linux. I'm not sure open platforms are very well suited to phones myself, but I'm not against them either.
Stop mistaking your unique desires for those of the vast majority of smartphone users. Very few care about alternate push notification services, or sideloading, they are happy to use the default app stores and services.
Even with the restrictions in place, Facebook and other apps have been caught abusing privileges to get more CPU rights and burn up battery life (and get collect user information).
https://cheapskatesguide.org/articles/techno-cage.html
There has to be space for more. General purpose computing getting snuffed out under the new security regime is accepting the abyss, & we must strive for more.
Except since our community actually knows stuff & we have users interests at hearts & it's open source, places like Debian would be largely immune to most of the horseshit.
1. From client get a push url.
2. Pass that to your app server for future use.
3. Send notification json to that url.
4. That url points to the specific browser vendor's Push notification server, and when it recieves a notification from your app server. It relays the message to the client.
And that url is different for different browsers.
Firefox - https://mozilla-push-service.readthedocs.io/en/latest/
Chrome - uses FCM
Can't configure a custom push server endpoint, like self hosted server without shipping your own browser.
So the only way to get push notifications on, say, apps that provide a client for generic protocols or self-hosted services, is for either the app developer to run a proxy gateway (which inevitably runs into scalability issues forcing them to start charging for it or require registration with free quotas), or for you to create your own build of the app. I ended up having to do that with Linphone, rebuild it under my own app ID with my own FCM creds, just so I could get push notification integration with my own SIP server instead of having to keep a background SIP connection open to receive calls.
This is completely silly, with the only free endgame being everyone has to compile their own apps and have one app installed for every potential provider, even if they share a protocol.
trivially addressed via a proxy, which you’d want anyway to properly monetize it
There's probably no wish to monetize, just to distribute working apps for free.
You're right that the issue is easily addressed with a proxy.
But now you need to maintain and pay for a proxy in perpetuity, for other people to use who aren't paying anything.
Even if it's cheap, maybe you don't have the time. It will break occasionally. Knowing there are people who may depend on it 24x7x365 is burdensome too. You'd like to have vacations.
It's not very open source friendly if other people can't just take your software and run it themselves without depending on you.
Those other people can avoid depending on you by registering themselves with FCM, but having to do that is not open source or self-hosted friendly either, which was the GP's point.
A: Never work, because NAT isn't going away (even with increased IPV6 adoption). Even locally it will work less and less because "block all incoming connections" host firewall configs will eventually become the norm.
B: Be a security risk waiting to happen (EX: Chromecasts using UPNP to expose themselves to the internet, which were immediately blasted with broadcasts from one of PewDiePie's wretched fans).
If energy used by firing up the CPU frequency plus the 4G radio to send some packet is the main battery drainer, why not just synchronize the poll of multiple notification servers?
The CPU will be waked up, a few data packets will go to a few notification servers, then in the common case of no notification everything goes back to sleep.
If it's the network that wakes up the phone when some packets are there (as WiFi energy saving does), if synchronized in time (NTP goog enough) it should also work and be energy efficient.
Probably naive, curious about real world measurements in this area :)
But imagine you are a company running one of the big mobile platforms. You could invest effort in the APIs and OS behavior to do this, and the payoff would be loosening your grip on the ecosystem. Tough to justify to those watching the ROI.
Google/Apple work directly with carriers to extend the timeouts for their push services so the phones aren't required to send keepalive packets every 30 seconds to keep the connection alive. Carriers won't be willing to do that for every random server out there.
This is just one of many ways these push services are carefully designed/operated to save as much battery life as possible. If you had more than one notification service, battery life would degrade to the worst performing one (the radio would be forced to wake up to keep every notification service alive... Even if the Google one could go minutes between the keepalive packets)
(Another is the way Google batches low priority notifications... Sending a push message won't immediately wake up a phone - it delays to try to batch as many messages as possible. This scheme breaks down if messages aren't all routed through a single server)
Before manufacturers come up with there GCM alternative, each apps actually have there own service to handle push messaging. It is fine when the number of apps is small, but drains a lot of battery when it gets larger. So manufacturers started to introduce some aggressive strategy to kill background processes to save batteries, but it also makes small developers' app less usefull. It is because apps from big corporations usually get a pass, while others will be killed. Now, as far as I know, manufacturers have their own GCM alternative now as an alliance.
So I think even if you don't have it, you eventually need one, because it is too inefficient to let each apps handle this by themselves.
https://dontkillmyapp.com
>why not shutdown location and frequent play service updates as they aren't helping my phone battery either
They do. The recommendation is to use the location library that batches GPS use instead of manually calling it per app. The playstore uses heuristics to know when to query for updates and when to download. Its better that the OS batches these sorts of things.
There may be some valid critique but this article is devoid of anything useful.