What is beacons in android

Android Beacon Library

An Android library providing APIs to interact with Beacons

The leading library for detecting beacons on Android.

What Does This Library Do?

It allows Android devices to use beacons much like iOS devices do. An app can request to get notifications when one or more beacons appear or disappear. An app can also request to get a ranging update from one or more beacons at a frequency of approximately 1Hz. It also allows Android devices to send beacon transmissions, even in the background.

What kinds of beacons does it detect?

The library can easily be configured to detect iBeacon, Eddystone and other beacon formats. By default, it detects beacons meeting the open AltBeacon standard See the documentation for the BeaconParser class for more info.

JCenter Sunset

Library version 2.18+ are available on Maven Central. Please update your build scripts as shown in the quick start

Android 10 and 11 Support

Library versions 2.16+ fully supports Android 4.3-11.x. Android 10 and 11 have a new location permission models that requires beacon apps to make changes to target SDK version 29+ and then again to target 30+. See the request permission page for more info.

Existing apps that use library version 2.12 older versions must upgrade in order to detect in the background on Android 8+ devices. Read more information here.

Who uses this library?

Over 16,000 mobile applications use the Android Beacon Library, including some of the world’s biggest brands. These apps have over 350 million installations.

What devices can detect beacons?

Any device with Android 4.3+ and a Bluetooth Low Energy chipset can detect beacons with this library. As of September 2019, this is approximately 97 percent of Android devices according to the Google Play Store.

To transmit as a beacon, Android 5+ and firmware supporting Bluetooth Low Energy Peripheral Mode are required.

Eddystone Support

The library provides full support for the Eddystone™, format from Google. The library will wake up your app when it detects Eddystone-compatible beacons in the background and provides regular ranging updates while they are in the vicinity. Eddystone-UID (identifier frame), Eddystone-TLM (telemetry frame) and Eddystone-URL (URL frame) are all detected and decoded. Details are here. Eddystone-EID Support is described here. While Google’s web services for Eddystone were deprecated in 2021, this library will continue to support this beacon format indefinitely.

Источник

How to Build an Android iBeacon [Updated] 1/3

Free up to 1MM monthly messages. No credit card required.

Here’s the deal — Retailers are always looking for the next great way to generate sales. Beacons are one technology that have taken the spotlight. Even years after their launch, Beacons are still featured in the news, mostly under the name “iBeacon” – Apple’s protocol using Beacon technologies.

The reason for iBeacon being so prominent is mostly thanks to Apple. They’ve been using beacons on iPhones since the 4S! They were also the first company to come out with Beacon protocols, but we’ll get into that later.

There are very few devices that have the hardware to act as beacons. Under the Android 5.0 testing version, the Nexus 5 was able to act as a beacon. However, because the chip would not allow multiple simultaneous beacon emissions, the final release of Android Lollipop prevents the Nexus 5 from using this technology! Android 10.0 was just released and has a new location permission model that requires beacon apps to make changes to target SDK version 29+. Newer versions of Android require that you request location permission from the user at runtime in order to detect beacons.This is very new to Android phones, so expect the Beacon phenomenon to get bigger in the near future!

Types of Beacons & Their Differences

iBeacon was created by Apple and was the first beacon protocol introduced. It’s pretty easy to use, and it is very widely supported.

Eddystone is Google’s answer to Apple’s iBeacon. Previously named UriBeacon, it is very flexible and, since it’s created by Google, works very well with all Google products and devices.

Designed by Radius Networks, it doesn’t favor one vendor over another. It is open-source, which provides for customizable source code.

This open-source beacon protocol was created by Tecno-World. It features 8 types of user data, and is open-source, so it’s pretty flexible with various mobile platforms.

But First — API Keys

The first thing you’ll need to do before getting started is to signup for a PubNub account. We’ve got a more than generous free sandbox tier for development! You’ll need the API keys at the beginning of this tutorial.

Android iBeacon Project Overview

