Beacons in Chrome (Release) Omnibox

Last month we mentioned that Eddystone via Chrome Omnibox Looking Likely. Since then, Google has started to roll out Chrome 57 release (rather than dev and beta) that includes Physical Web results in the Omnibox. This is on Android and iOS. Note that even if you have Chrome 57, this feature might not yet be enabled for you. This is because Google are also switching on the feature gradually. If you want to see what Eddystone beacons your Chrome browser can see, you can type chrome://physical-web. This works, irrespective of whether the omnibox beacon detection is switched on yet.

UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.

Eddystone via Chrome Omnibox Looking Likely

Last month we wrote about Google’s experimental Omnibox implementation available via Chrome flags. As it was an experimental feature, it was just as likely to be dropped as adopted.

We are pleased to see this functionality has moved a step closer to being used by everyone. It’s now available in the Chrome Dev and Chrome Beta builds. On Android, it works in the Dev version for all users and you don’t set the flags. On iOS, you need to sign up for Chrome Beta via TestFlight. It’s enabled for ~90% of logged-in iOS users on Beta.

Provided everything goes ok, Google have said that:

“omnibox integration will start rolling out on Chrome Stable for both Android and iOS sometime in the next few weeks and will likely take a few more weeks to reach 100%.”

If this actually happens, it has the potential to dramatically increase the discoverability of Eddystone beacons on iOS and Android.

UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.

Chrome, Eddystone and the Omnibox

There are some posts on Twitter and articles talking about how Eddystone appearing in iOS Chrome’s Omnibox might transform proximity notification scenarios. So what is this and what does it look like?

This came about due to the Physical Web/Chrome teams experimenting with new ways to show Eddystone notifications:

At the moment, notifications appear at the end of the ‘Today’ view. They get a bit lost because you have to swipe down get the notifications, swipe left and then scroll to the bottom:

BeaconZone Eddystone notification at the bottom

Noone is going to see this unless they know it’s there and are trying very very hard. Even though Eddystone detection is designed to be ‘pull’ rather than ‘push’, it’s a bit too difficult to find local Physical Web beacons.

With Google’s experimental Omnibox implementation, beacons come up when you go to do a Chrome search. At the moment, to try it out you have to enable an experimental flag by visiting chrome://flags:

After you do this, local physical web beacons appear when you start a search:

It’s far more likely people will see this rather than the Chrome widget at the bottom of the notifications Today panel.

It’s unknown whether this will find it’s way into future versions of Chrome without having to set the flag or whether it might appear on Android. Android has more visible Eddystone detection as it’s built in Android itself (Play Services to be more specific) and appears near the top of the notifications panel.

UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.

Troubleshooting Eddystone-URL on Android


Important: This web page is provided for historical purposes.

On 25 October 2018, Google announced they are discontinuing Nearby Notifications on Android. This mechanism should no longer be used.

Read about using Beacons for Marketing


This post assumes you already know about managing Physical Web URLs and the use of SSL.

