Introducing Ambient Web for iOS

By Scott Newman

This week, we released a new application called Ambient Web for iOS to help you find and visualize nearby Physical Web places.

Open the app when you are in range of any Physical Web-enabled place or thing and you will see a card with its URL. Tapping the card will bring the web page to full-screen where you can interact with it like any normal web page.

Ambient Web discovers Physical Web-enabled places or things immediately around you and organizes their related web pages in an easy to browse collection so you can immediately dive in and start exploring your physical space.

Screen Shot 2018-11-20 at 11.58.46 AM.png

About the Physical Web

Physical Web-enabled places or things contain special Bluetooth beacons—tiny radios that broadcast the unique web addresses for useful web pages and web services related to them.

More and more places—like transit bus stops, concert venues, sports bars and college campuses—are becoming Physical Web-enabled, giving you useful information about these venues, right at your fingertips.

Likewise, more and more things—like parking meters, vending machines, museum exhibits, and movie posters—are becoming Physical Web-enabled, giving you a much more interactive and personalized interaction with these objects.

For more information on the Physical Web project, visit the Physical Web Project page.

Create Your Own Physical Web Places

Beacons from Radius Networks support the Physical Web - you can even order one pre-configured with a URL of your choice.

Our beacons can simultanously support iBeacon™, AltBeacon™ and Eddystone™ technology, allowing you to reach your customers in multiple ways.


We’d love to know how you are using the application or how you think it could be even better. Please let us know!

App Store Link

Keeping Teen Drivers Safe with RoadPoints

Using beacons to promote safety of teen drivers by verifying driver identity and blocking mobile phone usage while driving.

Radius Networks has teamed up to with RoadPoints to extend their innovative solutions by providing a means for verifying driver identity and blocking mobile phone usage while driving.

RoadPoints provides an app that allows parents to monitor their teenage drivers and reward them for driving safely. It measures speed and speeding, braking and acceleration, and phone usage while driving. Based on these factors, the child receives a report card with an overall grade, determining their reward. For example, if mom selects the $50 rewards level and junior gets a B for the month, he earns $40, which is debited from her account and transferred to his automatically. With the help of Radius Networks’ beacon and proximity services team, RoadPoints has successfully integrated beacons into their solution to provide specific proximity-based information about the driver using the app.

“Beginning in May, we introduced the beacon as an add-on feature that pairs with the app and lets us know that the kid is in his own car and therefore is the driver,” said Michael Guthrie, CEO of RoadPoints. “Knowing that improves the accuracy of the grade, and it also allows us to block phone usage while driving.” “We are excited to be working with RoadPoints to enhance their already innovative mobile solution for incentivizing teen drivers to drive safely,” said Marc Wallace, CEO of Radius Networks. “We are confident that this new solution will improve the overall safety of teen drivers everywhere.”

RoadPoints strives to ensure teen-driving safety by incentivizing good driving behavior. RoadPoints provides an app that records data on speed and speeding, braking and acceleration, and phone usage while driving. Based on this information, parents receive a report card that includes information on the child’s overall grade and specific driving mistakes, and they set up a rewards plan by which the child can earn up to a certain amount of money. Ultimately, RoadPoints provides an innovative solution to promote driving safety.

Screen Shot 2018-11-20 at 11.57.32 AM.png

Introducing Leash for iOS

By Scott Newman

This week, we released a new application called Leash for iOS to help track your stuff through the power of Bluetooth Proximity.

This app will help you configure your RadBeacon Dot quickly and allow you to range its distance. You can give your beacon a name (such as “My Keys”) and optionally ask for notifications when you go in and out of range of your beacon.

Leash has been an internal project for some time - many of us here use Dots (beacons) to track our items. We saw that others might want to do the same, so we polished up the interface and made it available for free. All you need to use the app is a RadBeacon Dot. You might also want the keychain fob accessory to attach the Dot to your keys, purse, or pet’s collar.  

Screen Shot 2018-11-20 at 11.55.34 AM.png

Possible Uses

  • Attach a Dot to your pet's collar and be notified when they leave your area

  • Put a Dot on your keyring so you can see how far away your keys are when looking for them

  • Stick a Dot in your purse and get notified if you walk away from it

For the Technically Curious

Under the hood, Leash uses our RadBeacon technology to locate and configure a Dot beacon via Core Bluetooth. We assign a personalized UUID and random major/minor numbers to the beacon so you don’t have to worry about what values to use. If you enable background notifications, we monitor the beacon’s region and trigger UILocalNotifications for enter and exit region events.

We do not use your GPS location, nor do we collect any analytics from the app.

Currently, you must use Radus Networks RadBeacon Dots with Leash. In the future, we may support other beacons and beacon advertisements.


We’d love to know how you are using the application or how you think it could be even better. Please let us know!

App Store Link

Radius Networks Supports Android's Nearby Notifications

By Marc Wallace and Scott Yoder

Android’s new Nearby Notifications

Nearby Notifications, an upcoming feature in Android that shows you apps or websites from things around you, was unveiled at Google I/O a few weeks ago.  Nearby allows developers to associate their website or app with beacons and provide low-priority notifications when scanned by Android devices that are nearby.

Profiled in the announcement were Radius Networks customers taking advantage of early access to this new technology – CVS, United Airlines and Notre Dame. Radius Networks is a whitelisted developer and can register Nearby Notifications with Google on behalf of our customers and partners.

Nearby Notifications in the Wild


Radius Networks has partnered with CVS to deploy and activate the largest beacon network in the world with over 9,000 separate locations and 20,000 beacons. Using the Google Nearby technology, customers entering a CVS location will be notified that they can print photos directly from their phone to the photo kiosk located in the CVS store. They will get this notification even if they do not have the app and will be taken to the Play Store if they don’t.

Screen Shot 2018-11-20 at 11.53.35 AM.png

United Airlines

United Airlines is using the Android functionality to remind passengers to download the United app before they board so they can take advantage of in-flight entertainment.

Screen Shot 2018-11-20 at 11.53.39 AM.png

University of Notre Dame

Notre Dame is using the new technology to enhance their campus tour with student-generated video content as they approach specific locations.

Screen Shot 2018-11-20 at 11.53.42 AM.png

So how does it work?

In order for Android’s Nearby service to detect a Nearby Notification, you must first register your beacon in Google’s Proximity Beacon API, and add an attachment with the specific namespacedType of “” (or “” for testing).

Note: if you use “”, your attachment must go through an approval process with Google. If you use “”, your attachment will be immediately available to devices that are in developer mode.

The data for the attachment is a JSON object of the format:

  "title": "TITLE GOES HERE",
  "description": "DESCRIPTION HERE",
  "url": ""

Google provides documentation on Nearby Notifications on their Developer Portal.

Once your beacon is registered and your attachment has been added, you should be able to turn on a beacon with the identifiers you registered (or use MacBeacon) and your device should respond by displaying a notification.

Screen Shot 2018-11-20 at 11.53.46 AM.png


We at Radius Networks believe Nearby Notifications will bridge a massive gap in the use of beacon technology. Now Android users will no longer need a mobile app to be notified of value-added experiences near points of interest.

Please reach out to us to see how we can help you engage your customers using this Nearby technology from Google and Radius Networks. Click here to contact us.