In this tutorial, we dissect the signal emitted by beacons and then use this knowledge to show you how you can use the brand new Android BLE package. This blog post is our series overview to get you started, and after that, check out our in-depth tutorials on building an Android beacon emitter (publisher), and Android beacon detector (listener).

This tutorial is part of our more-extensive series on building smarter beacons, and you can check out the beacon series overview here. We’ll show you how to start a two-way communication with a beacon. Which is great because the original Beacons can only advertise information!

By the way, we’ve already published our tutorials for iOS iBeacon and Tessel beacon. So if those are more your cup of tea, check them out!

What a Beacon’s Advertisement Looks Like

According to the Bluetooth core specification, a beacon advertises a data package called the Scan Response Data.

This Data can be up to 31 bytes. If we create a smaller scan response, the remaining bytes will be filled with as many 0s.

The scan response is divided into what are called AD structures. They are sequences of bytes of various size, with a predefined structure that goes as follows:

• The first byte represents the number of bytes left to the end of the AD structure. This allows a receiver of this structure to know when it ends and when a new AD structure starts.
• The second byte is the ID of an AD structure type.
• The rest of the bytes are data structured in a predefined way, depending on what AD type the previous type defined.

That’s all there is to it — just a succession of AD structures.

Most beacon protocols, if not all, have only 2 AD structures which are as follows.

First AD Structure

The first structure has 3 bytes:

• The first byte: 0x02 because we only count the following bytes.
• The second byte: 0x01 which indicates we have a «Flag» AD type.
• The last byte represents these flags. These flags express whether the emitting device is, in “Limited Discoverable Mode”, “General Discoverable Mode”, etc… The byte computes the following way:

The 5 flags are represented by the first 5 bits of a byte. The value of these bits defines whether the flag is ON or OFF. The binary number is then written as a hexadecimal value which will be advertised. An example may clear things up:

The resulting binary value hence becomes: b00011010 . Converted into a hex we get: 0x1A

That’s it for the first AD structure! Now Let’s look into the second one, which contains most of the information we need.

Second AD Structure

The second structure can be of different sizes according to the protocol. We will take the example of AltBeacon, which is nearly identical to others.

• First byte is 0x1B (27 in hexadecimal) which means we are taking all of the last available byte of our 31-byte scan response. This can vary according to protocols.
• The next byte is always 0xFF which means we have a «Manufacturer Specific» type of AD structure.
• As a result, the 2 following bytes represent the company identifier as defined on bluetooth.org. For our Nexus 9 device, the manufacturer of the bluetooth chip isn’t very clear so we’ll simplify this by using Google’s manufacturer ID which is 224. In hexadecimal value, this is equal to 0x00E0. The ID, written as little endian takes up the 2 bytes. Here it will be 0x0E0 0x00 in this order.
• The rest is Manufacturer-specific data! This is what changes the most between protocols.

For the AltBeacon protocol, the 2 first bytes of the manufacturer-specific data are 0xBE 0xAC and identify altbeacon ADs. I personally really like that they decided to use the first 4 letters of beacon! Easy to remember. The next 16 bytes are a UUID representing the advertiser’s organizational unit, and the 4 next bytes can be subdivided anyway you want. We are going to divide them into 2. We’ll have 2 bytes long numbers, similar to the major and minor in iBeacon. The following byte must be set according to your hardware, and the last byte can be left at 0, you can also decide to give it any meaning you want.

The byte, which depends on the hardware, represents the intensity of the signal at a meter away from your device. It is the two’s complement of the value in dB. The value of the intensity depends on a lot of factors, it often isn’t very precise. For my Nexus 9, -75dB seems like a correct estimation. This means the two’s complement will be -75 + 256 = 181 , so in hexadecimal value our byte becomes 0xB5 .

Computing The Distance To A Beacon

One of the great strengths of beacon protocols is that they give you an approximate value of the distance that separates you from the emitting device.

This is achieved by comparing the reference RSSI, which is transmitted with the beacon scan response to the RSSI your phone detects. The algorithm to compute this value is often property of the beacon protocol owners (Estimote or iBeacon). However, because AltBeacon is an open-source project, we will use their algorithm, available here and here.

