Fuck Cloud Messaging
telegra.ph
telegra.ph
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.
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.
This is stated right before the steps you show. Only the one who doesn't read will blindly add analytics.
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.
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.
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.
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 ?
And there is microG, to hook into the Google way of doing things.
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.
>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.
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).
However, the Push API refers to a recommended IETF protocol for providing the push service: https://tools.ietf.org/html/rfc8030
> A self-hosted push notification service.
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)
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.
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.