Google Play permitting alternative billing systems for users in South Korea
developers-kr.googleblog.comRemember, people: the real lock-in with Android is not the Google Play. It is the push notification services that are bundled with it.
The Android OS is intentionally crippled to work only with Google Play push notifications, and there are no 'stock' ways to use an alternative without modifying the OS. The best alternative is to do it via persistently running app, which is less reliable and bad for UX.
This notifications problem also applies to iOS: even if users will be eventually allowed to install apps bypassing the AppStore, these apps would just sit idly until opened by a user, which is unacceptable for a very wide range of communication apps.
However, there is a difference with Android: iOS was crippled from the start, but first iterations of Android were relatively open, apps could run in the background without much issues. But then Google started tightening the grip, so Android now closely resembles iOS in this regard.
> first iterations of Android were relatively open, apps could run in the background without much issues. But then Google started tightening the grip
The flip side of this is that there were a lot a badly behaving apps, sitting in the background without a user requirement that would justify that, eating battery and network. Hence nearly all Android phone manufacturers bundling some kind of background app killer.
Restricting background apps by default is probably good. But Google didn't have to lock users in to their own service to provide a good push notification system on Android.
The correct solution here would have been a system-level, open source, provider-agnostic push notification API built into AOSP. The Web Push API is a great example of how a push API can be provider-agnostic: https://developer.mozilla.org/en-US/docs/Web/API/Push_API. It makes sense that push notifications should be consolidated to one provider -- this way, your device only needs to maintain one 24/7 TCP connection to a server which it receives all notifications from all apps through, rather than having each app run its own notification service in the background, killing your data and battery life.
Google's push service works by providing an HTTP endpoint to apps that they can use on the backend to deliver notifications. The Web Push API also works this way, but the returned endpoint can be for any provider. If you use Chrome, the domain will be `google.com`, but on Firefox, it's `mozilla.org`. But each provider's endpoint uses the same standardized API, so the backend doesn't have to care what the URL is. And this isn't a security risk, because everything sent through the service is encrypted.
This could have been done for Android, but that would have given Google much less control over the platform, so they decided to do it in a monopolistic way. This is one of the many ways Google aims to maintain their monopolistic control over "open source" Android. Another example is SafetyNet hardware-backed attestation.
Projects like GrapheneOS are really interesting because they are finally providing a real secure, private, de-Googled OS option, with excellent app compatibility thanks to sandboxed Play Services (which allows you to run Play Services without giving it root access to your device [1]). But will we ever be able to fully decouple Google from Android? I'm not sure. I expect most users of custom ROMs to continue installing Play Services on top of them for a long time, if they want something as basic as push notifications to work.
By the way, while I personally have qualms with Google, I believe users should have the choice to use Google apps, if they are comfortable with the inherit privacy risks. This belief is shared by the GrapheneOS developers. [2] My problem with Android is that it was not built to function without Play Services. Community projects that enable it to do so, like microG, will always be a cat-and-mouse game with Google. I think sandboxed Play Services is the most sane approach the problem of Play dependencies the community has come up with so far, but I think if we want real change to happen, we need to target app developers. Each developer has the choice of whether to include Google or not within their app. We just need to convince them that they don't need Google.
Google owns `developer.android.com` and points developers towards using Play Services APIs wherever possible. Perhaps the community should create their own open-source alternatives to the most commonly used APIs (e.g. push notifications) and developer documentation that provides instructions on how to switch from Google (ideally making the transition as easy as possible by emulating the Google API syntax). It would probably be possible to offer an installable platform-agnostic push notification API that developers can use. Providers could be installed as separate apps. Google could be one such provider. Perhaps we could implement a Web Push compatible API, and reverse engineer Chrome's Firebase integration to implement it as an option from the get-go, hoping other providers show up over time. We could perhaps allow users to self-host their push service as well. Modify Gotify, an open source self-hosted push server [3], to accept push notifications in the Web Push format.
In the hacker circles it seems there's two groups of people: those who think Android is a lost cause because it will always be controlled by Google, and think Linux phones are the only real alternative, and those who believe we can actually "steal" Android back from Google and make it into a true open source project. I fall into the latter, but I think a lot more work still needs to be done if we want to achieve this.
[1] https://grapheneos.org/usage#sandboxed-play-services
[2] https://grapheneos.org/features#features
> We aren't against users using Google services but it doesn't belong integrated into the OS in an invasive way. GrapheneOS won't take the shortcut of simply bundling a very incomplete and poorly secured third party reimplementation of Google services into the OS. That wouldn't ever be something users could rely upon. It will also always be chasing a moving target while offering poorer security than the real thing if the focus is on simply getting things working without great care for doing it robustly and securely.
There is no need for a global push service, either. Just some type of API that batches timer wakeups and network keepalives together is enough to guarantee very high battery life, and you can still keep as many connections as the user wants. Many platforms before Google/Apple worked like this.
Push services are a bit more convenient in that they require less infrastructure both in the server-side as well as client programs (e.g. they can even be shut down and still receive messages), but nothing really prevents having an ecosystem of multiple competing push services.
There clearly is a need. It needs to be as easy as possible to switch away from Google, or developers won't do it. Additionally, an ecosystem where each developer is encouraged to go wild and implement their own notification system is not ideal. Sure, some of them will be competent enough not to deplete the user's battery within a few hours, but others will not be, and each individual app that does this contributes to battery drain in a tiny way, which adds up.
> Many platforms before Apple/Google worked like this
Mobile devices are an entirely different beast with strict battery life and data usage requirements.
Another factor to consider is that Android will kill long-running background apps unless you disable battery optimization for said apps through a convoluted process (even if you show a persistent notification). [1] It would be really inconvenient for users to have to manually disable battery optimization for every app that wants to send push notifications.
[1] https://github.com/gotify/android#disable-battery-optimizati...
I have a custom app which monitors my device 24/7 in the background with a persistent WebSocket connection to my server to receive push notifications. While yes, as a user you need to grant some permissions to the app, it works without a problem.
If by notifications you are referring to Firebase Cloud Messaging, which replaced Google Cloud Messaging and is now integrated in Google Play Services, I do agree with you.
It is my opinion that Google should be forced to decouple all these Google Play Services which are not related to the "Online App-Store" which Google Play is, and ideally be forced to open source it, so that trustworthy alternatives can be used to replace it.
I mean all the components which track you, which basically is what Google Play Services is: it is a system service created to monitor every possible activity you have with your phone (location, physical activity, health) as well as the efficient, persistent data connection to transfer these bits of information to Google (and to your device as FCM), while Google grants you access to use these services in a restricted manner.
For me Amazon's Android devices are basically useless since they don't have Google Play Services installed, and you have to work around it to get it installed, which basically is illegal to do.
> While yes, as a user you need to grant some permissions to the app, it works without a problem.
Without the problem for YOU, because, presumably, you have a non-shitty phone. It is a much more severe issue on the likes of Samsung / Xiaomi / Huawei. See https://dontkillmyapp.com
> Without the problem for YOU, because, presumably, you have a non-shitty phone. It is a much more severe issue on the likes of Samsung / Xiaomi / Huawei. See https://dontkillmyapp.com
And if you force Google to stop verifying proper behaviour in CTS, do you expect those manufacturers to allow you to run background services at will?
They already kill off anything that's not whitelisted to keep those battery numbers up. The every new major OEM release we developers find bunch of new ways the try and kill background apps.
I can back that up. Oneplus is infuriating in that they include a way for you to whitelist apps and then kill them anyway. I essentially have to plug my phone in if I want to run, say, a torrent client for more than two minutes.
So the issue is not Android (AOSP) provided by google, but OEMs ?
AOSP is not Android. What Google distributes to OEMs and its direct customers is not AOSP. It is AOSP and the different Play Services including the Play Store and the Google applications with contracts mandating that they have to be provided to customers.
If you think people talk about AOSP when they talk about Android, you are always going to miss the point of these conversations.
From the link posted above parent: https://dontkillmyapp.com
> Unfortunately, vendors (e.g. Xiaomi, Huawei, OnePlus or even Samsung…) did not seem to catch that ball and they all have their own battery savers, usually very poorly written, saving battery only superficially, with side effects.
Heck, I was following the discussion regarding the notification system and how you couldn’t really do without and thought the link was actually relevant to the discussion without checking.
My apologies to NGRhodes, the link does indeed refer to an issue with OEM and not what Google supplies. I don’t really see what it has to do with the topic we were discussing however.
The issue is the locked-in requirement to rely on the sole source of push notifications built into the system. Running your own persistent app is an ugly workaround that doesn't work more often than does.
Also, such apps are unloaded from time to time even on stock non-modified Androids.
AOSP is horribly crippled by Google, as they move more and more features towards play services. Location, push notifications, etc.
There's a good reason to not allow 3rd party background networking though. It would work in theory, but in practice every company with more than a few devs would eventually implement their own crappy version of a notification system with terrible power management. Given that even well-funded companies like Uber/Facebook have constant engineering quality issues, I definitely wouldn't want to have 20+ separate active notification connections.
This is not even hypothetical, this was literally happening before background services were heavily limited in earlier Android versions.
The only thing you really need is an easily accessible tool to explicitly view which apps are allowed to run in the background. This doesn't have to occupy valuable notification area space.
With current notched phones which are limited to 4 notifications (you get four and a dot if there are more), you can have VPN app, XMPP client, Syncthing, and a generous space for one more incoming notification.
> The only thing you really need is an easily accessible tool to explicitly view which apps are allowed to run in the background. This doesn't have to occupy valuable notification area space.
Those tools existed and they didn't help because users had no recurse against poorly behaving apps. Meanwhile Android kept being reamed by reviewers and media for poor battery life and people kept buying locked-down iPhones instead because they lasted longer.
I spent countless of hours trying to get Android devs to not do dumbass things with battery ("oh, I need updates? I''ll just poll the server every 20 minutes and ruin the users battery in hours. Easier than long polling!") and in the end the situation didn't improve until Google stepped on the devs neck and forced them to use GCM/FCM and started actively powering down radio without apps input.
Oh, so because of (some) dumb users let's punish everyone by making them subject to a monopoly lock-in. Great reasoning.
Users have very effective recurse against poorly behaving apps: uninstall. You just need to inform users that the app X does use much battery. Then it should be up to the users to decide if to allow this behaviour or uninstall this app. Maybe an explicit permission to run in the background. That's it.
Solution that you like is also very beneficial for OS vendor, how convenient.
> Oh, so because of (some) dumb users let's punish everyone by making them subject to a monopoly lock-in. Great reasoning.
In your reasoning, "most" users would be done and "most" apps would be malicious.
But in the end, it's quite simple - dealing with power use on mobile is hard and most developers don't care (same as they don't give a crap about making your web pages fast and slim). Users care about battery life above most of other features, including your freedom. They WILL got and buy a device that lasts the longer amount of time in the smallest and lightest package.
As long as these two things are true, leaving developers to run their polling code without restrictions has a massive effect on sales of both OEM devices and Android ecosystem as a whole. As such, OEMs are actively modifying Android to not allow this - see the wonderfully depressing https://dontkillmyapp.com/ - which is a significantly worse mess than you having to use a proprietary service to send a single device wakeup ping.
If users care about battery life, give them tools to analyse what's eating it, but handcuff it so they don't hurt themselves. That way users who care about freedom will have it, and users who care about battery life above all will just block the permission to run in the background.
But that doesn't align with Google's interests, so it will never happen, unless they are forced to.
You severely overestimate what the user will do. Android has these tools built-in, but they are hardly used.
It's similar to how crappy drivers causing BSODs were for a large part responsible for the "Windows is a crappy unstable mess" sentiment of the late 90's and 00's [1]. This led to Microsoft severely restricting driver manufacturers, requiring signing and WHQL etc. Less freedom but stability and perception among users has markedly improved.
[1] https://www.zdnet.com/article/why-the-blue-screen-of-death-n...
Users are perfectly capable of using battery stats and determine which apps consume too much power, and then make an informed decision. This is not some rocket science.
Every single app that uses notifications needing to run in the background is not a scalable solution..
Even correctly behaving apps will consume much more power and network with this scheme.
Imagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer?
It is not up to the OS to decide which apps the user needs running. Be it wifi scanner, vpn or some file sync process. All the user needs is a correct tool to know which app consumes what, and then there User must decide. Not some prick in google or xiaomi or samsung or whoever else.
> Imagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer?
Your macOS has an unacceptable battery life already despite having a massive 58WHr battery - about 3.5x the size of a normal phone battery. Phone users don't want to lug that size of a battery around just to get battery life that's worse than they get right now from a 15WHr one.
> Your macOS has an unacceptable battery life already
Heh, not true anymore with the new M1 lineup. I was skeptical but they are insanely efficient.
Noone will buy a mobile phone with a battery life of a M1 lineup laptop. Pixel 4 got trashed on reviews for having the double battery life of those.
In terms of screen-on-time (for comparable tasks like web browsing) they are pretty close to modern phones..
I’m not saying apps shouldn’t be allowed to run in the background. But for notifications specifically it’s an unacceptable solution. It just doesn’t scale to the number of apps the average user receives notifications from.
Nobody was saying that every app needs to run in the background to deliver you notifications. I was arguing that for some apps background functionality is essential, and such functionality is obstructed by OS vendors, who strive to tie all background work to push notifications.
Sure, I agree with you there, but background app permissions and push notifications seem like pretty separate issues.
They are totally not, because whenever you need an app do something, like, display a message sent to you, the 'official' way is to do it via push notifications. But if your user doesn't use Google Play services, you have to make the app run in the background, which is increasingly difficult in Android (and impossible in iOS).
Hypothetically, an Android vendor could build a notification service separate from Play Services and deploy it on their Android builds. Has to be a vendor (or, more broadly: "someone who controls the OS down to the kernel level") because the notification technology involves some heavy abstraction-breaking footsie between the physical link layer and the TCP stack.
But the two big challenges there are:
- odds are the first several iterations of it will suck, so they'll be competing with an already-working solution that most users have no concerns using (significant market uphill fight, with the only major value-add being "We're not Google").
- we've just traded one master for another. Ultimately, unless someone builds an open-standard at the Android distro level that includes an API to allow users to establish a notification source, the distro owner still owns the notification system (and there's no reason a priori to assume they're less evil than Google). And designing that API to be abuse-proof would be a challenge; do it wrong, and we're back to the bad old days of sub-one-day battery life on an idle phone.
It'd be a hell of a cool project for someone to take on though.
Again, in a world of spherical cows this could work, but in reality it didn't.
I was an Android dev pre-5.0 and believe me, having lived through the s*tshow that was push notifications at the time, there's no way it would've worked any other way. Google's own SDKs were garbage and as with everything else they kept releasing new incompatible rebranded versions annually. Last I checked, the Firebase console for managing push notification subscriptions was still one of the worst SPAs I've come across.
You'd expect a thriving ecosystem of dedicated push notification providers to pop up and outcompete Google, but all of the 3rd party offerings were even worse, in terms of battery life, UX, reliability and even pricing.
It's unfortunate, but no developer cares about your battery life, because no user is going to switch away from using their app solely because of crappy power usage, so Google had to do exactly what they did.
Maybe in a decade or two, with new battery technologies, there won't be a physical limitation and this situation would play out differently.
> I was an Android dev pre-5.0
I was in Android dev since pre 2.0, developing an app which need to constantly run. The situation got worse since then, not better.
A thriving ecosystem of dedicated push notifications can't pop up because you can't go to Android settings and choose another push notifications provider. You have to rely on ugly crutches to even receive a push notification, and that is why they are 'even worse'.
Can you explain how this would work, does this mean that every app needs to push all notifications to all PN servers? Like there's the Google one and a theoretical Samsung one, my app has to send all push notifications to both, right, since I don't know a priori which provider you use, and if it's a global setting all apps need to use the same one.
So you either need every app developer to maintain the list of all push providers or someone, presumably Google, to maintain the canonical list and the thing that manages sending them to all the push providers.
Oh and then there's the associated suite of privacy issues. Do you really want every push notification prouder to get even metadata about all of your push notifications?
So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.
Why on Earth wouldn't you just make it a setting on the phone and expose that to apps? Have the apps read it on startup, and save it as part of the user profile server side. It basically becomes an email address.
> So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.
They seem to do fine with email addresses. Again, I don't see why 'username@notification.provider.com' (or an alternative with auth embedded) would be absurdly hard for developers. Someone will write a 'SendPushNotification' function that parses out the domain to send it to and the auth to use and send it, just like we've done with email since forever.
Google will likely know where you're sending your notifications, but they won't manage sending them (though they could probably scrape the contents since they own the OS).
Corollary: notifications should be a public service whose only purpose would be to maintain that TCP connection and have a server as a broker, with clear control given to the user over which app can use said service and be allowed to wakeup their device.
So almost literally how iOS and Android notifications work except I guess jointly owned and operated by by Google and Apple? Because public services like this are necessarily funded and operated by the companies that have a financial interest in them existing.
Not really: you can't use the service alone, without any other software. The software is not open source. And finally, the user has no control over which apps/services can send them a notification (or really, a device wakeup) at a given moment.
Those are downsides in many situations but the existing systems match your original description perfectly, unless "public" has a special description you didn't communicate.
The current situation means I can't even use my own push notifications for company owned devices running company written software. That's just ridiculous.
You could always run a custom Android build on company devices.
Sure, and by installing that custom build, you lose support and void warranty from your device provider.
That, and even worse maintaining a custom build with changes and the infrastructure such as maintaining a OTA update server, etc. is a lot of work.
That persistent notification for application running in background is the worst. Back in the day, applications on Symbian devices could run in background without any indication. Some would argue that's a risk but then we have been using our PCs like that since forever.
Even if you want users to give indication of something running in background there are far less intrusive ways to achieve that. But if you can't come up with those ways and persistent notification is the best you could come up with then at least give the user the ability to turn it off without turning off background process?
They know the tendency of people to clear notifications as they clutter the phone and they use this small knowledge to push their own Software. At least follow same practice for Google apps but no because then that notification area would be complete mess.
> Back in the day, applications on Symbian devices could run in background without any indication.
This was absolutely terrible for battery life, though. Accidentally leave the IRC client open in the background? There goes your battery. There are non-nefarious reasons why smartphones work they way they do nowadays.
But they did it less for saving battery life and more to push their own Software. There are many things that could have been done to avoid the battery issue.
They changed API to clearly show that an app is using battery to push their own software? Who's "they" and what kind of conspiracy theories have you been reading again?
> Back in the day, applications on Symbian devices could run in background without any indication. Someone would argue that's a risk but then we have been using our PCs like that since forever.
I still think my Sony Ericson p910i the best smartphone. Multiple human interfaces (the multi directional wheel is the greatest invention to be abandoned) in particular and a near fully functional OS that could do anything my computer could do
> That persistent notification for application running in background is the worst. Back in the day, applications on Symbian devices could run in background without any indication. Some would argue that's a risk but then we have been using our PCs like that since forever.
"My Android phone just died at 1pm with empty battery, I don't know why! I'm buying an iPhone!" complaints are something noone from the Android side of the market wants to continue hearing. Even if that means that you now need to have a notfication clearly telling you your battery is being drained.
> However, there is a difference with Android: iOS was crippled from the start, but first iterations of Android were relatively open, apps could run in the background without much issues. But then Google started tightening the grip, so Android now closely resembles iOS in this regard
As far as I know, Android still allows background applications though. The only constraint is that you have to show a persistent notification (that the user can hide). IM clients like Conversations.im will attest to that.
(iOS does not -- and thus creating a real Jabber client that does not depend on push notifications is impossible)
Relevant open source project: https://unifiedpush.org
Another approach is microG, as used by CalyxOS:
And yet another approach is sandboxed Play services, as used by GrapheneOS:
"The Distributor is the application you install on your device to get notifications. It receives notifications and distributes them to the other applications."
Such solutions are what I referred to as 'the best alternative'. No, thanks, it's not even close to the real deal.
The difference being, of course, that you only need one such application running, rather than every app that needs notifications running its own service. And of course, if a stock method every does become available, it only needs an update of UnifiedPush, rather than of every app that ships its own notification service.
Captain Obvious, thank you. There problem is, such functionality should be at OS level to connect to chosen push notifications provider if Google Play services don't suit you. Not via some app that is subject to all android restrictions on persistent apps, including occasional unloading from memory.
The OS is designed in such way requires push notifications built into its core to work properly.
> Not via some app that is subject to all android restrictions on persistent apps, including occasional unloading from memory
Apps are subject to power and resource restrictions, but the user can easily lift those restrictions manually for certain apps, like UP Distributor. If the app is implemented properly, it will work just as well as Google's push service.
> The OS is designed in such way requires push notifications built into its core to work properly.
Notifications are built into the OS. A network-based push notification service is not part of the OS. It is false to say that (a particular implementation of) network-based push notifications have to be "built into the OS' core to work properly."
Of course, but it's not, so it's cool that this project exists and probably relevant to people's interests here, which is why I shared it.
While I agree with you that Google is abusing its power in the Android ecosystem to "encourage" (to put it nicely) developers to use their APIs, it is actually possible to manage this imbalance between what Google wants and what we, as users, want.
Specifically with regards to notifications the main things I care about are instant messaging apps (WhatsApp, Telegram, Signal and Element) and email notifications. All of these apps fall back to either their own implementation of a persistent connection or use the OS' APIs for background job scheduling and polling. In my experience, having a handful of persistent background connections does not significantly impact battery life (<5%/charge). Also, modern Android has Doze[1] mode. Unless an app is granted a battery optimization exception, its scheduled tasks (polling) will run within a brief period every N minutes, where N depends on how long the device has been inactive. This is what I want in most cases. I personally only give IM apps a battery optimization exception. Notifications from other apps are usually less urgent/important.
However if you want the convenience of having a single connection for all your notification delivery, GrapheneOS[2] (an AOSP-based OS with many security and privacy improvements) has a compatibility layer for Google Play services[3] that allows it to be run with non-system privileges (i.e. the same as every app the user installs). That means you can choose exactly which permissions are granted to it. For example, you can revoke all permissions except Network[4]. This lets you use Google's FCM service without Google knowing anything about you except your IP address (and the contents of your notifications).
Using Google as the notifications middleman is an ugly crutch though[5], but this setup is solid. This is only necessary because they have convinced Android developers to use their APIs, but alternatives can and do exist. I think UnifiedPush[6] is going in the right direction, but they haven't gained much traction yet.
[1] https://source.android.com/devices/tech/power/platform_mgmt
[3] https://grapheneos.org/usage#sandboxed-play-services
[4] https://grapheneos.org/features (ctrl-f Network permission toggle)
[5] similar to using Apple as the notifications middleman, although the incentives are slightly different
> The Android OS is intentionally crippled to work only with Google Play push notifications, and there are no 'stock' ways to use an alternative without modifying the OS.
So modify the OS… it’s open.
Modify the OS, install it on your phone, hope that if you have an issue you still have support from the vendor or the carrier...
If it were that easy as an overall solution, non-OEM Android forks would be mainstream. They're not. I hardly know any people using non-OEM Android.
And distribute the modified OS to all your customers how exactly? You could probably sell your own android based phone as long as you find a single manufacturer that isn't part of Googles OpenHandset alliance or bound by the Play Store license to only sell Google approved Android. Alternatively you could limit yourself to India and China where Google cannot enforce these terms. There really isn't any point in pretending that Android is an open OS in the west. It is Googles proprietary stack or nothing.
This post is from Nov 4. (The dateline is written in Korean.)
The big surprise here is/was that Google intends to charge a "service fee" to developers who use an alternative billing system.
> We recognize, however, that developers will incur costs to support their billing system, so when a user selects alternative billing, we will reduce the developer’s service fee by 4%. For example, for the vast majority of developers who pay 15% for transactions through Google Play's billing system, their service fee for transactions through the alternate billing system would be 11%.
I was hoping that at some point in the weeks to follow, they'd clarify how this is supposed to work. Presumably Google will require me to send them a report of how much money I'd made?
And then I guess I'd write Google a check for 11% of my earnings…?? Quarterly? Monthly? What happens if I miss a payment?
> Presumably Google will require me to send them a report of how much money I'd made?
This isn't particularly uncommon for revenue based licensing agreements. For example, Epic requires you to file a quarterly report once you commercially release a product based on the Unreal Engine. (https://www.unrealengine.com/en-US/release)
Presumably Google will require me to send them a report of how much money I'd made?
And then I guess I'd write Google a check for 11% of my earnings…?? Quarterly? Monthly? What happens if I miss a payment?
There has to be some sort of callback into the app on successful payment so that the purchased functionality can be unlocked. Seems like Google would be able to inspect the combination of the app purchase metadata and the callback activity to come up with their vig. Just my guess though.
I'm guessing, based on the screenshot, that you'll only be able to use a third party payment system if you use a special API that will let Google know of every transaction.
I'm also guessing that this means that third party payment processors will have to register to be available on this new API.
Am I reading this correctly?
> We recognize, however, that developers will incur costs to support their billing system, so when a user selects alternative billing, we will reduce the developer’s service fee by 4%. For example, for the vast majority of developers who pay 15% for transactions through Google Play's billing system, their service fee for transactions through the alternate billing system would be 11%.
You have to pay a 11% fee for using someone else's billing system when buying an in-app purchase, if that app was downloaded from the Play store?
Everyone keeps repeating this assumed idea that it's "just" a payment processing fee which is simply not true and never has been.
The fee is for: - access to install base and customer relationship - funds development of the platform, SDK, and tools - funds development of the store - funds operation of the store - profit for the company - last and least: payment processing
Could those things be funded differently? Yes... but it would require a radical restructuring of the way mobile platforms work that would not be favorable to startups or independents. It would also lead to massive fracturing of the customer relationship, lower trust, and ultimately shrink the total dollars spent on software (though the big players would make more money). People trust Apple or Google with their credit card. They know the platform requires all subscriptions show up in one place and they don't need to call and argue with a sales rep to cancel. Be prepared for all of that to disappear when it becomes a free-for-all. Stop pretending this kind of "freedom" is completely free of consequences even for those who don't take advantage of that "freedom".
Each time someone use the straw man argument that they have costs to cover and that they still need to do a profit, just go back looking at facts:
<<Google Play Had a Profit of $8.5 Billion in 2019 With Margins of 62 Percent. According to court filings unsealed>>
https://www.thurrott.com/mobile/android/254978/google-play-h...
So, no, with indecent margins like that, you can't justify them using their monopoly to racket app developers with fees that are unrelated to the usage of the service.
Imagine if everyone was doing the same in real life, that would look absurd:
- your power utility provider requiring that you pay to them 10% of your business income because you use electricity somehow and they have costs and need to do profit
- the postal service requiring you to pay 15% of the bills you send by email through their online service or 10% of the bills you send by any other provider just because you benefit from receiving standard letters in your home mailbox. Just because they have costs and they need to do fat profits.
- Ikea forcing you to give them 11% on your business incomes because you use a desk and a chair that you bought there in your office. For the same reasons...
No, no, you're wrong! The free market will solve this!
You know that high margins are someone else's opportunity? Surely someone else will build an alternative that undercuts Android.
Ah, you say there's a huge moat? Worth billions if not trillions of dollars? Huge market recognition? Agreements with huge companies? Regulations and government approvals all over the world? Years and years of development by thousands of developers?
On top of that there's an oligopoly in place by companies already convicted of such agreements for other issues (see the anti-poaching agreement from a decade back)? What? Like a cartel that probably fixes prices?
> - Ikea forcing you to give them 11% on your business incomes because you use a desk and a chair that you bought there in your office. For the same reasons...
They very well can make these stipulations and expect you to pay them. They have every right to go "uh we need 100% of your business profit if you want to buy IKEA furniture". You have every right not to do that due to the unreasonable payment terms. You'll need to ask your lawmakers to fix this if you think it's unjust and you're being forced against your will to oblige.
> access to install base and customer relationship
This is the rent seeking that everybody is objecting to.
> funds development of the platform, SDK, and tools
The platform is open source. So if you want to use someone else's tools then you shouldn't have to pay this part, right?
> funds development of the store - funds operation of the store
The cost of providing this is negligible. Many alternative stores and repositories do it for free. It accounts for zero percent of the cost of anything.
> profit for the company
Profit isn't a separate thing. The cost of payment processing already includes the profit of the payment processor etc.
> last and least: payment processing
Which is the only thing left, so if you're using someone else as payment processor...
It's the "access to install base and customer relationship" that they're really sticking it to you for, and that's the illegitimate one.
(I work at Google, but not at all on Android)
> The platform is open source. So if you want to use someone else's tools then you shouldn't have to pay this part, right?
The platform here includes "android", so yes if you aren't using Android you probably don't need to pay to support Android development. It's not clear here, but do you think "open source" somehow means "doesn't require funding to develop"?
> The cost of providing this is negligible. Many alternative stores and repositories do it for free.
Few/none of those provide app review and various anti-malware stuff. You can argue that these have negative value, but they absolutely have non-negligible costs.
Also I don't think any alternative stores support canarying/progressive rollouts of new versions, which is useful for developers and a nontrivial to support for other stores.
>Also I don't think any alternative stores support canarying/progressive rollouts of new versions, which is useful for developers and a nontrivial to support for other stores.
You have a career in comedy if you think that the Play Store's definition of canary rollouts is good. Hell, the entire Play Console is probably one of the most hated piece of software by android devs because of how terrible it is, with constant changes, horrible performance, stupid requirements and non-working options.
Android is supported by others as well - it is not effort of Google only...
Yes, it is true, that there are other stores - like Samsung has it's own store on Android, so technically there is a choice of stores. Apparently Google would not fight store wars with the producers of hardware... but there is nothing that prevents them to disable any other stores by any other means - by simply sabotaging their app.
The issue here with Google Play is that it assumes, that Google Play has monopoly of money transactions for that publisher outside of Play store, even if the app has a choice to receive money through oher means - crypto, Paypal or cards. Same issue is with Apple store - they did not wanted to allow to transact money in Epic store(and wanted their cut on those), where you could make transactions in the Epic website from your card.
> The platform is open source.
Android is Open Source, Google Play & Google Play Services are not. Developers are free to build Android apps that don't use anything related to Google Play.
And, as far as I can tell, Google is the one making most features and patches to AOSP. Just because it's OSS doesn't mean it is operating independently, running only on donations.
Still, Google's costs of running Play Store are proportional to number of installs and maybe number of updates, not to amount of money users spend.
Google could charge accordingly without any "radical restructuring".
I don't see anyone sticking with android if they had to pay $1/mo, though.
>>> Everyone keeps repeating this assumed idea that it's "just" a payment processing fee which is simply not true and never has been.
When you are buying a phone, you also pay price that includes price for OS of the phone, that includes development costs of SDK and development tools. Some of the phones nowadays has a choice to BUY and install different OS, that comes with different stores.
Unlike your assumption, payment processing is completelly different ecosystem and Apple is simply using monopoly on iPhones and not letting other stores on their hardware and software. Alphabet does not produce phones... so IMO it is acting worse, that it makes up these stupid tales. This is one of the reasons why I am switching my phone from Android, because that is MY phone, that I paid for! Besides, Android still snoops your data without your consent and I'm not even paid for that data!
Besides, the only concern about payment processing that YOU should have is not development costs(they can't be that HUGE...), but if your payment processing is safe and protected!!! That is the only costs, that stores should have - to ensure protection of those many many transactions, where maintenance and development costs are miniscule and to be even considered is laughable topic.
When you are buying a phone, you also pay price that includes price for OS of the phone, that includes development costs of SDK and development tools.
With the race to the bottom on cheap Android phones, it's obvious that "profit from the device only" is insanely low.
> Some of the phones nowadays has a choice to BUY and install different OS, that comes with different stores.
Just pointing out that this seemingly directly contradicts your line before it. If some phones can install a different OS and come with a different store, why should the phone profit margin go towards developing the SDK and development tools?
The article actually enumerates what else the fee is used for. In Google’s words its:
""" Android & the Google Play Store: The free Android operating system enables hardware manufacturers to build a wide range of devices at different price points that gives users unprecedented choice. And the Google Play Store delivers the world's largest selection of apps and games, available in over 190 countries with personalized recommendations and easy discovery of high-quality apps.
New Android platforms: We build platforms for new form factors such as Auto and TV to help developers increase their reach in new ways.
Security: Consumers trust Android and Google Play because of its security, the reviews of apps to ensure they comply with policies around safety and privacy, and with automated security of Google Play Protect that scans over 100 billion apps per day.
App distribution: Developers can instantly reach over three billion Android users with the ability to optimize delivery by device and functionality and provide ongoing updates.
Developer tools: Developers can run experiments, beta test, optimize store listings, analyze performance, and more. """
It's actually worse, it's 26% for the larger businesses subject to the 30% rate which make up 99% of Google's revenue, when using their own billing system. It's a farce and Google knows it. (Similarly bull----, Apple claims their existing practices already comply with South Korea's new laws... which they definitely do not.)
The penalty for noncompliance is so low because the money is so huge, and nobody will go to jail, that they are going to pull every stunt in the book until someone has the guts to start shutting these companies down. By claiming they are complying technically, while obviously not, they force the government to follow up the legislation with a regulatory action, which then they can tie up in the courts for years.
If they complied with the law properly now, other countries would quickly follow suit. But if they can tie up the attempt for a number of years, they can all pad out their retirement funds before all the litigation is over and duck out before the stocks crash.
OK, let's imagine South Korea "shuts Google and Apple down" (kicks them out of the country, I guess, and then bans anybody from importing their products). Now what? Seems like they just don't have smart phones and torched a pretty productive part of their economy (i.e., producing Android phones), and it's not clear where independent app developers are supposed to be developing their stuff anymore.
Or this could force phone companies to create alternative, more open forks of the supposedly Open Source Android.
It's not like we don't know how to do this stuff, we just don't invest enough in it.
South Korean company tried to do just that - they built an OS called "Tizen" which withered and died because without user-facing software, it was a horrible user experience and people were seriously annoyed that they couldn't use the software they actually care about. Instead, they went and bought Google/Apple devices instead.
Another USA company tried to do that as well. They called their OS "Windows Phone" and it withered and died because a fractured support for software people care about doesn't make a useful device.
A Chinese company tried to do that as well. They now again ship Google Services next to their own Huawei services in Europe because without software support, their smart devices weren't useful to users either.
Where are you getting your information? Tizen OS is not dead. It is well alive and kicking and being improved and Samsung is slowly implementing that unified OS not only for their phones, but for other Samsung products. The main issue for any phone producer is that any OS that they do not own also Android comes at a price - there is no such thing as free OS.
There are also plenty of other mobile phone OS, that are not compatible with every phone and that is the main issue why they are not widespread. Phone that I own is supported not only by Android(and Android forks), but also couple of other mobile phone OS. The trend is that in future there will be more choices for OS, that might satisfy those users, that are currently not happy about Android, but have no other choices at the moment.
There are at least 10 other mobile OS choices - most of them are based on Linux, but current share of those is ~0,1% out of ~6 billion of phones. In total numbers that is only 6 million devices. 6 million device market is a significant number for any company, not to mention, that this number is only playground compared to 1000x larger world market of mobile phones.
"without software support, their smart devices weren't useful to users either."
Therefore, logically, Apple should be the one paying app developers 30% of their revenue. Witout them iPhone would be an overpriced paperweight.
The relationship is symbiotic. iPhones need your apps to stay relevant, and developers need access to the iPhone ecosystem to be able to reach anybody.
Sure, but Apple has the power, and money follows power.
Apple pays developers 70% of their revenue. Thats where the developer revenue comes from.
Unless developers get money from iPhone sales, this statemet has tenuous relationship with reality
You're almost there, but you didn't go all the way.
South Korea is a small market. The US company is famous for mismanaging its mobile operating systems for more than 2 decades.
The Chinese company didn't "try" to do that, it was forced to. But guess what, in China, where most external apps are banned, there's an entire, completely separate ecosystem.
You do need a combination of skill and critical mass. I don't expect South Korea to achieve this, but for example if there's a bigger alliance of say, South Korea, the EU, etc., where they put resources into encouraging an OS based on open standards, that starts to look feasible.
App developers will need support, but they can port their apps. Especially since this OS doesn't need to start from scratch, it can be based on AOSP.
That's probably the biggest thing Google/Apple are afraid of this point, that a fully open/interoperable mobile OS is somehow enforced. They either have to open up their OSes to be in key markets or they're forced to let someone else create that OS.
South Korea has its own Galapagos Island situation with apps thanks to efforts to foster them by the government — eg Google Maps is seriously crippled and you have to use Kakao Maps, they have their own local version of Uber, etc, etc
If it were so easy Chinese companies would have already done it, having both more resources and an obvious incentive.
They have done it. Do you know how the Chinese smartphone app market works?
As far as I'm aware almost everything is still Android, even if they're not using the Play Store.
Yeah, but Android is Open Source by design.
All these governments don't have an issue with the code, they have issues with project governance.
But they haven't gotten their own fork off the ground so they're still dependent on Google for continued updates.
Yeah, but with enough of these "nudges", maybe it finally happens.
The EU has already fined Google, South Korea is adding these new rules, I think even the US is thinking about some regulation, let's see what happens in a few years.
Ultimately, my guess is that the military/China conflict angle prevails over antitrust when it comes to Google. But I could be wrong. Certainly China has cracked down on its side, which I didn't anticipate.
Samsung and Tizen OS(that comes with store) is already an alternative for South Korea. Though, so far Samsung has profited from cooperating with Android, as it gained unprecedented share for smartphone market.
iPhone has branded itself as status symbol that people are rich and can pay and maintain lifestyle that includes ipHone - Androids, well - it is replacable and will be eventually.
At the very least, if Samsung is compelled to exclusively make Tizen phones, I think they can pretty much kiss foreign sales good-bye. Though I guess they're in better shape than LG trying to license the OS from their chief competitor.
"Now what? Seems like they just don't have smart phones and torched a pretty productive part of their economy"
So you are saying Google / Apple are above the law, capitalism is more important than democracy?
Where does this end? They might as well start acting as mafia, resort to raketeering and break you legs if you don't show up for work.
No, I’m not saying that. I’m saying there is a reason we have a regulatory regime with all the safeguards you’re decrying instead of randomly axing companies.
You reasons seems to be that Apple and Google are holding us hostage.
Is there any other reason i missed?
Sure, in the same sense the power plant "holds us hostage" so we don't respond to malfeasance by not having electricity anymore.
I have not found an English translation of the South Korean regulations - do you know what clause(s) Apple does not comply with?
That's because the law was stupid and apparently everybody who cheered for it missed a business 101 class. Why do people expect google or apple to roll over and die when faced with half assed laws ? They way SK or any country can meaningfully change the balance is by attacking the source of the problem. Google prohibits vendors from bundling other stores, which is the first issue. Second, robust privacy laws should prohibit google from being privy to any transaction data between the user and a vendor. So google doesn't get to intercept what the payment amount should be. Third, even if alternative stores are allowed, they still won't be popular. So for that, the government can heavily tax play store etc. to level the playing field with alternate local stores.
>Google prohibits vendors from bundling other stores,
they do? then why does my phone have a uninstallable 'galaxy store' app that Samsung decide to fill my limited storage with.
That's because google and samsung need each other. So samsung gets a pass. They don't allow other manufacturers.
Huawei ships with their own app store on devices with Play Services as well. There's no restrictions for other manufacturers.
What other manufacturers can't do is fragment the ecosystem and prevent people from also using Play Store.
The epic lawsuit has quite a few details about google preventing manufacturers from installing epic software/epic store on devices.
This still is a walled garden. Store from os or manufacturer. If you try to install a third-party you may end up with poor user experience from the os.
Time to split app distribution from OS. Making it mandatory to allow other stores, with first class user experience, and not set their as default one.
I installed the amazon app store on my android phone and it worked fine same with installing FDroid. all i had to do was check a box when prompted.
Sure but it's only you, already knowing about alternative stores, and with your specific device.
Step four, Korea now has a totally balkanized app system different from the entire rest of the world, it's a headache to deal with, and it encourages dangerous user behavior. Well, I guess they've been down this road with SEED/ActiveX already.
I love how this makes them admit that an average payment processing fee is only 4% (Less in the US actually, not sure about SK)
This has been part of Apple's argument all along. The 30% was never for payment processing but for the overall "ecosystem".
> The 30% was never for payment processing but for the overall "ecosystem".
Yup, ecosystem: https://en.wikipedia.org/wiki/Braeburn_Capital
For those that don't understand what that is, Apple's products, especially the App Store, have insane profit margins. Apple's profits are so high that they don't know what to do with the money so they started their own investment fund.
> In October 2012, CNET reported that Braeburn had US$117.2 billion under management, making it "the world's biggest hedge fund."
That was in 2012. Since then they've almost tripled the amount of Apple money that they manage.
Minor nitpick. Wikipedia, CNET and Zero Hedge are wrong about Braeburn Capital being the largest hedge fund. A hedge fund employs "alternative" investment strategies to traditional investment funds. If we loosen the definition to include Braeburn Capital, then it would also cover BlackRock, which has almost $10 trillion in AUM.
Well, I'd say that your comment probably provides the biggest bang for the buck, educationally, if you edit the Wikipedia page :-)
> Apple's profits are so high that they don't know what to do with the money so they started their own investment fund.
So we should expect companies to only profit to a point of net-zero? Or can you call out a percentage of revenue that is acceptable?
It's not about profits per se, it's about market distortion.
Just as people who are too rich distort democracy.
Right, the fee isn't the using Google's payment system, the fee is for using Play Store. Or rather, 11% of it the 15% is.
If that is the case then why is the fee taken as a percentage of payments made within the app as opposed to number of downloads, or just a straight up monthly or annual fee?
From a conceptual level, it makes sense to monetize a platform based only on the people making money. Like how game engines are generally free to use for games that make little or not money.
On the more practical side, it's kinda hard to make yours work. You probably don't want to charge a popular free app like Wikipedia the same as an app like Netflix.
I don't see how any developer nor consumer would benefit from "pay your monthly play store fee to access the store". Imagine if credit cards also worked this way.
This year the EU overhauled VAT regulations for purchases from outside the EU.
First of all it is now possible to make tax declarations yourself without going through a customs agent. Previously if you bought something like a dashcam from AliExpress you'd need to pay VAT and a "processing fee" to the agent (i.e. the post office) which in total would come to around the same price as you paid the seller. It's still somewhat complicated to do yourself, but the post office here introduced their own electronic declaration system. If you choose to use their system it's €3, but if you choose to do it yourself you need to pay a "parcel handling fee" of €3.
Additionally the regulations require sellers sending goods to the EU to charge VAT at the time of purchase. So everything you buy from AliExpress now is sold with VAT (but prices are still shown without). The post office also introduced a €1 handling fee for these parcels - that they don't need to do anything with other than deliver them.
"Sure, you can use an alternate billing system. But here's all the reasons we're great. Oh, your billing system wants more than 4% just like we did/do? Well shoot... Guess you're stuck with us, huh?"
What billing systems want more than 4%? Credit card transactions usually cost less than 2%.
Microtransactions are typically higher.
https://www.paypal.com/us/webapps/mpp/merchant-fees#statemen...
In the US, PayPal is a 4.99% + fixed (US: $0.09).
"Less than 2%" plus an additional constant-ish fee, sure. The typical cost of a CC transaction is significantly more than 2% at small amounts (like many in-app purchases).
What’s the credit card processing fee in Korea? I believe it’s generally around 3% worldwide.
In the EU it's capped at 0.3%.
That's only a part of the fee, in the end it's about 1%
When I was in college and threw parties I used to justify keeping all the money by saying it was for "the house". Not one of the people involved (bartender, bouncer, etc) got penny and I consistently made lots of money
Google now says the fee is for the "ecosystem". They are taking people for fools and hiding the real story: they are a monopoly and they only do this because they are forced by the people of South Korea
@dang @mods
Present title: Google Play permitting alternative billing systems for users in South Korea
The title is editorialised and reads like this is something Google is doing of their own volition, whereas they’re merely complying with (new) law.
Time for open source alternatives to Google Play services to appear? So developers can use other stores or no store at all?
There is F-Droid that people can try and it has many nice open source applications.
It's pretty straightforward on Android phones to install an alternate app store; you just have to enable sideloading.
It is anything but straightforward (unless you're the type of nerd who browses hacker news).
If you sell an app on an alternative store, how do you get the average person to install it? Adjust your marketing materials to teach them how to find the hidden "allow unknown sources" toggle on their phone, and then say something like: "Just ignore the many scary warning messages telling you that you're about to get a virus, and implying that we're malicious. Also, don't let it scan us for malware, not because we're malware, but because Play Protect may end up accidentally blocking us, and we have no idea how to get that reversed".
And even if you do that and manage to get enough customers to qualify as a potential competitive threat, Google will put together a task force[1] to destroy you.
1: https://www.androidcentral.com/google-fortnite-task-force
> If you sell an app on an alternative store, how do you get the average person to install it?
Usually a button next to the "Google Play Store" and "Apple App Store" buttons?
If the developer feels they have to support some store's users themselves with installation and troubleshooting, they should just get their own app side loaded and maintain a direct relationship.
I wouldn't expect Microsoft to give me directions to a Best Buy to pick up Office 365.
I think you misunderstood my comment.
> they should just get their own app side loaded and maintain a direct relationship.
How do you get the average person to sideload an app? Whether it's a store or a single app, Google Play will always have an unfair advantage.
You'd go to the manufacturer and convince them to bundle your app store I guess.
Epic tried to do that, but Google made secret deals with OEMs offering them a cut of play store revenue if they don’t (https://www.theverge.com/2021/8/19/22632806/google-epic-prem...)
Part of the deal was that they couldn’t tell anyone about it without Google’s permission. So when you get a rejection from an OEM after you offer to bundle your store, you don’t get an explanation.
Or maybe time for non-Android, non-iOS operating systems on mobile: see Librem 5 and Pinephone.
Good. I'm sure their billing and payments scam won't see light in many other countries as well. Devs in India have "until March 31, 2022 to comply"? LOL, let's see how that turns out. It'll be amusing to see another instance of Google getting shown their place by responsible competition regulators, especially in one of their most valuable markets.
Curious how this will get resolved when a service like Netflix uses their own billing system and is forced to pay 26% access fee to Google and 30% to Apple.
Will Netflix have to raise their subscription rate by 120% or more?
I'm sure Google and Apple would be in tears if all those users would migrate to their streaming services.
Netflix just raised their subscription fees a lot recently, on an unrelated note :-))
I remember the cynical Reddit comments warning of Google leaving the Korean market before allowing for third party payments.
If I had a penny for every time someone was threatening to leave a market and forgo millions of customers, I would be threatening to leave a market myself!
The fee is quite big, I do think that they should reduce it a little bit.