Android now forces apps to include proprietary code for push notifications
reddit.com
reddit.com
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).
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.
What exactly do you expect Google to do here?
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.
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"
Huawei recently stopped allowing bootloader unlocks.
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.
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?
This was not mentioned at any time during the purchase and they would not take my phone back.
Buying unlocked phones from the start can be an expensive downside, but being free from contracts and carrier bullshit can be a huge upside.
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.
You don't have to be a kernel hacker to build & flash AOSP. Google has a guide on it: https://source.android.com/setup/build/running
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.
A bit of a tangent but I'm a "power user" and still can't get rid of the stupid warning in the beginning. Definitely not a happy medium.
Where does Apple say that GPL code isn’t allowed on the App Store? I ask entirely out of my selfish need to avoid unpleasant surprises later on.
https://forums.developer.apple.com/thread/18922
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.
E.g. Git is on GPL version 2 still (and probably forever), and Apple continues to update that in a relatively timely fashion.
See for example https://apple.stackexchange.com/questions/6109/is-it-possibl... .
This is an Apple problem, not FSF.
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.
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.
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).
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, ...)
https://www.statista.com/statistics/266572/market-share-held...
This may be an ideal solution for you but its really not for most people.
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.
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.
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.
But yeah, if you want to avoid Google's servers, then it's not enough. But in that case, you're probably on Google-free LineageOS anyway right?
But yes, I agree, Android's competition is iOS and that's freaking sad.
1. According to the reddit post the firebase library makes no difference to battery life
2. It is perfectly possible to provide strong guarantees around battery usage and resource consumption with open source code
Unfortunately, the choices today are limited.
Let app developers and users have a choice.
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.
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.
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.
(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.)
If that is so, then this is obviously a killer and quite seemingly arbitrary requirement. Your MS example is quite good.
And, it should be noted, the LGPL license, which exists for exactly this purpose!
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 distribute firebase blobs under the gpl. Ergo, you have used a gpl library to make something not gpl.
Which is illegal.
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.
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?
What you can't do is write code which depends on GPL, then distribute it with those GPL components and insist the resulting package is not GPL.
In fact, it's not so much 'dependent than derivative. GPL is a copyright license, and copyright restrictions can only only flow to derivative works.
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.
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.
Maybe erring on the side of safety here makes sense?
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.
BTW, as others have pointed out, there are open source Firebase libraries (https://firebaseopensource.com/projects/firebase/firebase-an...)
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.)
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.
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.
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.
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.)
> 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.
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.
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.
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.
Thank you for the detailed info about how those modes work though -- it certainly de-mystifies the network problems!
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.
>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.
(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.
https://developers.google.com/web/updates/2016/07/web-push-i...
Thanks for the link, but IDK. I don't see FCM in that collection. What am I misunderstanding here?
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?
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".
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.
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.
(And yes, Android batches up process wakeups as well. See the docs on "Doze Mode": https://developer.android.com/training/monitoring-device-sta...)
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.
You are wrong. Cell networks don't prevent you from keeping a socket open for however long you want. For how to keep your sockets alive, see https://developer.android.com/reference/android/net/SocketKe...
It saves some CPU power by letting your process sleep, but still requires waking the cell radio up periodically.
The implementation can be found here: https://github.com/aosp-mirror/platform_frameworks_base/blob...
Especially in the EU where no favorable treatment is the default (so net neutrality) - as far as I know.
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.
EDIT: After reading the original post it is clear they are indeed not comparing against FCM. They are just comparing two different methods of running in the background. See: https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/mas...
And presumably the user has no way to install alternate notification services?
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.
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?
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).
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.
Or even just copying bits of GPL-licensed code in themselves.
Any examples for those who would like to learn more about this?
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 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.
The FSF does not consider GPLv2 to be Apache 2.0 compatible, telegram-FOSS is GPLv2, and Android/AOSP is Apache v2.
Additionally, their own codebase contains a bunch of Apache v2 licensed stuff, like exoplayer2, recyclerview, libtgvoip, fastdateparser, ABSL, etc.
They do not appear to be even giving attribution as required (or at least i can't find it)
They are in no worse a position than they were yesterday:
>ag -Ri apache
will produce tons of matches like this one:
TMessagesProj/jni/libtgvoip/webrtc_dsp/absl/strings/internal/m emutil.cc
3:// Licensed under the Apache License, Version 2.0 (the "License");
7:// http://www.apache.org/licenses/LICENSE-2.0See https://github.com/overtake/TelegramSwift/issues/163. I don’t know too much about Signal other than the fact that it exists, so I can’t judge it in comparison to Telegram.
> 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.
This is why I think IP laws make no sense, arbitrary restrictions are arbitrary and stupid.
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.
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.
I, uh, would really hope this "attitude" is standardized. GPL code should have the same meaning everywhere.
IMO, if this is an accepted practice on Linux—one of the largest GPL projects—that should be enough short of a court decision.
Edit: seems I was reading correctly: https://github.com/firebase/firebase-android-sdk/issues/125#...
firebase-messaging is missing from this open source version.
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.
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.
We'd be at a place no different from any other "FOSS" App on android today.
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:
https://github.com/firebase/firebase-ios-sdk/tree/master/Fir...
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.)
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.
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.
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.
Curious, what companies use that same phrase you are comparing it to?
Or if that isn't what you meant, where is Apple and Microsoft on the Good vs Evil dichotomy?
As an experiment, I'd love to compile it, put it on a spare phone and use it as my daily driver for a week.
Overall I liked the experience, battery life (especially with greenify) was amazing.
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.
[0]: https://f-droid.org/en/packages/com.github.axet.maps/ [1]: https://play.google.com/store/apps/details?id=com.here.app.m...
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.
[1] https://addons.mozilla.org/en-US/firefox/addon/close-all-tab...
Don't use the menu -- it feels like the less obvious option anyway. Use the mask icon to switch to private tabs and open one from there.
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.
I don't think that's a sustainable plan going forward.
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.
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.
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.
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?
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.
Without Google Services, a bare bone AOSP has more or less the same capabilities of some cheap low-end Chinese tablet that cannot run Google Apps.
[1]: https://github.com/Telegram-FOSS-Team/Telegram-FOSS/blob/mas...
Look up Project Treble.
Not anymore. Having basic android open source help when everything is pushed into the proprietary play store
> "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.
The library’s license says that it cannot be used by AGPL software?
Because if not, the FOSS authors can just make builds for Android with it.
Apple has created priopritary connectors, closed off systems, paid barriers to entry, and banning apps from their store.
Where is Apple and Microsoft on the scale from Friend to 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".
The other things you mention have all been a great service to users, in protecting their security and privacy.
Just that Google is not.
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.
Since things are not black and white, it should be reasonable to differentiate between Apple, Google, and Microsoft.
The same with Microsoft. People keep bringing up dragonfly, while conveniently forgetting that bing already works and censors in China.
...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.
If Signal has to implement it, I assume the FBI will ask Google for the ability to insert itself in the proprietary code in some updates from day 2.
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.
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.
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.