Hacker News Reader

Comment by hyperionplays | Hacker News Reader

now more devs need to start releasing APK's of their apps directly on their websites.

While this is certainly a welcome option, third party app stores like F-Droid work just fine. The main repository contains only free software compiled by the F-Droid team, but other user-addable repositories can contain anything.

Additionally it is already possible to download APKs as they are hosted on Google Play from sites like apkmirror.com and you can even install the Play Store if you have microG and are so inclined.

There's no lack of app distribution :-)

We also need an alternative to Google Push notifications.

I think it would be cool to implement a similar system on top of the Web Push API. This overs e2e encrypted push with existing clients. We would just need to define the Java client API.

There is https://bubu1.eu/openpush/ but I am not sure what the current status is.

I've seen it but it seems to be mostly idle. And they are defining a new server-to-server API instead of using Web Push which seems like unnecessary duplicated work and requires new server-side client libraries and server implementations. Furthermore they don't support e2e encryption yet.

Aren't web push notifications ineffective (especially battery-wise) compared to google's?

No. Web Push Notifications are basically a protocol. They define three main things 1. A JavaScript API for retrieving a notification endpoint and configuration 2. A JavaScript API for receiving notifications 3. An HTTP API for sending notifications.

Notably absent is a method for connecting that HTTP API to the JavaScript receiver. This is independent of the Web Push protocol and how it is implemented will affect the performance. For example Chrome on Android will use Google's regular push infrastructure (or at least a wrapper around it) and will have the same performance. You could implement this part via polling but the performance will be terrible.

So to make a replacement for Google's push system on Android you would need to rewrite 1 and 2 (possibly just translating the JavaScript browser API to Java) and you would need a push server implementation as well as a client to run on the phone. This client is where you take care. But as long as you run one client per device it should perform similarly to Google's solution. The main problem would be if every app ran their own client, but that isn't what is expected. The phone should provide the push server information to the app (which hands it over to the server) so that all apps on the device use the same server.

Sure, you are still implementing a lot, but the thing is that websites and services already have ways to store these push endpoints in the DB as well as encrypting the messages and sending them. It would be a lot less work to get them to do a little client-side work so that they app uses the same codepath as their webapp than making changes to their whole stack to support a new protocol.

Thanks for detailed explanation. It's much clearer to me now.

That's a bannable offense according to Google's policies

Could you cite that, please? Signal provides both a Google Play install and an APK directly downloadable from its website. And of course loads of apps are on both Google Play and F-Droid. So, I’m assuming that Google’s policies forbid providing directly download of APKs that are inextricably based on Google Play Services, but it would be nice to see the actual text.

Mostly from personal experience, also saw a few similar cases on Reddit. The banned app had a link to the app's website which, in turn, had a link to xda forum where the very same apk was hosted. Here is the rule quoted in the suspension email:

"Apps or third party code (e.g., SDKs) that download executable code, such as dex files or native code, from a source other than Google Play."

If someone thinks it's an overreach, read about cases when apps were banned due to a link to another Google Play app from the same developer [1]

[1] https://www.reddit.com/r/androiddev/comments/atsju7/linking_...

Yes, so this is apparently banning linking to third-party sources of executable code from within apps, not simply making an APK available from multiple sources.

Sure, if you frame it like this. But it's not what a developer would think of when linking to online tutorials from within the app

Is that why Signal's apk is so hard to find on their site? So they don't get banned for linking their site in the app?

Signal’s APK is hard to find because the developers really don’t want people using it. They believe that it is best for security if all users get the app from the same place with automatic signed updates, i.e. the Google Play Store. The direct-download APK is only grudgingly provided because they know that some signal users are using Android versions without the Play Store.

In fact there are many apps that are available in Google Play and externally (as APKs, and via other app stores).

I don’t think so. WhatsApp does that and it is a pretty known app.

Reply on news.ycombinator.com