We are going to use this algorithm in our example code to compute the distance. Note that regardless of the protocol you use, the computed value on the distance is not reliable and can’t be used to detect the exact location of the user. There’s more info on the limitations of beacons in Apple’s doc.

Using the Android BLE package for Beacons

To use Bluetooth on Android device, you will first need to add permissions to your Android Manifest:

The whole concept of the package is based around the Bluetooth Adapter which allows you to have access to your hardware. For example in your onCreate method:

That’s all you need to get started. Let’s look into more specific cases of emitting of scanning beacons. One thing you need to know when using the Android BLE package is that the first AD structure is automatically read or created. We will only need to work on the second AD structure. Moreover, the SDK automatically recognizes or creates manufacturer-specific data structures, so we will not need to edit or use the 2 first bytes defining the size and the data type. The 2 bytes representing the company ID is also edited automatically; you only need the decimal value of the ID. This will make our life a little easier.

Scanning Beacons on Android

The first thing you need to do is to instantiate a Bluetooth LE scanner:

The android package allows users to create filters, so we can choose to detect beacons that correspond to our filter.

To detect an altBeacon, you will first have to build a scan filter. You will need to create an array, of bytes, of size 24. The first 2 bytes will be the altbeacon identifier prefix: 0xBE 0xAC . You will also insert the 16 bytes for the UUID of the beacons you want to detect. Commonly this is the UUID of your organization. You can leave zeros in the remaining bytes.

Build another array, of size 24, that contains one from index 0 to 17 and the remaining ones with zeros. This will indicate that only the first 18 bytes are mandatory and that the scanner should show us results for scan records that match the beginning of our Manufacturer data only.

Turn your Android into an Emitting (publisher) Beacon

Similarly, the first thing you need to do is instantiate a Bluetooth LE Advertiser:

To Build your data, you will use the advertise data builder. Similarly, create an array of bytes containing the AltBeacon prefix, your UUID, major, minor, and tx power. Once this is done you’ve completed the beacon!

Sum it Up

We’ve gone over the signal emitted by beacons, computing distances to beacons, and how to scan beacons on Android devices. You should have all the info you need now to create a new Android BLE package.

Источник

Setting Up Beacons in Android: No Beacon Manager App Required

An introduction to beacons

Beacons are Bluetooth-transmitters that send some information or advertising data that can be accepted by the smartphones and tablets within the range of the transmitter. For example, a smart bus stop can transmit route schedules, a shop can send discounts info, a museum can air the timetable of exhibitions, and so on. A message transmitted as a notification can contain a link to some web page.
The starting point of the Beacons movement is considered to the development of iBeacons by Apple, announced in 2013. Beacons are the devices supporting the Bluetooth Low Energy technology. Their task is simple – serially send data packages (advertisement packets).
This packet consists of the following parts:

• The 3-component beacon ID:
  • UUID – 16 byte. For example your company ID, retail store ID, etc.
  • Major – 2 byte. The city ID where your company/store is located.
  • Minor – 2 byte. The GPS coordinates of a specific venue.
• TX Power – 1 byte. This is a paragon of the signal strength. The paragon is the signal strength at the distance of 1 meter from the beacon. Measures in dBm.

The iBeacon solution was only fit for iOS. Android had to use third-party libraries (like Android beacon library).

What is Eddystone?

In July of 2015, Google announced Eddystone- an open format for Bluetooth beacons. This technology is also compatible with iOS, as the packets format is similar to the iBeacon one. Eddystone can cast 4 types of packets:

• Eddystone-UID. This is the same identifier, an analog of iBeacon (UUID, Major, Minor). Eddystone-UID consists of the two parts:
  • Namespace ID (10 byte)
  • Instance ID (96 byte)
• Eddystone-EID pseudo-randomly changes its 8-byte AES-encrypted identifier with a developer-set average life period every few minutes. As for the rest, it acts similarly to the UID frame.
• Eddystone-TLM telemetry accesses such data as battery capacity, battery charge level, gadget temperature, and the number of packets sent.
• Eddystone-URL transmits the URL to a website protected by means of SSL. This beacon is the base of the Physical Web technology. URL limit is 10 byte.

