I refuse to Play. I don't really miss the app store, but I'm sore I can't cast media at my friend's house (Chromecast requires Google Play, of course). This is another brick in that wall.
This is more unethical and monopolistic than anything Micro$oft ever did, back when they earned that moniker.
It could've been an app. Or more than one. And then there could've been competition. Instead it's baked into a monster install that does who-knows-what when it invisibly updates itself.
I'm inclined to think this is an all or nothing here, but since we don't have access to the source, I won't know how Google has implemented Play Services.
Can you kindly give an example of which APIs shouldn't be tied to Play though? I've never thought about it.
They are an open source re implementation of play store APIs that work with play store apps, without all the bloated tracking and spy... sorry "telemetry", and without giving Google remote root on your phone, with the ability to selectively install and do whatever the hell they want to your device silently (sounds like a targeted intelligence operation dream to me).
Removing gapps stuff and using microg instead saved a large amount of ram, and more than doubled my battery life.
Its a great way to make old devices suck less.
No implementation of this API yet, but it seems rather trivial to do, and will likely see implementation.
On the one hand, the people who can reverse engineer stuff got too good: either they got tired of it, or they're getting paid big bucks to do it professionally. On the other, (perhaps this is jaded) new programmers are just learning scripting/web technologies and never peel back the covers of how the system actually works.
Perhaps reverse engineering proprietary products should be a mandatory tour of duty for young programmers, like military service in some countries. :)
Google play store APIs and protocols ARE being reverse engineered and re implemented.
I run microG with store apps with no issues with everything I have tried.
Doing it to a chat-app has an obvious benefit: you can use your own application with your custom UX, and connect it with multiple networks at once, or multiple accounts at the same time on the same network.
Doing it with something like Airdrop is kind of a nebulous proposal. If you want to share files with someone next to you, and for some reason you hate Airdrop, then there's lots of other alternatives. Reverse engineering Airdrop gets you nothing special.
"Note: The Nearby Connections API does not require the user to authenticate, which means that it can be used even when the user does not want to sign in or sign-in has failed."
"Warning: Messages sent through the Nearby Connections API are not encrypted. Do not send sensitive data through this API."[1]
The blog post links to this documentation page:
Game API (C++):
void SendReliableMessage(
std::vector< std::string > const & remote_endpoint_ids,
std::vector< uint8_t > const & payload
)
Nearby API (Java): public abstract void sendReliableMessage
(GoogleApiClient apiClient,
List<String> remoteEndpointIds,
byte[] payload)
Note that this requires a "GoogleApiClient" object, which ties it to the mothership.
Of course, Google had to lock up peer to peer communication by tying it to their online store. It's also unencrypted and unauthenticated, so you don't want to use this for home control.