New Android Physical Web App

Google has a new Android version of the Physical Web app. The new app offers blocking (swipe left), starring in list view and sharing. Starring causes items to be shown at the top of the list and a notification to be shown in the lock screen.


The Physical Web is more than just regular Bluetooth Eddystone Beacons and in a wider sense it about anything sending out a URL. Google have now added Wi-Fi Direct , mDNS, SSDP and FatBeacon.

Fatbeacon is an interesting experimental Bluetooth beacon that has the web site title, description and web page (<10Kb) inside the beacon. This will make beacon discovery very fast and not need an Internet connection as the app doesn’t need to go to the Google proxy nor a target web site.

The app’s sharing feature isn’t, as you might expect, a facility to share a discovered URL. Instead it’s an Intent based programming feature that other Android apps can use to share a URL to the Physical Web app that will shorten the URL and broadcast it via the phone’s Bluetooth LE. This reverses the discovery so that the device (or user) is part of the Physical web. It also introduces the possibly of dynamic (changing) URLs controlled by another app.

The release notes for the Android app can be found on GitHub.

Reverse Engineering iBeacon and Eddystone Bluetooth GATT Services

For some of our beacons such as the Axaet and Sensoro product ranges the manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programatically the UUID, major and minor and must rely on the manufacturer’s configuration app or, in the case of the Sensoro beacon, their SDK. While this of no consequence for the majority of uses, more ambitious scenarios might want directly access the Bluetooth GATT services.

Uri Shaked has written a great article on Medium on how to Reverse Engineer a Bluetooth Lightbulb. His method uses the developer logging in Android 4.4 and later to allow inspection of the Bluetooth packets and hence the Bluetooth Services and Characteristics that are being used. This method can equally be used with iBeacon and Eddystone beacons to reverse engineer the Bluetooth GATT information.

Should I Use the Manufacturer iBeacon SDKs?

Some manufacturers offer SDKs to allow programmatic access to their beacons from iOS and Android. Most SDKs tend to be poorly implemented/documented, tie your code into using that particular beacon and rarely get updated to use newer platform APIs. Instead, when you can, we recommend you use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type. Alternatively, use an independent 3rd party library such as Radius Network’s iOS SDK and the EasiBeacon Android library.

However, there are some cases where you must use the manufacturer library. This is usually in cases where there the app needs to connect with the beacon (as opposed to only view advertising scans) to perform beacon specific things. The Sensoro SDK is an example where their private protocol (to prevent squatters) and sensor information can only be obtained via their SDK.

Which Beacons are the Most Compatible?

We get asked this a lot. First of all, ALL beacons, whether iBeacon or Eddystone, are compatible with iOS and Android. There are a few ‘tracker’ type Bluetooth devices around that don’t transmit the right Bluetooth header and can’t be seen on iOS but we don’t sell those.

Almost all beacons are slight derivations of a few standard circuit designs and firmware provided by Texas Instruments, Dialog and Nordic who produce the System On a Chip (SoC) inside beacons. Hence, they all transmit to Bluetooth standards. The main area that can differ is the Antenna and PCB layout that can lead to different radiation patterns. The ability to detect a beacon isn’t usually affected and differences manifest themselves as differing beacon signal strength (hence range) and stability.

Apple certify beacons under the MFi scheme mainly to ensure they have settings, for example 100ms transmission, that work well on iOS.

The main areas where beacons differ is not in compatibility but in physical characteristics such as battery size and waterproofing that are to be found as categories at the left hand side of our store.

One thing people don’t realise is that there are more problems with phone compatibility than beacon compatibility. Over time, we have discovered about 5% of our customers have problems getting the Manufacturer’s configuration to app connect to beacons on Android. To be clear, this is only when apps need to connect (to change settings) as opposed to only scan for beacons so this doesn’t tend to be a problem (for end users) once everything is set up.

To answer the question, Bluetooth standards are such that all beacons can be seen on most phones and compatibility isn’t an issue. Problems we have seen have been related to phones rather than beacons. We have never had a beacon returned to us because it’s incompatible. However, if you want additional assurance then choose an Apple MFi certified beacon.

Where to Start with Android Beacon App Development?

We were recently asked where one should start when doing beacon development on Android. Here are some pointers:

  • The Android documentation is very good these days.
  • Avoid the libraries produced by the beacon manufacturers. They tend to add little value and tend to be poorly documented. You can achieve everything with the Android APIs (The same advice goes for developing on iOS). The only exception is connecting via GATT to Sensoro beacons where the Service/Characteristic information isn’t publicly available and hence you have to use their SDK.
  • Take a look at the easibeacon library for how to do scanning,
  • The TI SensorTag library has some great examples of how to connect via GATT.