Announcing the JavaScript Beacon Library

By James Nebeker

At Radius Networks we’re proud of our extensive collection of software and development tools geared towards location services and Bluetooth beacons. Today we’re excited to announce the latest addition to this family of tools and products, the JavaScript Beacon Library.

What is the JavaScript Beacon Library?

The JavaScript Beacon Library is (surprise) a JavaScript library for broadcasting BLE beacon advertisements. It harnesses the internal Bluetooth capabilities of the host OS to send out beacon transmissions that nearby phones/tablets can discover, turning your device into the ultimate software beacon. It’s simple to use and integrate, letting developers concentrate on building cool apps that use beacon technology instead of worrying about the nuts and bolts behind the beacon advertising.

What platforms are supported?

Currently the only platform supported is Chrome OS, the JavaScript Beacon Library can be used inside Chrome apps to transmit beacon advertisements on any Chromebook, Chromebox, Chromebit, etc. It leverages the Bluetooth APIs internal to Chrome OS in order to do the beacon broadcasting, which are limited in use to Chrome apps only.

Getting started with the JavaScript Beacon Library

First you’ll need a Chrome app to start integrating the library, I recommend starting with this guide from the Chrome developer site for a quick introduction to Chrome apps and how to start developing one of your own. There you’ll find a sample app you can download to start developing with if you want a quick start. Once you have a Chrome app set up, head to the JBL Github repo where you can download a copy of the library, the file is called beacon.js. Drop this into your project directory and add it to the header of the app’s index.html file:

<!DOCTYPE html>
  <script src="beacon.js"></script>

Now the library will be available in your app’s JavaScript source.

Registering a beacon advertisement

To begin broadcasting as a beacon in your Chrome app, you need to register a beacon advertisement with the JBL. This is done with the registerAdvertisement() method, which takes in an hash of options that dictate the beacon type, identifiers, and advertised transmit power.

This method is asynchronous; it returns a promise, for which you can specify the appropriate callback functions for success and failure of the advertisement registration.

Below is an example of registering a beacon advertisement of type AltBeacon:

  type: 'altbeacon',
  ids: ['2F234454CF6D4A0FADF2F4911BA9FFA6', 1, 1],
  advertisedTxPower: -59
}).then(advertisement => {
  console.log('Advertising: ' + advertisement)
}).catch(error => console.log(error.message));

If an advertisement is successfully registered, it will be transmitted by the OS until it is unregistered. The registered advertisement is stored in an array, accessible at beacon.advertisements, where it can be unregistered later on when you no longer want to transmit this beacon. This is done the unregisterAdvertisement() method:

let registered_adv = beacon.advertisements[0];
registered_adv.unregisterAdvertisement().then(() => {
  console.log('Advertisement unregistered successfully.');
}).catch(error => console.log(error.message));

Only one advertisement can be registered at a time, so if you want to register a new beacon advertisement you first need to unregister any existing ones.

Registering custom beacon types

By default, the JavaScript Beacon Library supports three beacon types:

Additionally, the JBL supports any custom beacon type, so you can register any other beacon standards and broadcast with them just the same.

To register a custom beacon type you only need to specify a name, beacon layout string, and either a manufacturer ID or a service UUID depending on the type of Bluetooth advertisement the beacon standard utilizes. This is done with the registerBeaconType() method, for example:

  type: 'cool_beacon',
  beaconLayout: 'm:2-3=0000,i:4-19,i:20-21,i:22-23,p:24-24',
  manufacturerId: 0x1234

After registering a new beacon type, you can then register a beacon advertisement of that type using the name you specified.
For more information on the beaconLayout string used to classify custom beacon types check out this page from the Android Beacon Library docs.

Physical Web Display

With the release of the JavaScript Beacon Library, we’ve released an update to the Physical Web Display Chrome app in the Chrome Web Store. This new version incorporates the JBL, now enabling all major beacon types, not just Eddystone URL. This opens up the app to many other exciting use cases and extends the number of users you can reach drastically. To grab a copy of the newest version check out Physical Web Display in the Chrome Web Store, or check out this blog post for more info.

A note about Chrome OS BLE Advertising

One important limitation of BLE advertising on Chrome OS is that it is limited to Chrome apps running in “auto-launched kiosk mode” by default. This is a security decision made by the Chrome team, and can only be circumvented by enabling the “BLE Advertising in Chrome Apps” flag in chrome://flags. Without this flag enabled, only a Chrome app running in kiosk mode that is launched automatically at startup will be able to advertise BLE. For information on developing kiosk apps and putting your Chrome OS device into “kiosk mode” check out these links:

Eddystone Support for MacBeacon and ScanBeacon

By Scott Yoder

Today Radius Networks would like to announce new versions of our beacon tools for Mac: MacBeacon 2 and ScanBeacon 3. Both of these tools now support a full range of beacon advertisements including iBeacon, AltBeacon, Eddystone UID, Eddystone EID, Eddystone TLM, and Eddystone URL (Physical Web).

We have found these tools to be invaluable while developing mobile apps which respond to beacons and we’re excited to extend them to support the full line of Eddystone advertisement types.

MacBeacon 2

With MacBeacon 2, you can easily simulate iBeacon, AltBeacon, and Eddystone beacons. It is even possible to do interleaved advertising to broadcast multiple beacon types simultaneously.

Registering an EID with MacBeacon

MacBeacon 2 also supports Eddystone EID. With Eddystone EID, you have the option of registering your beacon with Google’s Proximity Beacon API and adding attachments to it so that your app can receive the attachments when the beacon is detected. Before getting started, you may need to create a new Google project using the Google Developer Console.

In order to register, you must first fill in all the fields with valid values including the “Identity Key” field which will be computed during the registration process (you can initially enter all zeros for this). After you have filled everything in, you must check the “Enabled” checkbox in order for the “Register” button to appear. When you click “Register”, you must authorize MacBeacon so that it can register beacons into your project on your behalf. Then you must select your project from the list. If registration is successful, MacBeacon will enable advertising and you should see some “advertising information” (including your registered beacon’s name) display below the form.

One thing to note: the “Namespace” and “Instance” combination must be globally unique. if you attempt to register an EID using a Namespace and Instance combo that is already registered, Google’s API will return a “409” error indicating that there is a conflict.

ScanBeacon 3

In addition to supporting Eddystone, ScanBeacon 3 also allows more advanced filtering of the advertisements that appear in the list. You can select which beacon types you want to include via the “Beacon Types” drop-down menu.

Screen Shot 2018-11-20 at 11.50.26 AM.png

The search field has become much more powerful and allows you do do a “full text search” on your list of beacons. For example, you can search for all Eddystone advertisements by entering “eddystone” or all Eddystone URL advertisements by typing in “url”. You could enter “uid 2f23” to find all Eddystone UID advertisements with “2F23” in either the namespace or instance identifiers.

You also have the ability to look at the advertisement bytes via the “Inspect Bytes” (CMD-I) command.

If you plan to use both MacBeacon and ScanBeacon on the same computer, you should know that ScanBeacon cannot see beacons that you broadcast using MacBeacon because they will both use the same bluetooth chip in your computer.

Available for Download Now

