> Problem: The Firebase Android client library is proprietary, meaning FOSS apps can not use it. Apps that do not comply are reported to the user as "using too much battery".
It doesn't matter how much money Google is going to have to pay in the future as a fine for this practice. The amount of money that they will get for kicking out the competition is going to be way higher. That is a learned lesson from Microsoft (and probably others before them).
> It doesn't matter how much money Google is going to have to pay in the future as a fine for this practice. The amount of money that they will get for kicking out the competition is going to be way higher. That is a learned lesson from Microsoft (and probably others before them).
The competition in this case is Apples iOS, for which even HackerNews users love to harp over and over and over again how amazing it is and how little battery it uses because it doesn't allow apps to use anything but APNS, run anything in background or even include GPL source code.
This is what's Android competing against - an completely locked down operating system which cannot deliver any kind of GPL code. And every time it allows more freedom to developers it's punished in the market by losing against iOS and mocked on this very website about how it allowes their app developers to drain battery and access data.
I don't think you're focusing on the entire picture.
Some people here like iOS for the reasons you described. However I'm willing to bet, unless you can show me otherwise, that it's a vocal minority. I don't know of anyone personally who is happy that Apple disallows GPL code.
Comparing Apple's digital Fort Knox with Google's unsupervised free-for-all is a false dichotomy.
There exists a happy medium, where power users get all the freedom they want but apps are still by default beholden to certain restrictions. And this is orthogonal to a proprietary API.
> There exists a happy medium, where power users get all the freedom they want but apps are still by default beholden to certain restrictions. And this is orthogonal to a proprietary API.
Is this not the happy medium Google is trying to hit?
Power users can unlock their bootloader and do whatever they want. This is still officially supported, with vendor blobs officially provided.
By default things are restricted to deliver a happy user experience in the context of the average person that just wants a product that works. But you're free to do whatever you want. There's (usually) even controls to remove restrictions from apps manually without doing the custom ROM route, but there is always the ultimate power user toggle there of "flash a custom ROM"
Unlocking the bootloader is becoming increasingly rare.
To be honest, ignoring the back and forth between the discussions here, am the only one that doesn't get WHY the firebase library isn't open source? It could just be GPL right? Most of the interesting stuff happens in the backend anyway, so what's the issue.
Am I also the only one that thinks this gives google the chance to lock out/cripple third parties like huawei or other non certified android vendors from distributing Android apps that were built for the play store.
> Unlocking the bootloader is becoming increasingly rare.
This is a bit of "you get what you buy" territory. Google's devices have official bootloader unlock capability and always have, with instructions here: https://source.android.com/setup/build/running - already updated for the Pixel 3a & 3a XL even. You take your risks when you buy something that doesn't advertise that.
> Most of the interesting stuff happens in the backend anyway, so what's the issue.
I think most of the interesting stuff on the device is even in Google Play Services and not in the firebase library. I have no idea why the client SDK can't be open source, but how much does that even matter?
I just bought a new Pixel 3a only to find out that my cell provider locks the bootloader until I've paid for 3-4 months service with the phone, despite previously having an account with them.
This was not mentioned at any time during the purchase and they would not take my phone back.
I don't know the ins and outs of this, but wouldn't that still mean that the app would have to rely on google infrastructure to do push notifications? That might be a fix for the licensing problem, but it wouldn't address the problem that that would move virtually all remaining google-free (-ish) messengers into googles direction, with the potential for centrally siphoning of (meta-) data
For completeness' sake: even power users cannot really do with their devices as they please, if they don't happen to be kernel hackers with a few months' worth of time to spare.
If google was trying to hit some sweet spot (I'm not willing to give them the benefit of the doubt here any longer) then they would not spout such obviously wrong BS to scare users into submission. Conversations and telegram both put the work into doing push notifications The Right Way (TM) so scaring users about this is stupid at best.
> even power users cannot really do with their devices as they please, if they don't happen to be kernel hackers with a few months' worth of time to spare.
But whether or not you consider this a "power user" or not is obviously less clear cut. How you define "power user" does of course change things. The point is just that there is the ultimate escape hatch of flashing a custom ROM, and it's not THAT hard to do, especially with all the tools out there to flash things like LineageOS super easily. You may not understand what it's doing, but it is at least sitting on officially supported things for the devices Google sells.
Not sure why you are bringing this up. The point of this thread is the misleading warning or other OS level changes that are forced upon you if you don't use FCM. Changing that behaviour needs changing AOSP.
Then it's a real shame they haven't paid attention to the documentation for NotificationBuilder, because there's a straightforward solution to the problem they're complaining about.
Essentially it works like it should anywhere else: If you don't publish source code and someone complains, you're out. In an ideal world Google Play would hold itself to the same standards.
However, the App Store does impart restrictions which are incompatible with GPL, so it's not so much that Apple doesn't allow it as it is that GPL doesn't allow it.
Apple has no official statement on this of course, but we know how they feel about GPL code given that they've removed every bit of it from their OS over the last few years.
They haven't been removing GPL code actively, they decided not to take the risk of using GPL version 3 software, so they've let the respective versions of bash, rsync etc. linger at their last released GPL version 2 releases.
E.g. Git is on GPL version 2 still (and probably forever), and Apple continues to update that in a relatively timely fashion.
You attributed the incompatibility to the GPL. Apple created the incompatibility. Apple could easily fix it. The FSF can't change existing versions of the GPL.
Apple has been slowly phasing out GPLed software from their own software, such as Catalina's migration from Bash to Z Shell, but even writing third party apps with the GPL has apparently been problematic in the past: https://thenextweb.com/apps/2013/07/18/vlc-for-ios-will-retu...
The issue is that the Apple dev ecosystem creates encumbrances that prevent users of GPL binaries from relinking them. That is a GPL violation and such binaries are not compliant with the license.
How? I'll debate FSF ethics as much as the next guy, but they clearly state they want end user freedoms such as the freedom to modify the application you use. Apple clearly doesn't want that if you use specific GPL versions.
I don't know of anyone personally who is happy that Apple disallows GPL code.
And this is what you call a geek bubble. In the grand scheme of things most people don’t know what the GPL is and out of those, only a minority care about it running on their phone.
So you have friends that are not geeks who know about the GPL and care? This is the opposite of the “No True Scotsman”. Anyone who knows about and cares about the GPL is s geek.
> Anyone who knows about and cares about the GPL is s geek.
No, that would be a regular No True Scotsman.
> So you have friends that are not geeks who know about the GPL and care?
Did I say that? No, I didn't say that. I said I don't know anyone who is happy that Apple disallows GPL. This includes people who have no idea what the GPL is.
The difference is Apple has been the same from the beginning. There was no bait and switch. People who bought Apple products knew what Apple was and will be and what the terms were.
With Google there is a bait and switch (and it doesn't really just apply to this particular story). They came to market defining themselves as the open alternative to Apple to get market share and developer interest (and evangelism), and now that they've achieved dominance the terms are changing.
There's no surprise that there's going to be massive pushback (and probably antitrust implications).
Exactly. We see the same pattern with Chrome and the new course it's taking.
The reverse is also true: whatever sufficiently good product that doesn't generate money is basically doomed by them no matter how many users depend on it. (Reader, Inbox, Talk, ...)
Personally I've always bought Android (and while it lasted Firefox OS) phones because of the option to easily tinker with the phones. If/When pure linux phones make a come back I'll be moving on to them. Of course nerds being nerds is an outlier.
An ideal platform would use a foss compatible framework. It would allow the user to configure which server to use to push notifications(one server for all apps, since that is needed for battery reasons). Notifications would be encrypted with the apps key.
Often times even having configuration options creates surface for security issues.
A good example of this is that there were scams that involved having people paste some script into their chrome devtools and steal data. This worked fairly effectively. Facebook ended up doing some magic to show a warning message in the devtools console to tell people that no, you really shouldn't paste random stuff here, it will do bad things.
Configurability does come with a cost. And "the ability to reroute all push notifications through an arbitrary MITM" is a security cost that I expect wouldn't be worth it.
But I actually think you are mis-portraying the situation is because I don't think the average adult has the ability to comprehend these things. It's not the difference between adults and children, but adults and expert adults.
Here are some analogies to other parts of society that we don't have a problem with:
Seat belt laws
Hard hat required construction area
Safety guideline in Handling of hazardous materials
We basically said society doesn't trust you to decide for yourself about your safety - you just have to follow the rule.
>It's not the difference between adults and children, but adults and expert adults.
Part of me wants to challenge the existing groupings of adults and children where all that matter is if you have been around the sun 18 times or not. This is but one weakness in the existing grouping that furthers my questions, such as why do we allow the non-expert adults a vote over laws, but deny a 17 year old the same?
I think if you take the groups of children, adults, and expert adults you will find upon reducing them to only two groups based on similarity that you are left with experts and non-experts.
Except a large portion of society thinks seat belt and hard hat laws are bullshit and shouldn't even be legal to enforce. Hazardous materials handling is completely different though.
The impulse to protect people from themselves is a dangerous one. In the article itself we see that in practice it is used to push inescapable spyware.
"But our spyware is better than their spyware!"
Google says they will protect you. But the truth is they are just concern trolling to shut down marginally worse competitors.
For kids and elderly that can't make decisions on their own it could be default -locked to some entity contractually bound to good ior. Locked with an administrator password. That would be a reasonable compromise.
No the truth tends to be more banal - making everything replacable in configurable means more (paid) engineering work for Google engineers for what's, essentially, building infrastructure for competition. What would be the compelling business case for Google to do more work to enable removal of their own product?
This is possible to build on Android right now and something I've thought about myself. There is nothing stopping you or me from implementing it, and I've always thought that Amazon should have done it to make it easier to port applications into their ecosystem.
I use an iPhone currently but I'm wishing for an Android instead, precisely because Android allows some Free Software apps that have no equivalent for iPhone.
But yes, I agree, Android's competition is iOS and that's freaking sad.
I did, but then I'd expect the GPL group to actually comment with the same zeal on Apple articles... but Apple criticism seems very muted in comparison.
That was exactly the state of the Android until 6.x or so and I've had multiple frustrating hours of mentoring Android developers on how to do notifications respectfully just to be ignored with "eh, I'll poll every 10 minutes, it's easy and it works!".
And this has been my experience constantly:
- "Eh, I'll just demand full storage access for my game, it's easier to unpack files in root of sd card"
- "Eh, I'll just constantly reconnect HTTP no matter what the current device state is"
- "Eh, I'll just download 600mb on mobile, it's easier than checking"
There are some developers that did right by users, but enough Android devs are constantly ignoring the best practices of development and users privacy because it's "easier" and requires less code.
Because of that I fully understand Google's new stance: developers haven't proven themselves trustworthy and it seems Apple's way is the only way to defend users against abuse.
I do believe you when you say a lot of devs are taking the easy way out and wasting device resources. But some devs do things right. And those devs are the ones being penalized. Perhaps worse, the user's choice of apps has been constrained.
It would have been so much better if the Play Store and SDK and Android platform could have features that clearly highlight these resource-hogging apps as bad actors. That's the kind of killer feature I expect from Google. I don't feel like they're living up to their reputation for hiring brilliant programmers. Instead they're taking out a really large hammer and hitting everyone with it.
Defending users by actively lying about battery usage is not acceptable.
Battery meter in 8 was accurate and flagged battery eating apps accordingly. This new thing is actively lying when you don't use Firebase, as if nobody can ever correctly implement push notifications.
> This new thing is actively lying when you don't use Firebase
It is lying, alright.
That said, I don't think that this lying notification is the best example of Android designers being nefarious jerks. The notification lies to user about non-existing "battery drain", but it only does so when developer tries to get around the requirement to show notification with foreground Service. It is shown when you set notification to be hidden via low-priority. I have also seen it when notification icon was fully transparent. It is basically a retaliation against developer misconduct (when developer tries to run persistent background process without telling user). Ideally, this should encourage developers to show a proper foreground Service notification, which the user may consequently hide via notification settings.
I'm not sure what you're talking about exactly? What's the "new thing" in your post?
(Btw, the on-device battery meter is horribly inaccurate and always has been. Multiple values, like screen power use, are hardcoded by OEM and tracking app power use is not reliable in any case because those graphs are incapable of measuring cascading power efficienty effects coming from using the radio or Play Services.
Use Battery Historian if you want more useful battery use debugging.)
So, if I understand correctly, the GPL prevents you from using a non-free library in your code? (Asking honestly: I have tried to find this elsewhere but the FSF page on the GPL is rather ... convoluted).
If that is so, then this is obviously a killer and quite seemingly arbitrary requirement. Your MS example is quite good.
The GPL requires that all code with the software under the license to also comply with the GPL, which includes libraries. Therefore, it's simply not possible (legally) to use non-GPL compatible libraries with GPL software. A lot of open-source licenses are compatible, such as the MIT or BSD license, but proprietary licenses are not obviously.
If you are the creator of the GPL software you can do what you like, link Firebase to it, distribute the app and release your code as GPL. You're effectively 'granting yourself' a proprietary license to use your code and a GPL license for everyone else to use it.
However it means nobody else can release their own apps (with notifications) on Android based on your code, or anyone else's GPL code. As soon as they link to Firebase and distribute they will violate the GPL by distributing a binary of someone else's GPL code with a proprietary library attached.
You cannot however use anyone else's GPL code while doing this, because those library authors didn't give you permission to relicense their code. It closes off the entire Play Store to the GPL. This is the same thing that caused the FSF to declare Apple's iTunes store as incompatible with the GPL. Curiously, I think the iTunes TOS clause that disallowed copyleft has since been removed, but I haven't heard anyone more qualified than I offer an opinion on whether you can now publish GPL iOS apps.
Yeah I'm confused too. I run an open source Android app used by a bunch of Universities, I'm not sure what this means? Surely you can still open source apps that use Firebase to send messages, you kind of don't have a choice.
I don't get it. The Telegram GitHub says: "Since one can't use Google's push messaging in a FOSS app", but I can't work out why? Lots of FOSS apps on GitHub, mine included, use Firebase. It had never occurred to me it might be an issue.
A GPL app can absolutely link to proprietary software and still be covered under the GPL.
From the GPLv3 itself.
> The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
Now you can't just go and include random proprietary jars in your app for whatever reason but but linking to the jar for the purposes of using the system notifications and background services seems to me like it would definitely count.
I personally would consider notifications and the ability to run in the background to be essential but there's a better test which is the reason that this exception exists in the first place.
From copyleft.org:
> The system library exception is designed to allow copylefted software to link with these libraries when prohibition of that linking would hurt software freedom more than it would hurt proprietary software.
This is really the core of it -- who is hurt more by disallowing this linking: Google or FOSS apps?
As a daily reminder, this piece of junk will be countermanded by Samsung, Lenovo and Huawei and whoever deploys AOSP as they use their own push platforms.
Note the GPLv2 doesn't allow the exception to apply if the library is distributed with the app. GPLv3 doesn't draw a distinction between distributing with the app or linking to something already on the system. But IANAL.
As long as it doesn't require linking to a proprietary Windows library to interface with the NT api. That would violate at least the GPL 2. Though you could do it yourself, and release your own code as GPL (and the combined work as proprietary), no one else could distribute the full work under the GPL because of the incompatibility.
It should also be added that the whole backend is proprietary (and was for GCM as well) and is being maintained and paid for by Google.
Having said that, making firebase-messaging GPL-compatible library seems to be something that should make a lot of sense for Google to allow GPL apps to be released on the platform.
> Problem: The Firebase Android client library is proprietary, meaning FOSS apps can not use it. Apps that do not comply are reported to the user as "using too much battery".
This is simply not true. These two points don't even make a coherent argument, as it's plainly discernible that lots of apps don't use the Firebase Android client library but aren't "reported to the user".
Furthermore, "using too much battery" is not what the notification says. It simply says "is using battery", and even this is avoidable.
Windows 8.1 was absolutely determined to convince me that my brand new i5 was incompatible with Windows 8.1. MS hasn't stopped with the incompatibility garbage.
This has been coming for a while. We attempted to create a push-based notification system based on MQTT. It worked well, then the notifications started getting lost. Turns out, the receiver service was getting killed in the background. We found out the best way to get reliable notification was through Google's own GCM (which has now moved to Firebase Cloud Messaging.
We learned its incredibly difficult, if not impossible to build an app (with reliable notifications) that do not use Google services.
You can say its in an effort to maximize battery resources, which I totally understand, but by requiring a Google service (and now library) you are truly tied in to and reliant on their systems.
This has been true for awhile once they forced apps to use API26 or higher (if you want to be listed in the Play store, and really, there is no other place if you want decent exposure.)
I had a similar experience switching from "real background" to using FCM. I understand the battery saving motivation, but the problem is that the performance of the google service is terrible. The response time of my simple notification system was nearly instantaneous, but OK google, I'll play your game. I put together something that used FCM and it can take 15 or 20 MINUTES to get even a "high priority" message from FCM.
Reading the google docs, apparently google will deprioritize notifications that are shown but "not intereacted with" in a timely manner, so that is another source of delay.
I think the crux of the matter is that notifications have multiple purposes: signaling, and advertising, etc. Google hasn't provided a way for an app to declare its use case. So, you get policies to prevent notification spam creeping in and messing with basic app signaling functionality.
In the end, I kept both my "in-house" notifications for use by older Androids, and a kluge that uses FCM in addition, with some hacks to get somewhat better FCM performance. I live with the notification in Oreo+ and just tell users to ignore it (but honestly, I don't think users care that much.)
>The response time of my simple notification system was nearly instantaneous, but OK google, I'll play your game. I put together something that used FCM and it can take 15 or 20 MINUTES to get even a "high priority" message from FCM.
Letting your phone actually sleep is the battery saving feature. Also, you get throttled for high volume so check that as well.
If you think your messages are so important to have a constant socket open then make a foreground service. You're abusing a system that is really not suited to your needs.
Some types of messages do require immediate attention of the user, or are of highest value if delivered immediately. Instant messaging apps have been using notifications for a long time and did not require a foreground service. Expecting instant delivery of that class of messages is not abusing the system.
Even Apple, with its distaste for background processing, lets you declare an app with "VOIP" mode or something, where iOS manages the socket for you. You get access to simple server-based signaling, and as a bonus, you get to avoid the whole push-notification system.
Google just seems to have glommed everything into FCM. In the FCM console, push-notifications are really treated as a user-engagement/advertising thing. Throttling and spam prevention makes sense for that.
Maybe Android has something like the iOS VOIP mode that doesn't involve annoying the user with scary battery notifications, but I couldn't come up with anything at the time.
While it's not really possible to do this in your own background service any more, GCM still supports this use case. This is the deprioritization the grand parent is talking about. If there's already a notification showing you won't get instant follow up responses. It's a compromise to be sure but if you want to break that compromise you have to make a foreground service.
It was supposed to be possible, via standard notification mechanism and scheduler, new in 7.x. If Google starts flagging apps pinging network off the scheduler, everyone will get even more angry, as there will be a glut of foreground notifications just because they broke a use case.
For my use case, the volume of messages was not an issue. This isn't a huge app that is pushing out tons of notifications. We're talking 10's or 100's a day, maybe.
In fact, it didn't matter at all once the initial notification was visible whether follow-on notifications were displayed. Possibly the fact that I was locally dropping the notifications (because the user didn't need them), the system counted those as "notification that weren't interacted with, so I'm going to slow you down at the server."?
I have no idea, and no way to find out, since FCM is pretty opaque at this point.
15-20 minutes for a high-priority FCM message isn't normal.
Either your app is being rate limited by the server, or there's something unique about your network setup that is preventing push messages from getting through. There's not enough context here to know what's going on.
(Plenty of instant messaging apps use high-priority FCM messages, and get near instant delivery.)
I agree, it isn't normal, and I was scratching my head at the time as to why FCM would deliver the messages near instantly on older android models. The delayed delivery happened on Oreo+ phones. Oddly, I also noticed Whatsapp not delivering messages in a timely fashion (even when I had it opted out of battery saving). Background notifications in general started acting odd for Oreo+ phones.
> There's not enough context here ...
Sadly, actually getting context you can use to debug something like this from FCM is nearly impossible. The end result is you just take a WAG and hope for the best when the app gets in the field.
Signal switched to FCM about 4 months ago and I've had constant delayed-notifications issues too, usually in the 20 minute range. I can see the problem in Signal itself, the "sent" and "delivered" timestamps will be 20 minutes apart despite be actively doing stuff on my phone -- so the internet connection is there and the phone isn't sleeping. When I actually re-open the Signal app all the notifications flood in at once.
Maybe Google is assuming I don't care about Signal notifications because I don't always "interact" with them right away (I'll leave messages on unread for a bit if I'm busy), but I really wish there was a way to mark Signal and other instant messaging apps as "always high priority". Signal has battery optimizations disabled but that doesn't seem to help.
Hey! Signal dev here. We've actually seen delayed notification both before and after the switch to FCM. My guess is that newer Android versions are just becoming more and more aggressive with their battery optimizations.
We send high-priority FCM messages, but the device will still bundle them together in order to deliver them in batches. Even worse, there are times we are delivered an FCM message but network access will be invisibly restricted, further delaying our ability to retrieve the actual message content (for obvious reasons, we can't include the message content in the FCM message itself). We're continuing to try new things, but it'd be nice if there was some official guidelines on how to avoid these FCM pitfalls.
If you receive "actual contents" separately from GCM ping, you are probably being hit by Doze Mode. Doze is disabled for foreground Services, so your best bet is starting a foreground Service (via startForegroundService) _and_ taking wake lock (from within foreground Service, after your app is considered fully foreground).
Historically Android devices used to sleep by entering low-power CPU mode (sometimes complete with low-power radio and WiFi modes). In that mode all apps and kernel are heavily CPU throttled to the point when you can get network timeout because kernel TCP stack can't send packets fast enough. This is what gets disabled when you take a wake lock.
Doze Mode throttles individual apps by moving them into low-priority cgroup. In effect Linux kernel hardly ever schedules your process anymore. Doze Mode is not disabled by wake locks, only by starting a foreground Service.
Both Doze Mode and low-power CPU mode can coexist, leading to effectively 110% loss of CPU time by your process.
Interesting, so our current method is to do just what you said -- start a foreground service and acquire a wakelock. But we only do it if our network request takes longer than n seconds (to avoid always showing foreground notifications). We still hit the issue. Other Googlers have told me I may be running into some race condition that happens with foreground services and doze.
Thank you for the detailed info about how those modes work though -- it certainly de-mystifies the network problems!
> Interesting, so our current method is to do just what you said -- start a foreground service and acquire a wakelock. But we only do it if our network request takes longer than n seconds
This won't work. One of the less documented properties of Doze Mode is it's ability to sever your network connections. It can already be in action before you start downloading message contents. It can also kick in during the download. If you want reliable delivery, you have to take wake lock and enter foreground mode immediately after getting GCM push.
Look up, what is WakefulBroadcastReceiver, and why it used to be necessary. The class itself is deprecated (because implicit broadcasts are largely obsolete), but it shows, how one can miss opportunity to take a wake lock, causing entire application to be caught in deep CPU sleep. Google promises, that GCM will bring you out of Doze Mode, but I am not sure, if that also applies to wake lock. Your app may be sleepy because of failure to timely take wake lock, causing it to miss time window when Doze is temporarily lifted by GCM.
Thank you for your work on Signal. Despite my griping, Signal is still my primary messaging app and I love it.
>there are times we are delivered an FCM message but network access will be invisibly restricted, further delaying our ability to retrieve the actual message content
This is new... If this is happening regularly, maybe you should display a generic "message available" notification? I assume actually opening the app un-restricts network access and everything works fine from there -- it'd be nice to know I have a message waiting in limbo.
> I put together something that used FCM and it can take 15 or 20 MINUTES to get even a "high priority" message from FCM.
(from what I remember of some android documentations) Your definition of "high priority" is different from Google's one, which is also different from the end-user's definition. Google probably favors the end-user's preferences more than the developer's preferences. If the user wants all notifications asap from a particular app, the system will do a best effort to deliver, given all the other apps notifications and the current battery level.
Have you tried using VAPID? I didn't want to use firebase and the pwa app I made uses VAPID instead and push notifications show fine. Couldn't that be used in native push notifications, too?
So to summarize, to save battery all notifications on Android (since two versions ago) have to go through a single notification service (rather than each app having the option of continuously running in the background and maintaining a connection with its own notification service). Recently Google killed their GCM notifications service in favor of Firebase Cloud Messaging, which (unlike GCM) unfortunately doesn't have an open source library available for it at the moment.
Does that sound right so far?
Anyway, the Telegram-FOSS team claims that this doesn't _actually_ save battery:
> Despite Google's misleading warnings, there is no difference in battery usage between v4.6 in "true background" and v4.9+ with notification.
But this seems rather unlikely to me. Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all? Or am I just misreading that statement?
> But this seems rather unlikely to me. Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all? Or am I just misreading that statement?
I don't see how that could be true - Android has seen massive battery life improvements after introduction of Doze which forces apps to sleep and stops the from constantly waking up radio and main ARM core. FCM is the only service that can wake up the device remotely and includes throttling code.
Before these changes Android had severe idle battery life issues (which were happily mocked by owners of locked down and proprietary iOS devices on this very website) since multiple apps waking up radio for notifications/synces caused radio/cpu to run pretty much constantly. It's worth noting that just doing a radio ping can increase power consumption by as much as 100x for next few minutes.
Maybe the Telegram report ignores the fact that they aren't allowed to wake up the device anymore. If you're measuring in isolation it's easy to make a case for "not making a difference".
There is no way to wake up a device remotely ever. Firebase is doing the same thing anyone can, running on a schedule. It just batches the comms in one time slot.
Android scheduler mechanism was supposed to offer the same benefit.
> Are they saying that an application running continuously in the background uses the same amount of battery as an application that's not running at all?
A single application running in the background probably uses only a small amount of extra power compared to the notification service alone.
However, a couple dozen applications -- all running in the background in order to enable notifications -- probably consume a lot more power than a single service.
There's also a wide variety of possible implementations of a notification service, and not all of them will necessarily be as power efficient as what Telegram-FOSS does.
The phrase "running continuously" makes it sound like they are doing something... but they aren't: they are blocked reading on a socket. The only time they would run is if they receive information, which is exactly when they would run anyway (as they got a notification). The difference in battery usage would essentially be down to subtle effects caused by the private memory of that process (which might be negligible) not being able to be used as a cache to make some other process more effective. The only reason this would matter is if the processes are forced to wake up occasionally to actively send some kind of keepalive on the socket (which would be an arbitrary requirement caused by the network), which still frankly would not necessarily use much battery if the OS does intelligent gathering of wakeups from multiple processes (like, it would exist and be measurable, but seems strange to me to be something to care about as the phone is probably already waking up every now and then to do other stuff Google wants). I mean, if the notification comes in and the app wouldn't have to wake up to process it normally (which might prevent paging some executable code in from flash) and the notification itself could be delayed into some kind of batch, then maybe? Apple actually does do some of this kind of stuff on iOS: I would bet Google doesn't.
GCM/FCM will delay low priority notifications, in order to batch as many together as possible.
On top of that, the cell networks don't allow keeping a socket open for more than a few minutes without sending keepalive packets. Unlike on desktop, keeping a socket open isn't "free" on mobile.
Waking up the cell radio has a significant penalty on battery life.
So you just batch the keepalives, like the old Nokias were doing. Reaching 1 month long battery lifes with Jabber on.
Absolutely no difference 1 having to send 1 keepalive every 5 minutes than 30.
This is just a subversion of basic networking in order to centralize everything through a single provider and as usual the users are trained to see it as necessary without questioning it.
> On top of that, the cell networks don't allow keeping a socket open for more than a few minutes without sending keepalive packets. Unlike on desktop, keeping a socket open isn't "free" on mobile.
That's right. And it should work as advertised in the documentation.
Anyway, I was responding to the "cell networks don't allow" part of your comment. Cell networks don't have a say in what I do at IP/TCP layer.
They literally said that cell networks don't allow it without the keep alive. You quoted it and said they were wrong because... you can use a keep alive. I'm confused as to what you're correcting.
There are collaborations between mobile network providers and push notification providers to get these sockets special-cased. I.e., they won't need keep-alive at any regular interval. So the radio can actually get layer-1 pings (like, when you're called, or get an SMS) for push notifications.
The main issue with what you're mentioning is usually the fact that only Apple and Google servers tend to be whitelisted on telco routers for long polling connections. Trying to keep long-running HTTP connections for everyone else tends to be extremely hard on battery life since telcos can kill of connections even as often as 2 - 5 minutes. Powering up the main core and radio so often will make your phone hardly last 12 hours.
Are you kidding me, my old Android 6.0 unupdated S7 can easily top days when idle and polling radio only.
The main battery killer is, and always has been, the screen, followed by CPU in high power state.
[Firebase team member here] As far as I am aware, GCM never had an open-source client. In fact I don't think any "play-services-{x}" library has ever been open sourced.
> Despite Google's misleading warnings, there is no difference in battery usage between v4.6 in "true background" and v4.9+ with notification.
This doesn't sound like the right comparison to me -- shouldn't they be comparing FCM against the background app/persistent notification approach? Here, it sounds like they are comparing the background app approach against the persistent notification approach, but those are AFAIK basically the same technique, except the latter shows an annoying notification whereas the former didn't. So of course the performance would be the same.
I don't think so. A "notification service" isn't something that exists solely on the user's device; there's also a server-side component that each remote service that wants to send a push notification has to interact with.
So for Android to support alternate notification services, every app/service that wants to send push notifications would _also_ have to support those alternate services on their backends.
I think they said they aren't using any more battery than they were using before.
Sure they could implement their software using less battery, but these Google warnings could apply to anything. This app could perform better. This app could be smaller. This app could have less bugs.
The only thing that they can't say is: "This app could be more secure."
For example if you're building mingw32 based GPL C app, you're linking to all kinds of windows system libraries and there's no need for them to be under GPL.
If this notification library is available to anyone on Android and is part of the Android system platform, can it be the same, like some DLL that does notifications on windows?
But my "system" isn't AOSP. It's my OEM's specific packaging of AOSP along with Google services and other components. Why should the line be drawn around AOSP specifically?
I think it depends on if the library is distributed with the app or with the system. In this case, the library would be distributed with the app I believe, meaning it would not be exempted.
You can still write free software that uses it and produces a not-entirely-free artifact when compiled, though, right? (Is there a distribution restriction on the artifact, or is it impermissible to link it with GPL apps, or something?)
I'm curious if the free software apps are compelled not to link it to preserve the free software status of their code, or just voluntarily refusing on principle (which is laudable, to be clear).
Only if you are the author of all the code, so that the GPL doesn't actually apply to you.
In this case, the Telegram-FOSS people take the original Telegram source (which is GPL licensed) and redistribute it, so they can't distribute a non-entirely-free apk without violating the original license.
Other apps using, for example, GPL licensed libraries or accepting third-party contributions under the GPL exclusively are also forbidden from redistributing non-entirely-free stuff.
Other apps using, for example, GPL licensed libraries or accepting third-party contributions under the GPL exclusively are also forbidden from redistributing non-entirely-free stuff.
Or even just copying bits of GPL-licensed code in themselves.
There seems to be a lot of Telegram bashing but every assertion I saw eventually failed to be backed up†, if at all attempted. This ends up triggering my BS detector every single time, and the significant influx of such occurrences makes me think of some astroturfing/FUD campaign.
† I also do my homework when fact checking, but failed to turn up anything relevant, only more non-backed up assertions or obviously inflated beyond proportion facts twisted beyond recognition. I may very well miss something, that's why if backing up material is known by the detractors it's always worthwhile to share (which applies to any pro/con discussion really)
I’m doing the research work for you, though it’ll be a while before I can stop procrastinating for long enough to write a whole thing about it. While you wait, https://github.com/overtake/TelegramSwift/issues/163 is probably a good start.
I have a thing I’m writing that will go into more detail, but in short Telegram’s client applications (which are licensed under various incarnations of the GPL) are updated frequently while the source code in their publicly available repositories lags far behind. In addition, they use a number of open source libraries that at the very least require attribution, but Telegram does not follow their terms.
> while the source code in their publicly available repositories lags far behind
I don't think this violates GPL. GPL requires you to be able to receive the source if you want to, not that it be on an online repository. You might have to request it and have it sent to you.
I mean, I could, but I think it's fair for me to assume that the GitHub repository that the official website links to as the source code for their client is where they’d publish up-to-date code.
They might well publish it right there if you ask. Just saying they haven't violated the license as long as they have a written offer to provide you with the source code somehow if you ask. (That's what GPLv2 seems to require.)
They provide no alternative "written offer". On the website, they directly point to GitHub for the source code offer: https://telegram.org/apps#source-code
I’m not fully aware of the situation regarding Telegram-FOSS, but I’d assume Telegram can sue them for license violations regarding code that they own the rights to.
I have yet to see any proof of this. Granted, it's true that Telegram's backend is closed-source and that part of the infrastructure is completely opaque, but at least they're sincere about it, unlike Signal's open-but-not-quite[1] approach.
> The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
so anything that is not distributed with the operating system needs to be available as source code, so that you can credibly offer to distribute the source code to the recipients.
Thought experiment: write an application that automatically downloads and combines code with all sorts of legally incompatible licenses to create an application and installs it on an Android device. If personally doing it is legal (and basically unenforceable), what about making it easy for others to? Besides, unless you're a "radical Stallmanist" (for lack of better term), chances are you have a mix of proprietary and FOSS and use it together on whatever data you work with.
This is why I think IP laws make no sense, arbitrary restrictions are arbitrary and stupid.
My understanding is that what you describe is completely legal.
ZFS on Linux is a good example of this. ZFS and the Linux kernel are both open source, but their licenses are incompatible with one another—ie, you can't combine the code.
A common workaround for this problem is to compile the source on the user's machine. When you install ZFS in Debian, apt will automatically download the ZFS and Linux source code, recompile the kernel with ZFS included, and install the result. This is all completely invisible to the user, except for the absurdly long install time.
That would definitely be a dodgy thing to do. In general, law courts are interested in the net effect of what you're doing rather than the technical details of how you did it, and what you'd be doing in that case is equivalent to distributing the Frankenstein application yourself.
Describing in a blog post how to build the Frankenstein application is perhaps perfectly all right, but somewhere between there and the hypothetical application you described a fuzzy line would be crossed.
There's another fuzzy line relating to whether code is combined or not. Code that goes into the same statically linked binary is definitely combined, I presume. What about code that communicates via a REST API or a standard protocol? Perhaps it depends on the attitude of the communities that produce the code. The Linux people seem to be happy with non-free kernel modules in a way that some people wouldn't be.
IANAL, but I think that would be regarded as a circumvention device by a court. I hope you're not basing your opinion regarding laws entirely on this contrived case :)
Ubuntu gets around any possible GPL violations by offering to download and install proprietary drivers (ex., Nvidia) and codecs during installation process. Could something similar work for Android apps?
Yes, it would work - you could deliver the push notification module as a separate APK which talks to the main application part. It's still way more complexity than adding a GPL lib to your app.
The mechanism used by Ubuntu for such drivers is completely unrelated to GPL violations. It's just there so the non-free software doesn't get installed by default. If there would be any violation without it, there would still be a violation with it.
Just curious, does it means that a proprietary application downloaded through an open-source GPL script makes the whole (application + script) "GPL compliant" ?
I think this is misleading. To me it seems the issue is that app developers are being forced to use the proprietary Firebase service, but they are NOT being forced to use a proprietary library from what I can tell. The library in fact DOES have an open source version available: https://firebaseopensource.com/projects/firebase/firebase-an...
Sounds like an opportunity for someone to sit down and write one. The API and docs for it are fairly palatable and offer some very reasonable guidance on things like exponential backoff.
It still doesn't mean that they're going to be able to go without a persistent notification if they want to run their own background service, but that's a change that everyone is required to deal with. "Secret" background services were abused egregiously by bad actors and sloppy coders alike in the past and it's time for that to stop. This carp some people are floating about it incurring "warning" is nonsense--if they looked at the developer docs they'd see how easy it is to avoid that happening.
Since the FSF does not consider GPLv2 to be Apache 2.0 compatible, telegram-FOSS is GPLv2, and Android libraries are usually Apache 2.0, you have always had a problem.
They also use a ton of Apache2 libraries (at least 5 or 6) directly in their source repo.
They don't appear to even bother to properly give attribution/etc for the used software, so yeah.
This is so damn true I am LMAO at the other comments. So basically the entire community can get around the problem by releasing an Apache2 lic'd library that wraps whatever it is they need from firebase.
We'd be at a place no different from any other "FOSS" App on android today.
I was confused for a moment because I thought the Firebase SDK was open source.
Interestingly, though, the Android version appears to be only partly open source. I did not find an explanation as to why some of the source is not available, it is mentioned on the Github repository but not explained. In any case, I don’t see the code for Cloud Messaging in there.
It may not be that it is done out of secrecy, though. A cursory glance of the iOS SDK shows what seems to be the full iOS portion of Firebase Cloud Messaging:
Though that also raises its own question: doesn’t iOS effectively enforce APNS, and all third party providers actually must go through that? I imagine going through a single provider really can improve battery life. Each push provider needs to background fetch.
FWIW, as far as I know, FCM and APNS are both free to use indefinitely. I’ve always found this a bit perplexing since I can’t even really fathom how many messages an app like Facebook or Twitter would push per month. I wonder what the odds are of this ever changing. The cynical viewpoint could go either way.
At face value, this really does seem problematic for open source projects. Can a GPL app link to (the non-open parts of) the Firebase SDK? My guess would be no.
Hope this can be resolved :( There’s some really great stuff on F-Droid, like Amaze file manager.
(Disclosure: I work for Google, but not on Android. I don’t even use Android phones anymore.)
[Firebase team member here] Our goal is to open source all of our SDKs, and we have steadily open-sourced more of them over time. The SDKs you see on GitHub right now are all standalone, they don't require communicating with Google Play services running on the device.
Our bar for moving an SDK to GitHub is that it has to be more than a source dump, it must be the source of truth for that team's development. Right now that's not possible for FCM because of the dependency it has on Google Play services.
Is there a plan to a) Support use of FCM without play services (i.e., in AOSP)? b) If not, is there any legit path forward for cases like these short of them forking AOSP ?
Even if the SDK's are open source, a lot of the problems we experience with FCM at Signal seem to be more of an issue with devices trying to optimize battery. Do you have any advice on how to avoid the system heavily delaying notifications? We've seen instances of high-priority notifications being delayed and batched together, even for users who have disabled battery optimizations.
>At face value, this really does seem problematic for open source projects. Can a GPL app link to (the non-open parts of) the Firebase SDK? My guess would be no.
This is only partly a licensing issue. The larger problem is that the f-droid crowd has little to no desire to rely on FCM/GCM or other network services offered by google. At the very least, use of FCM would have to a part of AOSP or other (official) free software for it to even gain some legitimacy. At the moment, it is behind the play services ToS. And this still doesn't answer the question, "what if I don't want to use FCM?" If google's answer is, "Well, fork AOSP if you don't like it", we know that is a non-answer due to google's other tactics.
Google is one of the most evil companies out there for a company that started out with don't be evil. The have some very smart people, some amazing tech, but unfortunately they have some very evil people working for them help bent on maintaining their advantage by any means necessary.
Without using Google's push notifications, you are going to end up with something that works about 75% of the time. When this first started happening to me, I lost tons of time thinking it was a bug only to finally realize I needed to use Google's library to get reliability for what once worked.
I was using clean LineageOS for over 2 years, recently switching to LineageOS+microG. I'm using APKPure and F-Droid for apps, Chrome for browsing (as in Firefox, last time I checked, one tap separates you from losing all open tabs). Some apps refuse to work or break (e.g. Bitwarden does not sync), some have degraded functionality (e.g. WhatsApp sometimes does not ring when someone is calling you), many are just spamming "This program will not run without Google Play Services" (but there is Xposed module called something like "This program will run" that gets rid of these). In case of Google Maps, I'm using old version (9.69.1), and for Youtube, I'm using NewPipe.
Overall I liked the experience, battery life (especially with greenify) was amazing.
In my experience, Firefox with the Bitwarden addon installed syncs well without requiring you to install any Google services. The obvious downside being that you need to open Firefox to copy your password, but that can probably be worked around by adding a shortcut to the Bitwarden addon page to the home screen.
I don't know what you mean with "one tap away from losing all your tabs" though, perhaps you have an issue I haven't encountered yet. I personally never lose any Firefox tabs, even if I manage to make it crash somehow; I suppose what I'm trying to say is you might want to try Firefox again to see if the situation has improved.
As for maps and navigation, you might try Maps [0] or Here Maps [1] (if that runs without play services, I assume so with Microsoft behind it). Of course, an old copy of GMaps works fine, but Maps [0] is open source, which one might likely favour on a Google-less phone.
I forgot to mention that I keep Firefox just for Bitwarden extension. Though I usually just copy the password on my PC, and KDE Connect syncs the clipboard. I also try to be logged into as few services as possible on my phone, in case someone steals it while the phone is unlocked. Since the phone is rooted, determined thief would have many opportunities.
By "one tap", I meant the "Close all tabs" options next to "New incognito tab". If you tap "Close all tabs" in Chrome, you get an "Undo" button for few seconds. If you do the same in Firefox, you don't. There are "Recently closed tabs", but I learned the hard way that it only holds few tabs.
Maybe it's because I'm using Firefox on Linux, but I couldn't find a Close all tabs button or menu entry. There is even an extension for that [1]. Closing all tabs wouldn't be the same as closing the window they belong to?
microG still sends data to Google though, I believe, even though the local code is open. Without Google involved at all, Android is barely usable as a daily driver. I tried for a while.
It keeps connection to Google, but at least does not send your location and does not help Google with personalizing ads. I'm also not logged into Google account.
When all I needed of my phone was web browser + YouTube playlists + FB Messenger, lack of Play Services did not seem to be big deal.
Basically it still uses Google backends and infrastructure for push notification delivery without contributing anything to the costs of the infrastructure. It does that by spoofing the library ids and accessing the APIs with fake authorization.
I don't think that's a sustainable plan going forward.
Tangent, but can I ask what made you choose 9.69.1? I spent hours trying out a bunch of versions and ended up choosing 9.42.3 as it started up fast and was the last version that didn't have the "explore the city" nonsense taking up half the screen on startup. Curious what sweet spot you found in 9.69.1!
When I updated Maps and found out the latest version requires Play Services to start, I just went to apkmirror and grabbed random old version. Or maybe I grabbed one I had in Titanium Backup backups - I don't remember precisely.
I actually didn't know what you were talking about until I opened the app few seconds ago. I was just tapping the search bar as soon as the app started every time, and did not even notice something was appearing on my screen. But I agree, now that I looked at this panel, it does seem useless.
Oh I see. Yeah I recommend going back to that version if you don't have a particular reason to stick with the later one. Or maybe to 9.50.1 if you want the ability to add Favorites and Want To Go (as opposed to just Starred Locations). The later versions have way too much crap in them -- over fifty (!) notifications (and redundant ones at that, I'm guessing because people kept turning off the old ones) as of the latest version I tried, with the screen constantly trying to get you to look at it and tap stuff. They're trying to get your attention all the time like they're Facebook or something. They can't just show you a darn map and navigate you anymore. (Though even these versions aren't great, but they're usable.) They made the changes rather gradually though (sometimes even the same version behaves differently depending on whether you upgraded or not) so I'm guessing that's why you didn't notice.
> Chrome for browsing (as in Firefox, last time I checked, one tap separates you from losing all open tabs).
I've been using Firefox on Android for a couple of years now and have literally never had that happen, so I'm intrigued now. Are you referring to "Close All Tabs" being next to "Private Browsing" in the dropdown? I can see how that could be fat-fingered but I've always used the icon instead of the dropdown.
It does complain about them on the first launch (when the setup screen tries to sign you in for synchronization), but works perfectly after that. I was a bit surprised too. Now, my Chrome installation has been moved between 5 devices (via Titanium Backup) and still works.
The only big inconvenience is getting bookmarks to PC. There is XML file in /data/data/com.android.chrome called Bookmarks (by the way, Chrome seems to be the only Google app in com.android namespace). I just use regex to select the lines with URLs.
Galaxy S4 Black Edition (with leather back), previously Galaxy J7 16, Nextbit Robin, Galaxy S3 LTE and S3. I downgraded as I find notification LED priceless and 5' screen perfect. I'm mostly sitting on HN and Reddit, so it's okay performance-wise (though your Nexus is faster), though I keep my eyes open on new devices.
There are still new S4 batteries manufactured by Samsung for Korean market, got mine in Poland for $25. I'm getting 5h+ SOT.
I'm not a performance-demanding smartphone user, but if I were, I would consider jailbreaking an iPhone. Android & Linux (Purism, Pinephone) keep disappointing me.
EDIT: maybe "disappointing" is not the right word. It's just that for good step, a step backwards seems to be taken somewhere else. Choosing a phone is all about trade-offs now, which is kinda sad. I'm using phone manufactured 6 years ago. Why can't I find any device that is a clearly improved version of it?
Practically, it's very difficult. LineageOS people are trying to work on that, but it's just a very big hassle with the variety of OEM components running amok the industry.
You can get a close enough view on this by finding a phone supported by LineageOS and installing it without anything esle (e.g. no fdroidPriviligedExtension, no openGapps etc).
Alternatively, or maybe even better to what you ask, if you have a Pixel phone you can build RattlesnakeOS, again without adding anything like openGapps, which is almost pure AOSP iirc.
You can't get anything running with AOSP, there's not a single common phone which would run without random Android blobs & custom kernel changes. Then once you add those blobs, you need to add MicroG to have any hope to run any moderately popular app.
You won't get play store, default apps and apps from store itself. You can install f-droid, some other store or use microG as replacement for google services and apkmirror as a store, but you'll probably have some problems with compatibility.
Misleading title... Real title something like: apps that use Android push notifications without Firebase, including GPL-licensed apps, now reported as "using too much battery"
I'm not an Android dev, but according to the source in the article [1] this limitation is applied since Oreo, which is released two years ago. Why this problem arises today?
They never did. Releasing the source contributed creating the developers ecosystem we have today.
What Google fears more than the Armageddon would be someone making a truly FOSS operating system capable of running on Android devices, and they prevent that by keeping device drivers and firmware tightly locked.
This is probably still in Google's best interest, since it greatly reduces the cost for OEMs to distribute updates (and updates are one area where Android severely lags behind iOS)
This is pretty darned incorrect on a number of fronts. Skipping for the moment that a random histronic Reddit post is being considered "news"...
> "Google started leveraging its de-facto monopoly on Android distributions by forcing all apps to use its proprietary service Firebase for push notifications."
A number of logical leaps of faith need to be made before the word "force" carries any truth, but no one's "forcing" anyone to do anything. A developer can still use the FCM or not, it's up to them. If a developer simply refuses to interface with any sort of proprietary code then it's a wonder they'll touch any commercial product at all (iOS included).
..and since Telegram-FOSS were cited as a source for this mess, here's the very first part of [i]their[/i] statement, which is also not true:
> Since Android 8.0 Oreo, Google doesn't allow apps to run in the background anymore, requiring all apps which were previously keeping background connection to exclusively use its Firebase push messaging service.
Sooo very not true. Android [i]does[/i] still allow apps to run in the background. The developer docs caution against doing so without good reason because so many developers try very hard to ignore the lifecycle methods, resulting in many wasted clockcycles and reduced battery life.
But the Telegram team didn't stop there, so let's unpack the rest:
> Sadly, if the app would set the notification to lower priority (to hide it a bit in the lower part of the notification screen), you would immediately get a system notification about Telegram "using battery", which is confusing and is the reason for this not being the default. Despite Google's misleading warnings, there is no difference in battery usage between v4.6 in "true background" and v4.9+ with notification.
First, it's not a "warning". It's simply a statement. ...and yes, if you're going to maintain a separate push notification service of your own (I'm looking at [i]you[/i], Facebook.) you [i]are[/i] going to be using at least a few clockcycles. There's no way around this.
The backgrounded apps notification is also as "judgement free" as any notification can possibly get. On my phone right now, running Android 8.0... "3 apps are using battery". One of these is my own app (which happens to be a homescreen widget), another is Life360, and another is GSam Battery Monitor. Tap that notification and a list appears, headed up with "Apps running in background" with "Tap for details on battery and data usage" and lists the apps with their icons. Tap one and it shows what resources the app [i]is[/i] actually using. GSAM... 52Mb of RAM, and ~55kB of data in the last month. 0% battery used since last full charge. My app, 0% battery (probably not enough to count as a whole percent) use since last full charge, 5.84MB of internal memory, no data usage. I don't know how other people might view them, but to me these seem like vindications. None of that information is being presented in any way that that should be construed as condemning or accusatory, let alone "misleading".
If Telegram-FOSS doesn't want users throwing a fit about their resource usage, perhaps they should spend a little time grooming user expectations to be more reasonable.
The reddit user who posted this mess, on the other hand... A five-year old account that only occasionally posts anything that doesn't smell of astroturf, and this one post is nearly 80% of their karma. Seems like they've decided to make a foray into outrage-farming.
I am confused. The repo you linked to hasn't had a release since 2016, and I cannot find a reference to that library ANYWHERE else. The firebase android sdk, which is what I would guess you would use (though I don't do android, so could still be wrong) is apache. What am I missing?
Amoungst this big thread, I've not noticed any evidence for this and the original article does not back this up with anything. Is the allegation that google are using battery warnings to push people towards using firebase notifications? Has anyone any experience of this?
I think the only difference is that foreground service must show a notification that's all. Users will learn to just disable those useless notifications.
This was my first thought as well. If you can't get encrypted messaging apps to use the SMS service siphon you can at least snag notification text - and most people allow the message to be in the notification.
Apple lobbies against right to repair, and Microsoft lobbies for software patents, among other of their user-hostile actions, so they both deservedly fall under 'enemy'.
And do not pretend this '1 restriction' is the full extent of Google's user hostility - it is merely the latest straw.
Edit: You may find calling someone an 'enemy' rather extremist - after all, Google is just doing what's best for its bottom line, same as other companies, right? But when they increase their profit not just by providing a good product/service, but also by altering the market/ecosystem/legal system to leave you worse off, what else would you call them? Perhaps sociopath - but "sociopath that's trying to get you for all you're worth" isn't meaningfully distinct from "enemy".
What proprietary connectors? There was one significant one. Singular. Lightning. That's it, in the recent history of Apple. And thank God they created it: micro-USB sucks. There was a legitimate engineering need for it.
The other things you mention have all been a great service to users, in protecting their security and privacy.
Um, there has been ONE new iPhone port design. One. Lightning. Which I already mentioned. As for MagSafe, that's a strength, and there have been a grand total of TWO versions of that. Compare to the 900 trillion different PC charging sockets during that time.
On HN, the overwhelmingly common paradigm is that conflict in the tech industry is to be understood as part of a existential conflict between Apple and Google. A comment that starts "Google is evil" is all but guaranteed to come from someone with a iOS device in her pocket.
And in this case I think the point is valid: this policy is bad, both because battery management and notification policy really needs to be part of the core OS in AOSP and not a proprietary add-on and because of the licensing glitch reported here where the client library isn't GPL-compatible.
But that's just one policy. Across the fence of the war mentioned above, it's a GPL-incompatible wasteland where absolutely nothing is possible at all. If you care about free software in the abstract and want to view your war along those lines: Google is behaving badly and needs to be admonished. Apple is clearly The Enemy.
The corporation will put its best interests before anyone else's. Doing something like this where 99% of the world won't know or even care is likely in their best interests no matter how unethical its actions are. There tend to be very few true 'friends' because of it. People are normalized to this corporate dance and keep expecting less and less for more.
Absolutely correct. HN somehow is fixated on google because google was maybe very good once and now maybe they aren't so good. The entirety of the App store is GPL hostile, so much so that the vlc devs had to rewrite a lot of vlc code to relicense just to make sure it could be distributed on the app store. Was the iOS notification lib ever open source, I don't know but I guess not.
The same with Microsoft. People keep bringing up dragonfly, while conveniently forgetting that bing already works and censors in China.
Google still lets you use your own push notification service. It will just be correctly reported as using more battery. The evil thing is not providing a GPL-compatible library for connecting to that service, but I'd be surprised if that isn't remedied.
Not quite. Apps have always been held to accounting for the amount of battery and clockcycles they use. The only change here is that a notification is now required for an app to deploy a persistent service. If you request the absolute lowest priority for your notification, your app winds up in the list of apps which are "running" in the background (mainly because the stuff way down at the bottom is too easily missed). If you don't request the lowest priority notification, then your notification text says whatever you'd like it to say and your app doesn't feature in the default notification.
...and there are plenty of good reasons to explicitly register as a foreground service.
I agree with you that someone's bound to crank out a GPL-compatible lib for interfacing with FCM sooner or later.
Funny, I always get that reading HN comments, but then again, I can't really compare, I've cut down on reading reddit comments years ago, maybe it's time I follow suit for HN.
Signal has sworn by GCM the entire time they've been running on Android, it took a lot of whining from the community to get them to allow anything else.
The reason to do this is security principle: Don't Stand Out.
If Bob uses Bob's personal notification system for Signal, a passive observer can see that Bob was notified by James. If everybody uses Huge Corp notifications the passive observer can only tell that James was notifying somebody about something and that Bob was notified about something.
> Signal uses E2E encryption, so your attack vector doesn't work.
End-to-end encryption is just that. That Firebase library is running on the client phone (aka, an end), if Google put code into the library allowing it to download updates it would also be running in Signal's context which would allow it to trivially dump and exfiltrate messages, memory, etc from the Signal process.
Now, we have no reason to believe such a mechanism is used here to my knowledge, but if they really wanted to, it would defeat end-to-end encryption.
In that case, Signal can run the integration in another process. It's extra work, but it also gets around the GPL issue for the main application, so if Google doesn't solve that itself, it's easy for someone else to and share the solution with everybody.
It would also be easy to spot if Google put an updater inside the library because the requested permissions for using the library would change.
If this is your angle, then they wouldn't need you to load any library for them to be able to do this attack. They have root, so they could do the attack regardless of firebase being open source.
This is a standard on the industry. From 1999: https://www.theregister.co.uk/1999/11/05/how_ms_played_the_i...
It doesn't matter how much money Google is going to have to pay in the future as a fine for this practice. The amount of money that they will get for kicking out the competition is going to be way higher. That is a learned lesson from Microsoft (and probably others before them).