Need help? We provide beacon app development services.

New Tally App

We have just announced our new Tally app that can be used to monitor people or things that have beacons attached to them. It’s suitable for counting groups of people, for example, tour groups and educational classes or finding the wareabouts of things such as stock items, machines or vehicles. It’s also suitable for lone workers and evidence based working.

The app is csv driven in that you can import and export beacons of interest with given names and groups. You can then start/stop monitoring sessions on all beacons, all beacons declared in the app or just beacons in a named group. The results make up sessions of detected beacons that can, again, be exported to csv files. You can also choose to add arbitrary (prompted for) information to a session, for example a description of the location, that you might later use for analysis.


The power of the app comes from the fact it works in background and can also work unattended, stopping and starting sessions automatically during idle time when detected the beacons haven’t changed. The resulting session csv files can be automatically sent via email or ftp, with queuing for failed sends.


Here are some examples of how Tally can be used:

Managing Tour Groups: You might set up an Excel file with named grouped members that’s imported into the app. Give each a beacon and set the app to show those beacons that are missing. Start a session and the app will give you the names of those people missing.

Class Registration: Give each student a beacon. Import the student names from Excel and/or dynamically add the named students one by one by allowing the app to add the nearest beacon. Set the app to automatic sessions and email sending. The app will regularly report who is in the room. The app will also send the group if this has been set for the student.

Managing Stock: Put beacons on large or valuable stock items. Import the items from Excel or add manually in the app auto-filling the beacon uuid, major and minor for the closest beacon. Set the app to prompt for extra information at the start of a session. When you need to do a stock check, start a session, enter the room name or area and walk around the room. Stop the session and export the detected beacons. You might also set the minimum signal strength for detection so as to filter out beacons in adjacent rooms.

Evidence Based Working: Some jobs require workers to prove they have been at a particular place at a particular time. Site beacons at the places that need to be visited. Import the named place details and/or set them manually in the app (you can also export this data). Set the app to unattended use and FTP upload and give to the worker. You will receive where the worker has been, with named locations via FTP.

Testing Beacons: Some rollouts, for example at museums, need to regularly walk-test the routes to make sure the beacons are working and battery strength is sufficient. Set the app to detect all beacons and enable the battery monitoring. Walk the museum and all the beacons, with their battery levels will be recorded for the session. Export to Excel, send via email or share the output session file.

Learn more about Tally

Beacons, Google Instant Apps and Nearby Notifications

There have been some interesting announcements from Google I/O 2016. The first is Instant Apps that will allow apps to be run from a URL without installation. Once they have been used, they will disappear and not appear in the usual applications list.

This should integrate well with Eddystone URLs/The Physical Web where a place/item might advertise a URL that runs an Instant app. This gives more possibilities than just providing a fixed landing page, possibilities that particularly make use of things a web page can’t – for example deeper things on the phone such as sensors, contact information and calendar information.

The other interesting announcement is Google Nearby Notifications. This is where you can associate a URL, App intent (with URL fallback) or direct app install with an Eddystone beacon. This is different and separate to Eddystone-URL. You use the Tools app and/or the Web Based admin to set up attachments for your beacon that describe the URL, App intent or install. Anyone can see that data and act on it when they use an API or component, for example Place Picker, that uses Google Nearby. The key thing here is that Google trying to sell the one beacon, many uses idea. Many people, not just yourself (as developer) can act on your beacons and that can enable new scenarios and possibilities.

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.

Which Beacons are Compatible with iOS and Android?

We often get asked the question which beacons are compatible with iOS and Android. All beacons, whether sold by us or purchased elsewhere can be used with iOS and Android. However, there are some caveats:

  • Android only supported Bluetooth LE as of Android 4.3. Older devices can’t see Bluetooth beacons. As at the time of writing this, the Google Dashboard shows that 95% of users are on Android 4.3 or later. Most people with recent Android devices can see both iBeacon and Eddystone beacons.
  • Apple iOS doesn’t have background support for Eddystone. While iOS apps can scan for, see and act on Eddystone beacons, the iOS operating system isn’t going to start up your app when there’s an Eddystone beacon in the vicinity.

Also see Which Beacon’s Are the Most Compatible?