Both utilities are available on our accounts page in the utilities section. Download them and get started developing Eddystone EID enabled apps now:

Download Now on Radius Networks Accounts

Hope these tools help you build something cool. When you do, we’d love to hear about it.

Beacon Apps on Android 6 Update

By Aaron Kromer

We’ve previously discussed how to prepare your beacon-aware app to continue to function by complying with important changes on Android 6. Now that Android 6 has been generally available for several months we’ve learned a few more things. This covers some extremely important beacon-related behavior you need to know.

Location Services

You’re probably already aware that you need Location Services runtime permissions on Android 6. What you may not realize is that Location Services must also be ON.

If the service is OFF the logs will continue to show successful scans. However, you won’t see it find any beacons and your registered callbacks will sit idle. Our understanding is that this is the intended behavior for Android 6+ and is here to stay.

Additionally, you may have noticed a new Bluetooth scanning option under the new Scanning settings for your device’s Location Services. This setting currently has no effect on the general BLE scanning available to applications. So even with this setting ON if Location Services is OFF beacons will not be detected.

Foreground vs Background Scanning

There are some additional subtleties with foreground and background scanning. These revolve around whether your app is targeting API 23 or attempting to leverage the older permission model by targeting API 22 or lower.

The short answer is if you target API 22 or lower you can perform foreground scanning while Location Services is OFF. However, background scanning will not work. Background scanning will always require Location Services to be ON with Android 6+.

Location Services State for Scanning on Android 6

Targeting API Foreground Scanning Background Scanning


API < 23 ON or OFF ON

Why the Change?

Based on responses on the Android issue tracker this is to better protect user privacy. Part of the BLE scan reports the MAC address of the BLE device. It is theoretically possible that someone could create a map of beacon MAC addresses to determine a user’s geographical location.

This brings Android more in-line with how iOS works. Each operation system now views beacon detection as part of Location Services. They each require appropriate service authorization prior to use and both Bluetooth and Locations Services need to be turned on.

Announcing Physical Web Display for Chrome OS

By James Nebeker

Screen Shot 2018-11-20 at 11.47.07 AM.png

We are excited to announce the newest product from Radius Networks, Physical Web Display for Chrome OS. Physical Web Display is a Chrome Kiosk app that combines the advertising and marketing power of digital signage with the user enhancement and engagement of the Physical Web. With this app, you can easily set up an array of custom digital signage displays that not only show content to potential users or customers visually, but also connect with them directly via their mobile devices with the Physical Web.

So what makes this different from every other digital signage app out there? Can’t you just use a QR code to share a URL and let people access it easily on their phones? Or maybe an NFC tag? Well QR codes are great and all, but literally no one has ever scanned one to open a URL. Physical Web is like a QR code that people will actually use. URLs are pushed over-the-air to a user’s phone automatically, so they can check out your site without having to be the one guy that scans a QR code while everyone else around silently judges them. NFC tags are a little better, but they require you to slap one on or around every display you have out there. The Physical Web Display app uses the internal Bluetooth capability of the Chrome OS device to transmit the URL, so everything works out of the box without additional effort.

How can this help your business or organization reach users or customers? Rather than just asking them to check out your website or download your app, you can link them directly to your homepage, webstore, Facebook page, or Twitter feed. You can broadcast the URL to download your app in the App Store or Google Play Store directly, all without the aforementioned clunkiness of QR codes, NFC tags, or manually entering URLs. With deep linking in mobile apps, you can even send users to a specific location inside your app.

The app works by letting you provide custom content to display on-screen, which is then paired with a custom URL that you provide. This URL is transmitted over Bluetooth using Google’s Eddystone URL standard (the backbone of the Physical Web) while the paired content is displayed, reaching nearby users and allowing them to easily access the URL. You can add as many of these content/URL pairs as you want, and configure how long each one is displayed before rotating to the next one in the queue.

The Physical Web Display app runs on any Chrome OS device, from the small yet powerful ASUS Chromebit to the all-in-one AOPEN Chromebase, both of which are perfect for digital signage. To get started, find the right Chrome OS device for your needs and head to our knowledgebase for instructions on installing the app on your device and configuring your first advertisement. You can also check out Physical Web Display in the Chrome Web Store. For more info about the Physical Web and its possibilities check out our blog post and the Physical Web site.

Monitoring the Closest Beacon with Proximity Kit

By Scott Newman

Calculating the closest beacon to a device can be a challenge, but our latest release of ProximityKit makes it very easy to do. We’ve added a new delegate callback method to our library that will tell you when the closest beacon has changed. It’s easy to use right out of the box and it can be configured as needed.

Let’s look at how we solved the challenge so you can focus on writing world-class applications.


If you read through Apple’s iBeacon documentation, you’ll find their recommended approach to distance ranging is to use the proximity property on the CLBeacon class and they discourage developers from trying to detect specific distances. While this is a very good strategy, there are times when it is appropriate to determine the beacon’s distance.

The proximity property of CLBeacon returns a CLProximity enum with one of four values:

  1. CLProximityUnknown

  2. CLProximityImmediate

  3. CLProximityNear

  4. CLProximityFar

These values are calculated by Core Location automatically and take into account factors such as RF signal interference, fluctuation, etc.

Note: In our ProximityKit iOS library, we expose the proximity and accuracy properties from Core Location’s CLBeacon class in our RPKBeacon class. Any tips you find around the web for working with CLBeacon also apply to our RPKBeacon implementation.

When is estimated proximity good enough?

For many use cases, knowing if a device is immediatenear, or far from a beacon is good enough. Ideally, beacons are physically placed far enough apart so that it is not possible to be in immediate or near proximity of two beacons at the same time.

If this is the case for your application, the code can simply use the didRangeBeacons:inRegion:callback from ProximityKit or Core Location to see which beacons, if any, are immediate or near.

In practice, the immediate proximity is approximately 1-2 meters from the beacon, and this might be too close for your needs. You probably don’t want users to crowd around a podium in the middle of a museum exhibit to trigger an immediate proximity event.

In this scenario, it would make more sense to trigger when the proximity is near, but what if two beacons are both reporting near at the same time because they are about ten meters apart?

When to use the accuracy measurement

ProximityKit (and Core Location) also returns an accuracy measurement derived from a calculation using the beacon’s signal strength (RSSI) and the measured power calibration. While it is not strictly a distance measurement, it can be used as a proxy for distance calculations. Apple recommends this property be used “to differentiate between beacons with the same proximity value”.

From the CLBeacon reference discussion for accuracy:

Indicates the one sigma horizontal accuracy in meters. Use this property to differentiate between beacons with the same proximity value. Do not use it to identify a precise location for the beacon. Accuracy values may fluctuate due to RF interference.

Let’s imagine a scenario where three beacons are placed in a room approximately fifteen meters apart. Your user is standing in the room and all three beacons are reporting a proximity of near. We want to tell the user which beacon is the closest, so we can differentiate the three beacons by looking at the accuracy property.

Challenges using accuracy

The challenge of using the accuracy property is that the value can fluctuate wildly in a short amount of time. Perhaps the room is busy and people are walking between the device and the beacon, causing the signal to fluctuate and sporadically disappear.

To combat this, we can create some logic that averages the readings over a few seconds and reports back a running average of the accuracy reading.