For the complex operations using beacons, Google developed a number of independent solutions under the unified Google’s Beacon Platform. It includes the Eddystone format, the Beacon Dashboard monitoring and management system, and the APIs for beacons interaction (like Google Proximity Beacon API , Nearby Messages API , and Places API).

Nearby Messages API is the API for Android and iOS that scans devices, collects data from the Google Cloud, Beacon information, and the attached data.
Google Proximity Beacon API is the API for beacon management and administration. Briefly, there is a Google cloud where all the beacons are registered by their identifiers. You can use a special Proximity Beacon API or a Beacon Tools app for this. *
With the help of Google Beacon Platform you can only register beacons with support of Eddystone. After that you can bind data to the beacon, the so-called Attachments. With Beacon Dashboard you can not only register beacons, but also easily monitor and manage attachments via a usable interface. After this, you can interact with other beacons on the devices using Nearby Messages API and Places API. Places API is the UI, allowing binding Place ID metadata to the beacons.

Nearby

Nearby is the technology of network data exchange. This tool delivers content for users based on their location. Through this technology you can implement notifications connected to the place or a person. An important aspect is the interaction with the other devices. The API-UI of Nearby Connections API allows an app to easily discover other devices of the local network, connect, and exchange messages in realtime. Nearby is available starting from the Android version 4.4 (KitKat).

Physical Web

Physical Web is the ability to translate a regular URL from a beacon to the mobile devices with the help of Bluetooth Low Energy (BLE) technology. The Eddystone-URL packet is sent from a beacon and received by the devices with Bluetooth on. For example, there is a beacon in a store, sending notifications with links through bluetooth. Users within the reach of the beacon can access this notification and follow the link to the store website to see the entire catalog.
Physical Web is like a QR-code, only a QR-code is passive and has to be found first, then you have to open an app with a camera, zoom in, get the URL and follow the link. In Physical Web, it’s enough to be within the reach of the beacon with the device bluetooth on.

Registering Beacons

First, enter the Google console for developers, activate Nearby Messages API and Google Proximity Beacon API. Also, create an API key for the app working with Nearby Messages API. As a limitation for the key, select Application for Android. After that, enter the packet application name and the checksum of the SHA-1 certificate for OAuth 2.0 client ID . Then, with the help of the Proximity Beacon API or Android/iOS Beacons Tools app, fill in the following fields:

• Advertised ID (mandatory)
• Status – active/inactive / obsolete
• Stability – stable/rarely portable expresses the expected consistency of distribution.
• Latitude and longitude – a pair of variables in degrees. Has to be compatible with the representation WGS84 if not specified. The values have to be within the normalized scope.
• Indoor floor level – human readable line indicating the floor where the beacon is located.
• Google Places API Place ID
• Text description
• Arbitrary properties as key/value pairs

The advertised ID must be a correct Eddystone-UID identifier of the beacon (16 byte with 10 byte of namespace ID and 6 byte of instance ID). The ID value has to be base64 implementation of data.
Beacons are presented as the beacon source and can be registered by means of the beacons.register source. A beacon can be registered simultaneously in a only one project at a time on Google Developers Console. An attempt to register a beacon the second time might lead to an error. As soon as the beacon is registered, its AdvertisedID field cannot be edited.
A setup example with the help of Google Proximity Beacon API :

Response:
If the action has been successful, it’s indicated by the code 200 OK response status. The body of the response contains a beacon’s JSON representation with the beacon.beaconName value that can be used as a link for beacon management.
After the beacon is registered it can’t be deleted from Google Beacons Registry. There are two ways to take the beacon into an offline mode:

• Invoke beacons.deactivate to temporarily delete the beacon from a project. After deactivation, the API will not be returning neither the bound data, nor the information about the beacon. In order to turn the beacon back into the working mode, invoke beacons.activate .
• Invoke beacons.decommission to permanently deactivate beacon ID from the project. You can’t use the ID that has been associated with it before. But you can easily assign a new ID to the beacon and re-register the beacon with a new ID.

