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?
Android now forces apps to include proprietary code for push notifications
261–270 of 284 posts
Re: Android now forces apps to include proprietary code for push notifications
#262Amoungst 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?
Re: Android now forces apps to include proprietary code for push notifications
#263Earlier quoted context omitted.
That's what I thought when I bought my Sony phone. Except when you unlock it you run a crippled version of the phone. 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 inte…
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
No, the app can continue to use third party push notifications if the OS allows it to.
Re: Android now forces apps to include proprietary code for push notifications
#264Earlier quoted context omitted.
> 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 an…
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…
Who exactly is buying Android phones based on the premise of openness vs "they're cheaper", "it was a subsidized new phone from my carrier"?
Re: Android now forces apps to include proprietary code for push notifications
#265I 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...
Nope! firebase-messaging is missing from this open source version.
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.
Re: Android now forces apps to include proprietary code for push notifications
#266Earlier quoted context omitted.
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…
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 w…
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!
Re: Android now forces apps to include proprietary code for push notifications
#267Earlier quoted context omitted.
Is the solution to begin, to a degree, treating adults as children?
To answer the question shortly: Yes 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…
>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.
Re: Android now forces apps to include proprietary code for push notifications
#268Earlier quoted context omitted.
That method just instructs the OS to send keepalive packets on a system thread. 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...
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.
Re: Android now forces apps to include proprietary code for push notifications
#269Earlier quoted context omitted.
They don’t- it’s the FSF restricting developers freedom. Not Apple.
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. This is an Apple problem, not FSF.
End user freedoms but not freedoms for the person who actually creates the code.
Re: Android now forces apps to include proprietary code for push notifications
#270Earlier quoted context omitted.
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 w…
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 ho…
> 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.