The logic would work something like this:

  1. The didRangeBeacons:inRegion: method is called in your delegate

  2. Iterate over each beacon from step #1 and get its accuracy property

  3. Store the accuracy value from step #2 in an array along with its timestamp

  4. Iterate over the array from step #3, purging any readings older than five seconds

  5. Compute the average accuracy value from the array in step #4

  6. Compare the average accuracy value from step #5 for each beacon and determine which is the closest

The logic is straightforward, but there are subtle details that must be taken into consideration to conserve battery life and processing.

We wrote it so you don’t have to!

We felt this was enough of a common use case that we should write an implementation for the developers using our beacons and ProximityKit library. This functionality has been released with version 1.2.1 of our ProximityKit framework.

Using it is very simple. When instantiating RPKManager, provide the monitor_closest_beacon and averaging_secondsvalues in the configuration dictionary:

RPKManager *manager = [RPKManager managerWithDelegate:self andConfig:@{
        @"kit_url": @"<your kit url>",
        @"api_token": @"<your api token>",
        @"monitor_closest_beacon": @"true",
        @"averaging_seconds": @(10.0),

Note: averaging_seconds has a default threshold of five seconds; you can omit the key/value in the configuration if that value works for you.

How to use it

When you configure RPKManager this way, you’ll get a closestBeaconDidChange:forRegion: delegate callback:

- (void)    proximityKit:(RPKManager *)manager
  closestBeaconDidChange:(RPKBeacon *)beacon
               forRegion:(RPKBeaconRegion *)region

Here’s an example implementation of the delegate method:

- (void)proximityKit:(RPKManager *)manager closestBeaconDidChange:(RPKBeacon *)beacon forRegion:(RPKBeaconRegion *)region {
	if (beacon != nil) {
	    NSLog(@"New closest beacon: %@-%@", beacon.major, beacon.minor);

There are three things to know about the callback:

  1. If you go out of range of all beacons, the beacon value will be nil.

  2. The closest beacon will not change more than once every five seconds

  3. When the closest beacon calculation happens behind the scenes, the new closest beacon must be 10% closer than the current closest beacon

Steps #2 and #3 are designed to prevent “flapping” behavior where two beacons in very close proximity keep fighting each other to become the closest. This is part of the ‘smoothing’ behavior discussed above.


We hope that this new functionality cuts down the amount of code you need to write as a developer when you need to calculate the closest beacon. Give it a shot, and let us know what you think!

Physical Web with Pre-Configured Eddystone URL Beacons

We are excited to announce the availability of RadBeacon proximity beacons, factory-configured with custom Physical Web URLs to streamline access to the Physical Web and the Internet of Things

Radius Networks today announced the next step forward in promoting and popularizing the Physical Web by enabling customers to order RadBeacon proximity beacons that customers can purchase pre-configured to advertise Google’s Physical Web protocol. Pre-configured Eddystone URL beacons are available for purchase on the company’s website and simplifies deployment and access to the Physical Web, the latest advancement of the Internet of Things.

The Physical Web combines the power of web technology with the explosive growth of the Internet of Things, giving any smart device a web address. Soon, thanks to the power of the Physical Web, walking up to any smart device, be it a rental car, vending machine, a child’s toy, or a city bus stop, will provide immediate access to useful and relevant information and services.

“The Physical Web is a simple, yet powerful, way of leveraging beacon technology,” said Marc Wallace, CEO and Co-Founder of Radius Networks. “We believe that this will make the benefits of beacons more tangible for everyone.”

At CES 2016 in Las Vegas, Radius Networks deployed 1500 beacons throughout the convention show floor to deliver indoor navigation, in-app messaging and gamification to attendees via the CES Mobile App. The beacons also broadcast Physical Web URLs that, when clicked, took attendees directly into the maps section of the CES app. If the attendee did not have the mobile app, they were taken to a web page where they could download it.

Buy Physical Web Beacons

Get started today with Physical Web Beacons. They are available on our store now.

A Few Notes About the CES 2016 Beacon Scavenger Hunt

By Marc Wallace

The folks over at Make Magazine have posted about their efforts to hack the CES 2016 Beacon Scavenger Hunt.

We wanted to share our response with you:

Hey Alasdair and Sandeep, Marc Wallace at Radius Networks here.

A few comments on your post:

1. Hacking the Scavenger Hunt

The purpose of the Scavenger Hunt is to encourage attendees to explore areas of the show floor that they might otherwise have missed. If you complete the scavenger hunt, you get a token that you can present at the CES office and win a prize.

For the top prize winners, we use a procedure to validate that they actually visited the scavenger hunt locations at CES. Simulating the beacons at your desk generates a token in the mobile app, but it doesn’t mean you completed the scavenger hunt. It just means you missed out on seeing some really cool stuff at CES.

2. Tracking of Attendees

Radius Networks and CTA take mobile privacy very seriously. Beacons are used to generate venue foot traffic analytics which do not contain personally identifiable information.

Also, the message that was pictured and described as creepy, and possibly as a result of tracking using beacons, has nothing to do with our beacon implementation.

3. Indoor Navigation Beacon Information

In addition to scavenger hunt beacon information, you also accessed indoor navigation beacon definitions with related lat-long information. These beacons are in support of our extremely successful indoor navigation implementation at CES. As with the scavenger hunt beacons, this information is not considered sensitive, and the identifiers are essentially public information.

As a general approach, it’s important to use the appropriate security mechanisms for the sensitivity of the information involved. We feel we accomplished this for CES, that the integrity of the Scavenger Hunt has been maintained, and that attendees at CES will continue to enjoy the benefits of the beacon network.

Marc and Chris with the CES 2016 Scavenger Hunt Grand Prize Winner, Damien.

Marc and Chris with the CES 2016 Scavenger Hunt Grand Prize Winner, Damien.

Battery-Friendly Beacon Transmission

By David G. Young

While most beacon apps focus on detection of bluetooth beacons, some of the coolest mobile apps you can make involve making the device transmit as a beacon as well. Think about an app that lets friends know they are nearby one another. When two users walk within about 50 meters of each other, presto! The app alerts you that a friend is nearby.

Apple has supported beacon transmission since iOS 6, and most Android devices have done the same starting with Android 5.0. But lots of folks are wary of transmitting all the time. The conventional wisdom is that app developers need to be careful about transmitting because of its impact on battery. We all know that angry users with drained batteries will quickly uninstall your app. Is transmitting as a beacon really that bad?

To test this hypothesis, I used the Locate app for iOS and Android, the first configured to transmit an iBeacon frame and the second configured to transmit an AltBeacon frame. I figured I could run the apps for a long time and see what the battery drain is compared to the same device over the same period of time without the transmitter app running.

Screen Shot 2018-11-20 at 11.34.43 AM.png

Foreground vs. Background Transmission

It is important to note a major difference between iOS and Android when it comes to transmitting when your app is in the Background. On iOS, you essentially can’t do it. While BLE advertisements are allowed in the background, they are only allowed using a proprietary Apple format intended for advertising application services. You can’t send standard iBeacon transmissions unless your app is in the foreground. Android, on the other hand, has no such restrictions — you can transmit in the background all you want.

The fact that you aren’t allowed to transmit in the background on iOS leads many to believe the restriction is in order to save battery. Apple is notoriously stingy about restricting background usage of operations that are battery hungry.

Because of this restriction, the Apple tests had to be run when the app was in the foreground and the screen was on. Obviously, the screen causes a big battery drain itself. So it was important to run both the baseline test and the transmitter test under the same conditions with the same screen pattern on.

Test Setup

In order to test the battery usage of beacon transmitters on iOS and Android I installed the Locate app on an iPod Touch 5th Generation with iOS 8.1 and a Nexus 9 with Android 6.0. I chose non-phone variants of iOS and Android so I could eliminate the cell radio as a source of battery drain — something that is often outside developer control and subject to random variation. In addition, during the tests I put the devices into airplane mode (but with Bluetooth enabled) so that WiFi and GPS radios did not affect the results. Finally, I uninstalled everything but stock apps so I knew there weren’t any other apps draining the devices in the background.

Because iOS can only transmit in the foreground, I configured “AutoLock” to Never and set the screen brightness to a minimum. This kept the screen on and the app in the foreground. For both the baseline and transmitter tests, I kept the same Locate transmitter screen on the display. This is important because different screen patterns can affect battery usage when the display is on.

On Android, I simply hit the shoulder button to turn off the display for both the baseline and transmitter tests. Android also lets you configure the transmitter power level (which I set to low) and the number of advertisements per second (which I set to 1 Hz aka Low Frequency.)

Screen Shot 2018-11-20 at 11.34.47 AM.png


You can see the results of the tests in the tables below:

Android Nexus 9 (6,700 mAh battery)

Baseline Transmitter On Transmitter On (extended)

Test Duration 12:45 hours 22:20 hours 52:36

Battery Start 100% 100% 100%

Battery End 100% 100% 94%

iOS iPod Touch 5th Gen (1030 mAH battery)

Baseline Transmitter On

Test Duration 04:16 hours 04:38 hours

Battery Start 100% 100%

Battery End 36% 43%

The first thing you notice is that the Nexus 9 really does not use much of its battery regardless of whether it is transmitting or not. And even with the beacon transmitter on, the battery was still at 100% after nearly 24 hours. After over two days of transmitting it was still at 94%. Clearly that beacon transmission is not using much battery. It’s so low, it is impossible to calculate how much it is using with any certainty with this test setup.

The iOS results show much higher battery usage 36% over the course of only four hours, but it is undoubtedly due to the screen being on. In fact, when both the screen and the beacon were on the battery usage was lower. There is no reason to think this is actually because the beacon transmission saves battery — it’s probably just that the beacon battery usage was within the margin of error of the test method. Because the screen is using so much battery, it’s hard to conclude that the beacon transmitter battery usage is negligible in this test setup. However, it is clearly negligible compared with the battery usage of the screen. And since iOS requires the screen to be on to transmit a beacon signal, there is no point in worrying about beacon battery usage at all.


These tests show conclusively that beacon transmission on iOS and Android causes an insignificant battery draw compared with other sources of battery drain. There is simply no reason to avoid beacon transmission in order to save battery.

Is this really so surprising? Consider that manufacturers of hardware beacons typically power a transmitter for months using a tiny CR2032 coin cell battery. These batteries have a capacity that is less than a tenth of the energy density of even the small battery in an iPod touch.

The fact that Apple restricts transmission in the background probably has more to do with other design concerns (like limitations on how many apps can transmit full advertisements simultaneously using a single bluetooth chip.) So if you have an app on an Android device that can transmit in the background, and you can get access to the transmitter before all the transmission slots run out, go for it! Your app users will never notice the difference in battery usage.

Hashtag Sports Fest in Brooklyn, NY

By Christopher Sexton

Radius Networks is at the Hashtag Sports Fest today and tomorrow in Brooklyn, NY.

Hashtag Sports Fest is a groundbreaking 3-day expo, conference, and celebration of the convergence of sports, digital media, and technology that will serve as an industry showcase and catalyst for innovation.

Over 30 exhibitors and hundreds of decision makers from global brands, media companies, and disruptive startups will gather with the sports industry in over 60,000 sq. ft. of New York City space on Oct. 20-22 to discuss the critical opportunities and challenges that emerging technologies present to sports content providers and the Millennial / Generation Z fan experience.

From the creators of the industry leading #SportsConf virtual thought leadership series with over 125 speakers and 20,000 viewers to date, the inaugural Hashtag Sports Fest will take the conversation offline for an unmatched, immersive educational experience and networking opportunity in the heart of Brooklyn.

Come see Radius Networks and a lot more innovations, where sports and technology meet to make marketing and fan experiences better.

For more details and to visit the free expo check out

Screen Shot 2018-11-20 at 11.33.09 AM.png

Proximal Push Notifications

By Scott Yoder and Christopher Sexton

Push notifications are a great feature on iOS, but they are a pretty blunt instrument. When you send them, they get delivered to recipients no matter where they are. What if you want to send a notification only to people that are in a specific location?

One option is to report their location to the server, and then only notifications to the people in the desired location. But this has privacy implications. It involves tracking users locations all the time, and that’s a little creepy. We were not willing to do that.

For Campaign Kit and came up with a solution that is both reliable, quick, and treats customer’s privacy with respect. This works by having our SDK in an App on the phone. The phone knows where it is and can use that information. The important part is to not report up those details unnecessary.

How do we do this? The solution we follow is:

  1. Send a silent Push Notification

  2. Check Recent Places

  3. Sync with the Server

  4. Range for Beacons

  5. Show Notification

Lets go over those steps in more detail.

1. Send a silent Push Notification

Screen Shot 2018-11-20 at 11.30.04 AM.png

On iOS, Apple supports a “Silent” push notification, where the app will receive a callback in the background. You just have to implement the didReceiveRemoteNotification in your app delegate and set the remote-notification Background Mode in the plist.

- (void)         application:(UIApplication *)application
didReceiveRemoteNotification:(NSDictionary *)userInfo
  // Handle the callback }

2. Check Recent Places

Screen Shot 2018-11-20 at 11.30.08 AM.png

This is important to not overwhelm the back end and to have a low impact on devices not in proximity to a beacon. Check the internal list of places and make sure that the phone has been near one recently, perhaps within the last hour.

If we find that there was a recent and relevant location we will continue; otherwise, stop here.

3. Sync with the Server

Now that we know this phone is likely to be in proximity to a beacon we want to sync with the server. This will fetch any content as well as a list of beacons that will trigger the notification.

4. Range for Beacons

Screen Shot 2018-11-20 at 11.30.14 AM.png

Now that we have updated data, range for a few seconds. If there is a beacon within range, you have found a match. The method we use for doing that looks something like this:

- (void)handleRemoteNotification:(NSDictionary *)userInfo
          fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
  NSLog(@"CampaignKit: handling remote notification.");
  if ([proximityKitDelegate placeDetectedRecently]) {
    // we've seen beacons/geofences recently, so we better sync and check campaigns     [self syncWithCompletionHandler:completionHandler];

    // range for 5 seconds in the background     __block UIBackgroundTaskIdentifier backgroundTask = \
    [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:
        // if iOS tells us our task has expired, let's quit before we are killed         [[UIApplication sharedApplication] endBackgroundTask:backgroundTask];
        backgroundTask = UIBackgroundTaskInvalid;

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, FIVE_SECONDS)), dispatch_get_main_queue(),
        if (backgroundTask != UIBackgroundTaskInvalid) {
          [[UIApplication sharedApplication] endBackgroundTask:backgroundTask];
          backgroundTask = UIBackgroundTaskInvalid;
  } else {
    // haven't seen any places recently, so let's assume this push isn't for us     completionHandler(UIBackgroundFetchResultNoData);

5. Show Notification

Screen Shot 2018-11-20 at 11.30.18 AM.png

The fun part: notify the user. Send the local notification, display the content, whatever your app needs to do to inform the end-user. And only the people who would care about that information.

Campaign Kit: Engagement where it counts

Want this functionality in your app? Check out Campaign Kit, and we take care of these details for you. It’s an SDK that you can drop in to take advantage of beacon and geofence capabilities to deliver targeted campaigns to mobile devices within proximity of any place. Complete with simple content editor, campaign analytics, smart caching, and more.

How to Pop a Pass Using iBeacon Technology

By Michael Harper

Using iBeacon Technology to Display a Pass in iOS

PassKit was introduced in iOS 6 and brought us coupons, boarding passes, store cards, and event tickets directly on our iPhones. I remember adding an Alaska Air boarding pass to Passbook several years ago (now known as “Wallet” in iOS 9) and being pleasantly surprised to see it magically available on my phone’s lock screen when I was at the airport.

How’d they do that?

I’m guessing they used a geofence in the pass to cause it to be front-and-center when I was at the airport where I’d board the plane. It turns out you can do the same thing when a pass is installed on a device that is in proximity to a specific beacon!

Different types of passes can be added to Wallet: airplane boarding passes, store cards, discount coupons, and payment methods for Apple Pay, just to name a few. In this tutorial, we are going to build a membership card pass for a fictional fitness club named “RadBeacon Athletic Club”. The idea is that the pass should pop onto the iOS lock screen when in the vicinity of a beacon at the facility’s front desk in order to be scanned.


The RadBeacon Athletic Club (RBAC) has a front desk where members check in as they enter the fitness area. We would like for the member‘s pass to be available from his phone‘s lock screen when he arrives at the front desk. This will make it very easy for the member to have his pass scanned without even breaking stride.

We are going to configure a beacon at the front desk with the following values:

Beacon Identifier Value

UUID 2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6

Major 2

Minor 150

For the purpose of creating a pass, I will pose as member #24601.
The Pass Type ID for this pass is

Creating a Pass

A pass “package” is comprised of a directory containing a pass.json file and a few image files:

  • icon.png — displayed in the pass notification on the lock screen

  • logo.png — appears in the upper-left-hand corner of the pass

There are additional images that may be specified for a pass, but we‘re keeping it simple.

The pass.json file is where the magic happens. It is simply a dictionary of keys and values that define the pass. There are a bunch of different keys available, including pass identifiers, description, styling, and “relevance” which specifies where the pass is likely to be used. The beacons key is the one we’re interested in.

I started with the “generic” pass sample provided by Apple and stripped it down to the bare minimum and then added the beacons entry.

"beacons" : [
    "major" : 2,
    "minor" : 150,
    "proximityUUID" : "2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6",
    "relevantText" : "RadBeacon Athletic Club Front Desk"

This is the complete pass.json file (with the teamIdentifier elided):

  "description" : "RadBeacon Athletic Club Membership Card",
  "formatVersion" : 1,
  "organizationName" : "RadBeacon Athletic Club",
  "passTypeIdentifier" : "",
  "serialNumber" : "2460124601",
  "teamIdentifier" : "your_team_identifier_here",
  "beacons" : [
      "major" : 2,
      "minor" : 150,
      "proximityUUID" : "2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6",
      "relevantText" : "RadBeacon Athletic Club Front Desk"
  "barcode" : {
    "message" : "24601",
    "format" : "PKBarcodeFormatPDF417",
    "messageEncoding" : "iso-8859-1"
  "foregroundColor" : "rgb(255, 255, 255)",
  "backgroundColor" : "rgb(0, 0, 0)",
  "generic" : {
    "primaryFields" : [
        "key" : "member",
        "value" : "Brian Johnson"
    "secondaryFields" : [
        "key" : "subtitle",
        "label" : "MEMBER SINCE",
        "value" : "2007"
    "auxiliaryFields" : [
        "key" : "favorite",
        "label" : "FAVORITE EQUIPMENT",
        "value" : "TRX Suspension Trainer",
        "textAlignment" : "PKTextAlignmentRight"

Once you‘ve assembled the contents of your pass, you need to sign the pass directory with a certificate obtained from the Apple Developer Member Center. This generates a .pkpasspackage which is the actual pass that needs to be distributed. I used the Apple-provided signpass executable (see Passbook Support Materials) in conjunction with my certificate to generate the signed pass package. These steps are all covered in detail at the Apple Developer site.

The completed pass directory can be found here.

Installing the Pass

After signing the pass, I previewed the pass on OS X.

Because iCloud is configured on my Mac and on my iPhone, I am able to add the pass to my wallet directly from my Mac by double-clicking the pass and clicking Add to Wallet. You can send the pass to your phone any way you like — email, Message, AirDrop, web site — as long as you can tap on the attached pass to install it into Wallet.


Note that Location Services need to be enabled for the Wallet app on iOS in order for the pass to become available in the vicinity of a beacon.

I used RadBeacon to configure a RadBeacon Dot with the UUID, major, and minor specified for the front desk.

Screen Shot 2018-11-20 at 11.22.13 AM.png

Once the pass is installed and the beacon is enabled, whenever my phone is in the vicinity of the front desk beacon, the pass becomes available on my lock screen.

Now I can swipe on the pass notification and see the pass.

The pass notification also appears on my Apple Watch.

Tapping through on the notification displays the pass details and QR code.

Announcing Radius Networks Services

Yesterday we released a new offering of managed services for enterprise customers including beacon deployment, network monitoring, maintenance and support.

“At Radius Networks, we’ve helped major, global enterprise brands develop and deploy large, sophisticated proximity networks,” said Ken McInerney, Director of Client Services at Radius Networks, “We are excited to formalize these matured capabilities and offer turnkey managed services that relieve clients of the day-to-day burden of managing and monitoring their proximity services networks.”

Radius Networks Services (RNS) comprise an end-to-end managed solution for proximity beacon networks of all sizes and include network architecture, beacon deployment and optimization as well as ongoing monitoring and maintenance of the entire system.

Key components of the RNS service include continuous monitoring by Radius Networks’ Proximity Network Operations Center (PNOC), located in Washington, DC, and local field maintenance and problem resolution conducted by Radius Networks field engineers and a network of authorized local technical partners.

“Our clients are coming to the table with increasingly more robust business objectives for their proximity networks,” explained Radius Networks CEO, Marc Wallace, “Since we are the technical experts behind the technology, Radius Networks is uniquely positioned to partner with our clients over the long term to ensure that their networks perform flawlessly.”

RNS services will be initially available out of Radius Networks’ North American facilities in the 4th quarter of 2015, and Radius Networks is currently working with partners on a European facility to provide hosting and managed proximity services directly to European clients in the 1st quarter of 2016. Find out more information about Radius Networks Services.

Is Your Beacon App Ready for Android 6.0?

By David G. Young

The new Android 6.0 release has several important changes that affect apps detecting bluetooth beacons. If you have a beacon-based app already in the Play Store, or are planning a new beacon-based app, you’ll need to make updates to keep your app from breaking as users transition to Android 6.0.

While this article focusses largely on the impact for users of the Android Beacon Library and Radius Networks’ ProximityKit and CampaignKit libraries that are built upon it, the same issues described here apply to any app that detects beacons. If you are using a different vendor’s SDK, it is important to make sure they will continue to work on Android 6.0.

Runtime Permissions

The biggest change for beacon apps in Android 6.0, codenamed Marshmallow, and sometimes called just “M”, has to do with permissions. Just like iOS, Android now implements permissions at runtime instead of the traditional way of granting permissions at install time. Apps designed for Marshmallow (SDK 23 and above) must add code to prompt users for some permissions after the app starts up, otherwise they will not be granted.

Not all permissions, however, work this way. Permissions marked as PERMISSION_NORMAL are still granted the old fashioned way: at install time. For beacon apps, two important permissions continue to follow the old model: android.permission.BLUETOOTH and android.permission.BLUETOOTH_ADMIN, both of which is needed to scan for beacons. Because these permissions still use the old behavior, nothing really changes with them in Marshmallow.

While the bluetooth permissions are enough to allow your legacy app to scan for beacons on Android 6.0, these permissions only allow it to do so in the foreground. Background scanning for bluetooth devices in Android 6.0, including beacons, now requires either android.permission.ACCESS_FINE_LOCATION or android.permission.ACCESS_COARSE_LOCATION.

This means that apps to be installed on Android 6.0 devices that want to discover beacons in the background must make changes. Apps must declare one of these location permissions in AndroidManifest.xml. This is true even for legacy apps that don’t target SDK 23 used for Android Marshmallow.

What’s more, these permissions follow the new runtime model. This means that apps that target SDK 23 must also prompt the user for a location permission after the app is launched. If you fail to prompt for and get this permission, you’ll get the following error in LogCat when you try to do a bluetooth scan in the background, and no beacons will be detected:

09-22 22:35:20.152  5158  5254 E BluetoothUtils: Permission denial: Need ACCESS_COARSE_LOCATION or
                                                 ACCESS_FINE_LOCATION permission to get scan results

To avoid your Android Marshmallow users getting this error, you must at least update your legacy AndroidManifest.xml with the following:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION”/>

And you must also add code like the following to an Activity if your app targets Marshmallow (if you set targetSdkVersion 23):

private static final int PERMISSION_REQUEST_COARSE_LOCATION = 1;
// ...

protected void onCreate(Bundle savedInstanceState) {

    // ...

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {

        // Android M Permission check

        if (this.checkSelfPermission(Manifest.permission.ACCESS_COARSE_LOCATION) != PackageManager.PERMISSION_GRANTED) {

            final AlertDialog.Builder builder = new AlertDialog.Builder(this);

            builder.setTitle("This app needs location access");
            builder.setMessage("Please grant location access so this app can detect beacons.");
            builder.setPositiveButton(android.R.string.ok, null);

            builder.setOnDismissListener(new DialogInterface.OnDismissListener() {


                public void onDismiss(DialogInterface dialog) {
                    requestPermissions(new String[]{Manifest.permission.ACCESS_COARSE_LOCATION}, PERMISSION_REQUEST_COARSE_LOCATION);





public void onRequestPermissionsResult(int requestCode,
                                       String permissions[],
                                       int[] grantResults) {
    switch (requestCode) {
            if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                Log.d(TAG, "coarse location permission granted");
            } else {
                final AlertDialog.Builder builder = new AlertDialog.Builder(this);
                builder.setTitle("Functionality limited");
                builder.setMessage("Since location access has not been granted, this app will not be able to discover beacons when in the background.");
                builder.setPositiveButton(android.R.string.ok, null);
                builder.setOnDismissListener(new DialogInterface.OnDismissListener() {
                    public void onDismiss(DialogInterface dialog) {

How Permission Prompting Works

The code above will first check to see if the location permission has already been granted. If not, it will prompt the user with an AlertDialog, “Please grant location access so this app can detect beacons.” This dialog is not strictly required, but it is recommended to first explain to the user why your app needs the permission. While this message is just an example, you should probably fine tune the verbiage to explain in less technical terms what functional benefit users gets from granting this permission. Otherwise, users will likely deny the permission to keep the app from tracking them.

After presenting this dialog, the system then calls the new Android requestPermissions method that actually does the prompting. The dialog screenshot above shows what the user actually sees. Android also provides a callback to the app telling you the result of what the user decided (see the onRequestPermissionResult callback), but it is important to note that users can change their mind later on via settings and turn permissions on or off. In that case, the callback method won’t get notified.

Location Permissions are not Enough

It is important to note that the location permission does not replace the need to request BLUETOOTH and BLUETOOTH_ADMIN permissions – all three are now necessary. And just because you get user to grant the permission doesn’t automatically turn bluetooth on. It still needs to be turned on separately, so you will need to keep prompting your users to do that, too.

Two other supplemental permissions used by the Android Beacon Libraryandroid.permission.RECEIVE_BOOT_COMPLETED (used to start looking for beacons after phone startup) and android.permission.INTERNET (used to download an updated database of device-specific distance estimation formulas) also follow the old model. For beacon apps using the Android Beacon Library, these two supplemental permissions will continue working the same way with Android Marshmallow.

Power Saving Modes

The other big change for beacon apps with Android Marshmallow is that it implements two power saving modes which affect background operations. Fortunately, apps using the Android Beacon Library, and other Radius Networks SDKs built upon it (like ProximityKit and CampaignKit) don’t need to make any changes to their apps as the library handles all the details of keeping beacon scanning going in the background. If you use other code to scan for beacons, or if you are interested in how the Android Beacon Library handles the changes, read on. If you’d rather just take our word for it, skip to the MAC address section below.

Doze Power Saving Mode

Android’s new Doze feature will put your device in a battery saving mode when the screen is off and it is not plugged in, and the operating system detects that it is sitting motionless based on accelerometer input. This is intended to cover cases where it is sitting on a desk, but not when it is in your pocket or purse while you are moving around, or in a moving vehicle.

To understand how this affects background beacon scanning with the Android Beacon Library, it is important to understand how the library handles periodic background scanning. It uses a background Service that uses the Android Handler mechanism to periodically start and stop scanning. It also uses the AlarmManager to restart the scanning service if the app and service are terminated due to low-memory conditions or due to the user closing the app from the task switcher.

Doze does not affect the ability to do bluetooth scans or run Handler-based timers, but it does affect the ability to use the Android AlarmManager system, which some beacon-based systems use to schedule bluetooth scans. For apps based on the Android Beacon Library, the disabling of Alarms does not cause problems in scanning for beacons because it only uses Alarms as a backup should Handler-based timers fail. Tests on a Nexus 9 running the third preview release of Android M (build number MPA44l) show that beacon detection continues normally under Doze.

App Standby Power Saving Mode

App Standby is similar to Doze, but it is triggered under different conditions. If a user doesn’t explicitly launch an app for several hours or several days (Google won’t say specifically how long it takes), the app is put into App Standby mode whenever the device is not connected to a charger. (App Standby also may be avoided if the app sends visible notifications.) Once an App is in App Standby, it generally cannot access the network, something that might prevent calling web services based on beacon detections. That said, App Standby does not specifically affect beacon detection with the Android Beacon Library, because bluetooth scanning service continues to run normally, and the AlarmManager and Handler-based timers continue to work. Again, this has been verified by tests on a Nexus 9 running the third preview release of Android M.

Network Calls Blocked in App Standby

Being blocked from making network calls can still affect your app. If your app only needs to periodically contact a web service, App Standby can keep it from trying to do so. In theory, an app in App Standby can still make network calls once in awhile. As Google says, “if the device is idle for long periods of time, the system allows idle apps network access around once a day.” Unfortunately, there is no documentation on how this works. If your app uses one or more libraries that require background network access and the app requires background network access in its own code, there is no guarantee which codebase will try background network access first, and which one will actually succeed “around once per day.”

Fortunately, there are two other ways an app in AppStandby can get network access aside from the squishy “around once per day” promise.

  • The app receives a new “high priority” message from Google Cloud Messaging (GCM). Receiving such a push notification amounts to a get out of jail free card. But Google has yet to release details on how to send this new high priority push notification. What’s more, it’s based on Google Play Services, which are not available on many devices like Amazon’s Kindle Fire line, the vast majority of tablets and handsets in China, and a growing number of non-Google Android devices in India and other parts of the world.

  • The phone is charging. Any app that has been put into App Standby temporarily regains network access after charging is connected. An app can therefore register to receive a broadcast message when power is connected and then attempt to make network calls at that time. (It’s probably a good idea to delay for a minute or so to wait for full network access to be restored.) The code below shows how you set this up in the AndroidManifest.xml.

<receiver android:name="com.mycompany.myapp.MyBroadcastReceiver">
    <action android:name="android.intent.action.ACTION_POWER_CONNECTED"/>

While the Android Beacon Library does not require background network access, Radius Networks’ ProximityKit and CampaignKit libraries for Android do make periodic network calls to sync new data with the server. Using techniques like described above, new releases of these libraries for Android 6.0 will continue to sync data even in the background.

Background Scanning and Launching Unchanged

The Android Beacon Library’s scanning service starts up in the background by using a broadcast receiver that listens for the RECEIVE_BOOT_COMPLETED event. This same broadcast receiver also handles alarms that go off after five minutes of the scanning service not being active. These alarms ensure that the service is able to keep looking for beacons even if the operating system had to temporarily evict the app due to a low memory condition. Based on testing with the Nexus 9 and the Android Marshmallow preview release, these capabilities are all unchanged with the new OS update.

As described above, the only limitation with Doze is using Alarms to restart beacon scanning. Because Alarms are disabled in Doze, the Android Beacon Library cannot use Alarms to restart itself if it is manually killed by a user or if memory pressure causes the operating system to terminate the app. However, because interacting with the device will cause it to exit Doze, there is no easy way for a user to kill an app while it is in Doze. Similarly, because a user is not interacting with a device while it is in Doze, it is very unlikely that an app will start using a large amount of memory causing the a beacon-based app to be shut down to free up memory. In the very unlikely event that this does happen, the app would stop scanning for beacons until the next time power is connected or the phone rebooted.

The table below shows the effect of different Marshmallow modes on the scanning and auto-restart techniques used by the Android Beacon Library.

Platform/State Timed BLE scans Low Power Restart Scan Restart Scan
Scan Filter on Alarm on Power Connect

Lollipop Yes Yes Yes Yes

Marshmallow Yes Yes Yes Yes

App Standby Yes Yes Yes Yes

Doze Yes Yes NO N/A*

* Power connection automatically disables Doze

MAC address Spoofing and Read Blocking

Apps on Android 6.0 can no longer read the device’s own bluetooth MAC address, and this bluetooth MAC address is spoofed when sending out packets while doing an active bluetooth scan. The MAC address is randomized each time you start transmitting as a beacon (or doing bluetooth advertising for other purposes.) While transmitting as a beacon using the Android Beacon Library’s BeaconTransmitter class continues to work normally, receiving devices will see that it sends a different spoofed MAC address each time transmission starts.

Interestingly, blocking access to reading bluetooth MAC addresses is part of the rationale behind requiring location permission to scan for beacons. This restriction is already discussed in the permissions section above. But it is worth noting here Google’s justification for this permission change being based on reading MAC addresses:

“The MAC address and the SSID can be used to identify surrounding devices. Knowing the location of these devices can be used to infer the phone location. As we have no way to know if the app would try to infer user’s location via WiFi scans we take a conservative approach to protect the user’s privacy. If an app is targeting pre M SDK does not have ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION it will get scan results only if it is in the foreground. For M SDK apps the location permission is required to get scan results” – Google


While there are big changes in Android Marshmallow that affect beacon apps, users of Radius Networks SDKs like the Android Beacon LibraryProximityKit and CampaignKit are well positioned to make a smooth transition. The libraries already handle most of the details. If you have an existing beacon app that does not yet target SDK 23 and only needs to work in the foreground, no changes are needed. If you have a beacon app that needs to work in the background, you need to update it to request proper location permissions as described in the first section. Users of ProximityKit and CampaignKit will need to upgrade their SDKs to keep background syncs happening on Android 6.0.

Announcing the RadBeacon Smart

Today we have released RadBeacon Smart, the industry’s first software beacon platform.

The RadBeacon Smart software beacon platform by Radius Networks can turn existing hardware with BLE capability into a beacon. The RadBeacon Smart enabled beacon can also be remotely managed and configured using the RadBeacon Smart API and through Radius Networks Director beacon management service. Additionally, the RadBeacon Smart beacon can manage other beacons within range of it, acting as a hub within a fully-managed beacon network.

“We are seeing rapid growth in demand for our more sophisticated, secure and capable proximity products, like the RadBeacon Smart software platform. Enterprises in many different industries - from restaurants to sports stadiums to factories - need a robust, proximity solution that is flexible and can be managed to handle a rapidly evolving environment.” said Marc Wallace, CEO & Co-Founder of Radius Networks, “Furthermore, the ability to remotely install the RadBeacon Smart beacon software to existing devices in the field is a key benefit of our new platform.”

Radius Networks is currently deploying the RadBeacon Smart platform globally and with enterprise customers. Companies interested in learning more about the RadBeacon Smart platform can contact Radius Networks sales engineers for more information.

“Up to now, beacons have been considered to be cheap, battery-powered, throw-away devices. Unfortunately this approach does not meet the operational and management needs of large enterprises with geographically distributed locations. The RadBeacon Smart platform delivers a flexible, fully-managed, connected and customizable beacon solution that provides the industrial strength capabilities that these customers demand,” added David Helms, Chief Product Officer at Radius Networks, “Flexible, connected, software-defined beacons are the next big evolution in proximity solutions.”