Today we're announcing the availability of this API across all Android devices running Google Play services 11.0 and up.
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.
Play services is more than just the online store; it's a Faustian bargain of useful services in exchange for giving Google root control over "your" computer.
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.
Well, tough. As an app developer, I don't bother with users who don't use Play. I prefer worrying about Play versions instead of Android versions. There are a lot of useful features which we would otherwise wait for new OS releases to be able to use.
The vast majority of which have no reason to be tied to Play, they're just (ab)using Play to auto-install and auto-update it everywhere. An effective way around carrier update delays, to be sure, but far from the only option.
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.
That's fair criticism, but "we" are likely to complain that "Google is installing many apps, and I don't know what they're doing". What also happens when I install "Core" v11.0.4, and then "Cast" doesn't install? Or the user stumbles upon "PubSub", and removes updates?
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.
It used to be that these kinds of protocols would be reversed and reimplemented pretty quickly. See Pidgin (GAIM) and countless other instant messengers. I wonder what's happened - I see a lot less reverse engineering going on these days.
Having done a fair share of reverse engineering in my time, I think the reason is that it's boring. Sure, at first it's fun: it's all about constantly solving new puzzles. But eventually you realize you're in a maze of twisty passages, all different. The challenges are artificial and meaningless and will continue forever as long as pointless incompatibility is incentivized.
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. :)
Did people used to widely reverse engineer protocols that weren't related to communications and chat?
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]
Just because the Nearby Connections API layer is neither authenticated nor encrypted, doesn't mean the developer isn't free to implement it. If I tell you an Ethernet cable requires neither authentication nor encryption, you aren't going to tell me it's impossible to authenticate or encrypt over Ethernet.
This is one of those features that really needs cross platform support. If Apple and Google could just work together and let MultipeerConnectivity and Nearby Connections work together maybe developers would actually develop interesting applications for peer to peer.
It's presumably built around WiFi Aware, which is cross platform, but the WiFi "Alliance" (owners) won't tell you what it is or how it works or how you can make use of it.
So this is what we get.
100% agreed though. IMO is poison and a major regression from where things stood- barely working wifi p2p- since it doesn't make any interoperability affordances/offerings.
WiFi Aware is an OS-level feature that's being added in the upcoming Android O release. It also requires new hardware support, which means most phones don't support it yet.
Nearby isn't using WiFi Aware. We want it to work on all existing Android devices.
Internally, it's using a mix of WiFi, WiFi Direct, Bluetooth LE & Classic Bluetooth.
Getting proximity-based P2P messaging to work correctly across all devices is complicated. With Nearby Connections, we're trying to provide an abstraction layer that makes it easy.
Seconded. What could be their interest in not making this technology interoperable? I'd there are already some killer applications for only one platform it could be user lock in. Otherwise it's to keep developers from using it, which is strange.
Definitely! It's amazing that two people can have smartphones with wifi, bluetooth and other comms links yet there isn't a standard, platform agnostic way to send a file to another phone.
So now we have Nearby Communications for Android and AirDrop for iOS and we still can't send stuff to friends in the same room, without sending the data through a remote third party service. The only standard supported mechanism for sharing without an app is via email!
I would love to go full Watch_Dogs on those shelves. They'll probably have those e-ink price tags that are now popular; it would be cool to make them display "IT'S A TRAP" instead.
> Imagine walking into a hotel room and having the temperature set just right, your favorite sub-genre of progressive-math-rock playing in the background, and the TV urging you to continue binging on your saved guilty-pleasures watchlist.
I really can't help but cringe. Please let that never be my future, where I broadcast out personal information to the entire room everywhere I go.
I am genuinely curious in wondering what proportion of the open standards in technology begin as innovative evolutions of existing standards with only limited support at introduction, like this is. Isn't this essentially one of the accepted pathways to open standards, build the system, invite collaborators, and see if it gains acceptance and traction?
I can see this as a way to configure IoT devices more easily. For example, setting up a new printer is often a hassle; using a tiny, barely workable, touch screen and an inefficient menu system is no fun. Imagine you could just plug it in and your smartphone comes to life with a nice GUI. It could even pre-configure it for you. Another example is Amazon's Alexa devices. Currently, you have to push buttons and install a custom app on your phone and it can be very confusing.
The classroom examples also ring true to real world experiences. My wife is a teacher and has used several different proprietary "voting" devices in the past to great effect. However, they all used different hardware/protocols and didn't integrate with their current environment at all. This year they are moving to Chromebooks and my hope is that Nearby Connections might provide an "open" foundation on which a new breed of apps can be built.
It's amazing how much things have changed since AirDrop. In the last two offices in which I've worked (both creative), AirDrop was indispensable. Even in a small team of 20 or so people, it was used hundreds of times a day.
The new Apple era has strayed considerably from "it just works," except for AirDrop, which has been nothing but a pleasure to work with.
I don't have any Apple hardware so I don't know what AirDrop is. I should google it but my point should be already easy to see. If it's not interoperable it can't become as useful as it could be. Compare it with HTTP, SMTP, FTP etc which are open standards with multiple interoperable implementations.
Can you describe the workflow of using AirDrop? Because for some reason AirDrop never really clicked for me. It is far too many layers or options before i get it across devices.
And I assume you are all using Mac?
Because In Cooperate World it is pretty much Windows Only.
In Corporate World of the 1990's it was pretty much Windows Only. Much of the corporate world has moved on, largely spurred by managers adopting iPhones.
The last two companies I worked for — a creative agency with ~50 people, and a larger more anonymous company with ~2,000 employees in 10 states — both were 100% Mac. The first one, because that's how creative agencies have always been. The second for security. The IT dept's policy was no Microsoft hardware or software allowed other than Office: Mac.
As for the workflow, it's like this:
- See file on desktop.
- Right-click and select "Airdrop"
- Choose destination computer
- Notification appears on target computer stating that someone wants to send a file
- Destination user clicks "Accept"
- File transmits super-duper fast in the background and lands in the destination computer's download folder
Or if you're sending a file to yourself (both devices have the same iCloud/.mac/.me ID) skip everything after the third step.
No need to wait, the recently announced Broadcom wifi vuln discussed here[1] can be used to spread to nearby devices (see the section titled "The First Wifi Worm" near the end).
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.