What do you do if you have set everything up and aren’t getting any notifications? Here are some things to try and do:

  • Internet connectivity? Android connects to a Google proxy and then to your site to get information, for example the web site title, to show to the user. If there’s no or poor (slow) Internet connectivity, the beacon will appear not to be detected. To test connectivity, enter your URL into Chrome on Android and see how long it takes. Anything more than a few seconds will cause the Google proxy to give up.
  • Is it the URL? Try a URL that you do know works for someone else, for example one generated by phy.net or our test URL http://bzone.click/bz
    If you think it’s a problem with the URL, you might like to try using Google’s Physical Web URL validator. However, be aware that the validator itself has faults and we have seen URLs which work that fail with the validator.
  • Is it your URL content? Any URL content, for example images, must also be accessed via SSL (https://) links.
  • Is it your URL shortener? Some public URL shorteners can get overloaded and when they take too long to respond, the Google Physical Web Proxy gives up. The total time for the shortener and your web site to respond needs to be less than 3 seconds. Test the shortener speed and your web site speed in a normal web browser. Try a different URL shortener.
  • Is it your web server?  If you have control of the web server and it uses a Cache-Control header, make sure you set it to at least 24 hours so that it gives the Google Physical Web Proxy time to update it while using the old cached version.
  • Are you linking to the Play App store? Links to the Play store are not supported.
  • Have you waited long enough? While notifications usually arrive in the order of seconds, on some phones this can be minutes. Wait at least 10 minutes before concluding it isn’t working. Turning the screen off and on can sometimes cause Android to re-scan for beacons.
  • Is it Android? Try the Physical Web app. Note that notifications are not guaranteed. If Nearby has already sent you notifications recently then it may back off to make sure it is not annoying you.
  • Are you running Android 8.0 (Oreo)? There are problems with Android 8.0. We have submitted an issue with Google.
  • Is it your phone? Really. Some phone have problems with Bluetooth. Try a different Android phone.
  • Is it the beacon? Use the ‘nRF Connect’ app to determine if it sees the beacon and the correct URL.
  • Is the beacon being detected? You can test if the beacon has been set up correctly by going to Settings … Google … Nearby and your beacon will be shown (you might need to use the refresh button at the top).
  • Have you previously dismissed the notification?  If the notification has been dismissed on a device recently, that device may not show another notification a period of time. You can reset the backoff policy by opening Settings … Google … Nearby.
  • Is your notification blocked? If notifications have suddenly stopped working, Google might now be blocking your URL. The Google proxy has a scoring algorithm such that a notification won’t show if it has not been well received by users. Try a new URL.
  • Is it the Google Proxy? We had a customer say that trying to use the Beacon Tools app, allowed their beacon to be seen even though registering via this app (as expected) failed because it wasn’t a Eddystone GATT beacon. [Only Eddystone GATT beacons can be registered using the Beacon Tools App.]  We are not sure if this really caused the beacon to be registered or if it was just a case of ‘Have you waited long enough?’ (above).
  • What’s going on in the Android OS? There’s a great post on StackOverflow that shows how to use ADB (needs Android Studio installed) to enable logging. There’s also another post from the Nearby team on how to get the Nearby logging.

Getting Further Help

Log a Physical Web Issue or communicate with the Physical Web team via the Physical Web discussion forum. You can also create a bug report and send it directly to the Nearby Team.

Chrome 53 Arriving With Web Bluetooth

Chrome 53 currently being rolled out now includes Web Bluetooth. What was previously an experimental feature enabled by the chrome://flags/#enable-web-bluetooth flag can now be enabled for Chrome OS, Android M, and Mac via what Google calls an Origin Trial.

Web Bluetooth allows the browser to see and interact directly with Bluetooth devices. The idea is that it will allow such devices to be configured and controlled from the web browser. Imagine consumer or IoT devices that no longer need a native configuration app nor configuration over WiFi. Instead, the app can be written in Javascript, served from anywhere and even be a local html file. There are some technical level examples on GitHub.

In terms of beacons, Web Bluetooth allows these to be potentially configured via the web browser rather than via native iOS and Android apps. The Physical Web team has a page where you can configure Standard Eddystone Beacons that follow their new Eddystone Configuration GATT Service. We have tried this under Android Chrome 52 with our Sensoro beacons in Standard Eddystone mode and the beacons weren’t even detected. Let’s hope when Chrome 53 reaches us, such problems have become resolved.

There’s more information on implementing Web Bluetooth and the implementation status of Web Bluetooth across the various platforms.

How Do I Manage Physical Web Beacon URLs?

We have had some enquires how to manage Physical Web beacon URLs remotely, without physical access to the beacon. The answer lies in a previous post on Physical Web Getting Started Tips where we referenced a paper advocating the use of a URL shortener for web addresses over 18 characters. However, there’s a bit more to it than that.

First of all, the URL doesn’t strictly have to have 18 characters or less. Longer URLs can sometimes still fit in the beacon advertising data because the scheme (http part) and domain ending are encoded. See the Eddystone specification for more details. In most cases you don’t have to worry about the encoding as it’s the beacon management app that puts the URL in the beacon for you. In any case, you should be putting a shortener-generated URL into the beacon to allow it to be remotely changed in the future without re-configuring the beacon.

The next thing to know is that you shouldn’t use just any shortener. Commonly used URL shorteners such as goo.gl and bitly.com don’t allow you to change the URL. Instead, use a shortener such as tiny.cc or bit.do (the login versions of these services) that allow you to change the URL in the future.

For less dependence on a third party, more privacy of visitor stats and a better service level, you might consider a self-hosted URL shortener. Take a look at yourls.org that provides pretty stats and polr that provides an API that, if you are an app developer, you might use to allow users to manage URLs from within your app or other (web) interface.

We have used yourls.org for some of our test Eddystone beacons and it works well with Chrome/the Physical Web app including changing URLs.

One final thing to know is that, as mentioned previously, Eddystone URL only triggers on secure Physical Web URLs (https rather than http). However, it’s only the final redirected-to URL that needs to be secure and you can use tiny.cc or your own self-hosted URL shortener on a non-secure domain.

Why Doesn’t Chrome Detect My Physical Web/Eddystone Beacon?

We have a lot of enquiries asking why Chrome on Android doesn’t pick up some beacons. This is often despite enabling the Physical web in Chrome.
Even mobiforge had problems.

The reason is almost always because the pointed to URL doesn’t use https. For some reason, probably as a defence against Man in the Middle attacks, Chrome on Android needs the URL to be secure otherwise it won’t be triggered. Note that the Android Physical Web app and also Chrome on iOS don’t have this limitation.

The fact that so many people are confused and it’s inconsistent with Chrome on iOS suggests that the Google hasn’t thought through or communicated this aspect well enough.

UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.