Attachments

The generic data, called Attachments can be bound to the beacons. Attachments are blobs stored in Google’s scalable cloud. Currently, Attachments are only available for the project they were created in, with no availability for other projects.
To create an Attachment, fill in two fields:

• namespacedType is the line consisting of the identifier of namespace, slash, and data type. For example, surreptitious-banjo-145/string .
• Data – base64 representation of data type, defined in the namespacedType field. For example, aGVsbG8gd29ybGQh

In order to figure out which namespaces are associated to which projects, you can invoke namespace.list .
Attachments can up to 1024 byte long. You can use any string that matters for your application, for example, a bus stop ID, store location, structured data like JSON, or a link to an external database.
You can manage beacons in Google Beacons Dashboard. The main dashboard window looks like this:

You can also change the beacon configuration and add attachments here.

Nearby Messages API

Nearby Messages API is the API that allows different devices to publish and subscribe to messages, thus exchange data. Nearby Messages API is the part of Nearby . For message exchange, the devices must not be on the same network, but must be connected to the internet. In this case, the smartphone or tablet that is to receive messages must be connected to the internet. The beacons don’t require internet connection. Nearby Messages API allows message exchange through Bluetooth, bluetooth Low Energy, Wi-Fi, and even ultrasound, but Bluetooth Low Energy allows to minimize energy consumption.
Nearby Messages API is available on Android devices in the Google Play services library version 7.8.0 and newer.
Setting up the project:
In the build.gradle , add play-services-nearby as a dependency:

In the AndroidManifest.xml manifest, specify API_KEY, stored in the Google console storage, in Credentials:

In the application, create GoogleApiClient and add Nearby Messages API:

In order to receive messages from the beacons, first subscribe to them, in either of the two following ways:

• If the application is active, as a response to the user action or event.
• In the background, i.e. when the application is inactive.

For parsing, use MessageListener:

Active mode subscription

When the app subscribes to the beacons’ messages in the active mode. Scanning is performed continuously until the app unsubscribes. Such a subscription is recommended to be used only when the application is active, usually as a response to some user actions.

Background subscription

Subscription in the background is initiated by the Intent service:

The Intent service itself:

If the subscription is no longer necessary, unsubscribe by invoking
Nearby.Messages.unsubscribe(GoogleApiClient, PendingIntent).

Emulating Beacons

If for some reason there is no beacons available at hand, there is a way to utilize a third-party beacon emulators.

• Node-eddystone-beacon . A cross-platform project . It can distribute 3 types of packets:
  • Eddystone-UID
  • Eddystone-URL
  • Eddystone-TLM

It works on top of the NodeJS . The emulator device, for example a laptop must support Bluetooth v4 (Bluetooth Low Energy).

Let’s check Eddystone-UID. In Google Beacons Dashboard, add notification to the beacon. This notification will be distributed from the beacon to all the users within the reach of its signal with their bluetooth on and active internet connection. Say, the title is “Search the world’s information” and as the URL, let’s set https://google.com .

The device in the beacon zone had active internet connection and bluetooth on. The notification is:

Let’s check Eddystone-URL. For this: in the beacons settings, I provided the https://github.com/ URL. After this, a notification with github link appears:

Beacon Tools apps:
For Android.
For iOS.
Selected sources:
https://developers.google.com/beacons/
https://www.youtube.com/watch?v=3nYyApSiSLQ
https://codelabs.developers.google.com/codelabs/hello-beacons/#0
https://habrahabr.ru/post/278443/
https://habrahabr.ru/post/279381/
https://habrahabr.ru/post/279379/
https://habrahabr.ru/article/302978/
https://habrahabr.ru/post/274585/
http://droidtune.com/15238/google-nearby-servis-vzaimodejstviya-s-okruzhayushhim-mirom.html
https://nvworld.ru/news/google-releasing-nearby/
https://habrahabr.ru/post/256071/

Источник