Google is rolling a new set of features and services to help developers build apps using beacon technology. This includes a new open format for Bluetooth low energy (BLE) beacons to communicate with devices, a way for developers to add this data to apps and to Google services, as well as a way to manage a fleet of beacons efficiently.
Google calls this new and open frame format for BLE beacons Eddystone. According to Google, Eddystone offers a robust and extensible platform which supports multiple frame types for different use cases, and supports versioning to make introducing new functionality easier.
Eddystone offers a protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages. It describes several different frame types that may be used individually or in combinations to create beacons that can be used for a variety of applications. It’s cross-platform, capable of supporting Android, iOS or any platform that supports BLE beacons. And it’s available on GitHub under the open-source Apache v2.0 license.
The design of Eddystone by Google has been driven by several key goals:
- Works well with Android and iOS Bluetooth developer APIs
- Straightforward implementation on a wide range of existing BLE devices
- Flexible architecture permitting development of new frame types
- Fully compliant with the Bluetooth Core Specification
To enhance privacy and security, Eddystone offers a built in a feature called Ephemeral Identifiers (EIDs) which change frequently, and allow only authorized clients to decode them.
Eddystone offers two key developer benefits: 1) better semantic context and 2) precise location. To support these, Google is launching two new APIs including the Nearby API for Android and iOS which makes it easier for apps to find and communicate with nearby devices and beacons to provide better context.
The Proximity Beacon API lets developers associate semantic location – such as place associated with a latitude/longitude - and related data with beacons, stored in the cloud. This API will also be used in existing location APIs, such as the next version of the Places API.
Eddystone’s extensible frame formats allow hardware manufacturers to support multiple mobile platforms and application scenarios with a single piece of hardware. An existing BLE beacon can be made Eddystone compliant with a simple firmware update. Google will be soon be introducing an Eddystone certification process that will be created working with beacon hardware manufacturers. Google already has a number of partners that have built Eddystone-compliant beacons.
To help to manage a fleet of beacons, the Eddystone’s telemetry frame (Eddystone-TLM), in combination with the Proximity Beacon API’s diagnostic endpoint, can help beacon deployers monitor their beacons’ battery health and displacement - common logistical challenges with low-cost beacon hardware launched at scale.
Google has also starting to improve its own products and services with beacons. Google Maps launched beacon-based transit notifications in Portland earlier this year, to help people get faster access to real-time transit schedules for specific stations. And soon, Google Now will also be able to use this contextual information to help prioritize the most relevant cards, like showing menu items when a user is inside a restaurant.
And, when a mobile app is not available, the Physical Web project will be using Eddystone beacons that broadcast URLs to help people interact with their surroundings.
Google has a variety of tools and code samples to assist beacon developers and implementors in working with Eddystone devices. These include:
- An Android app that performs non-exhaustive basic validation of all the Eddystone frame types.
- An Android app that can broadcast configurable Eddystone-UID frames.
- A validation tool for the dedicated Eddystone-URL configuration service.