Clearing the Android Bluetooth Cache

In our post on compatibility we explained how Bluetooth LE connection problems are more likely to be with Android rather than the devices (beacons) with which they are communicating.

If you are experiencing such problems you can try clearing your Android Bluetooth cache:

Settings
Select Application Manager
Display system apps (swipe left/right or choose from the menu in the top right corner)
Select Bluetooth
Select Storage
Tap Clear Cache
Restart the phone

Note that these menus are not available on the latest versions of (vanilla, non-OEM) Android because Google has unhelpfully removed access to system apps.

Bluetooth LE Developer Questions

Here are the top questions we get asked as a Bluetooth LE developer:

  • For apps, can the app work without Bluetooth and location on?
    No. There’s no special OS mechanism on iOS nor Android that uses Bluetooth LE without the user having Bluetooth and location on. Many users leave Bluetooth and location on to allow ease of use with cars and audio headphones. Location is also usually one due to use with maps.
  • How does leaving Bluetooth on affect battery life?
    Bluetooth is no longer drains the battery as was the case in the early days of smartphones. It can be left on with negligible extra battery use.
  • What’s the maximum range?
    The range depends most on the Bluetooth device to are connecting to. Most devices, running on battery, work 50m to 100m. Devices with larger batteries, running from mains or USB can work up hundreds of metres. We have a device that works up to 4000m.
  • What SDK should be used?
    Most, but not all, SDKs and 3rd party libraries tend to be poorly implemented/documented, tie your code into using a particular beacon and rarely get updated to use newer mobile platform APIs. We recommend software use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type and readily able to be updated when the mobile platforms themselves are updated.

Read about our Bluetooth LE Software Development Services

SensingKit for iOS and Android

There’s a 3rd party SensingKit for iOS and Android that came out of the research, SensingKit: Evaluating the Sensor Power Consumption in iOS devices (pdf), by Kleomenis Katevas, Hamed Haddadi, Laurissa Tokarchuk of Queen Mary University of London.

While the SensingKit supports beacons, it only supports them for detecting proximity. The various sensor beacon variants are not supported. SensingKit is best used when you want the smartphone, not the beacon, to do the sensing. It’s useful when you want to mix smartphone sensing with beacon proximity sensing.

In most cases it’s best to use the native Android and iOS SDKs.

Read about our Bluetooth LE Development Services.

Android Physical Web App Removed from the Play Store


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


Google has removed the Android Physical Web app from the Play Store. This provided a way of scanning for Eddystone beacons without relying on the built-in Android Nearby functionality. As previously mentioned, the Google Physical web team was disbanded. Google have now removed the app, presumably because there’s no-one to maintain it in tandem with new versions of Android. Here’s the final Android Physical Web APK if you wish to side-load the file.

The iOS Physical Web app is also no longer available. The iOS version wasn’t written by Google and has recently been taken over by the non-profit Physical Web Association

iBeacon App Mechanism

People often come to us with the wrong impression how iBeacon apps can work. They think an app can sit in the background and suddenly come to the foreground when an iBeacon is detected. If you think about it, no 3rd party apps work like this, taking over your screen, and for good reason. It’s seen as intrusive by users and both iOS and Android prevent this. Instead, apps need to show a notification which, if tapped on, goes to the app or a screen within the app.

On iOS, apps don’t actually do the detecting of beacons. iOS detects beacons with ids that have been pre-declared by the app. When an app isn’t running, iOS starts the app for only a short time to allow it to show a notification.

On Android, prior to Android 8, you could have a background service scanning for beacons. However, Android has become more like iOS. Newer Android ‘Doze’ and background restrictions mean you have to use newer Bluetooth APIs to detect beacons when the app isn’t running.

Hybrid vs Native Apps and Cross Platform Tools?

When creating apps to discover beacons, there’s often the temptation to use cross platform tools to create both iOS and Android apps at the same time. Such tools are often based on web (WebView screen) technologies and Javascript.

The first problem you will encounter is that few of the cross platform tools support Bluetooth. Even if they do, they don’t support it to the degree required to implicitly use the latest iOS and Android Bluetooth APIs. This is one of the main problems with cross platform in that functionality always trails the underlying native OS functionality.

Another problem is that there’s no one Android browser upon which the WebViews are based. Niels Leenheer has a (old but still relevant) set of slides that explains how browsers vary across Android versions, devices and phone manufacturers. The consequence of this is that getting any non-trivial WebView-based app to work across many device types is very difficult.

The next problem is functionality. It not only lags the underlying OS functionality in the use of APIs but also features are absent. This often requires some native coding which causes the app to become more of a Frankenstein creation with consequent unexpected complexities.

For best performance and OS look and feel you have to use native development. It’s possible for hybrid apps to look and feel like Android and iOS but it takes a lot of effort due to the previously mentioned browser fragmentation. It’s possible to get near-native app performance by replacing (bundling) a better Javascript interpretor. However, these extra complexities are what you were trying to avoid by using the cross platform framework in the first place.

If the above doesn’t persuade you, even Mark Zuckerberg regretted using web technologies in apps in 2015. This didn’t stop others trying. There are some detailed posts on Medium explaining how AirBnB is moving back to native development and how the difficulties are not just technical but also organisational.

If you are writing apps or getting apps written we recommend you save yourself some grief and write them using native code.

Read about our development services

Devices That Can See Beacons

When people think about beacons they often imagine them being detected in smartphone apps. This post explores other devices that can also see beacons allowing for different interaction possibilities and new scenarios.

Apps – Apps aren’t limited to just smartphone apps. You can run apps on TV boxes that run Android. Just make sure they have Bluetooth 4.3 or later.

GatewaysGateways are small single pupose devices that look for beacons and send the information on via MQTT or REST (HTTP) to any server. This allows web servers to see beacons.

Desktops and Laptops – PC/Mac devices with built-in Bluetooth or dongles can see beacons.

Walky Talkies – Motorola manufacture the MOTOTRBO range of digital radios that can detect iBeacons and show their location on a map.

Raspberry Pi – This has Bluetooth and can be used to detect beacons.

AndroidThings – This special IOT version of Android can run apps that detect beacons and store and/or forward information to other devices.

ArduinoArduino boards often have Bluetooth and can do things based on the presence of beacons.

Pixl.js – The manufacturer of the Puck.js also supplies a device with a screen that can detect and interact with beacons.

Single Board Computers (SBC) have an advantage over gateways in that data can be cached locally when there isn’t an Internet connection. They can also make decisions locally and send out alerts directly rather than having to rely on a server. This is so called ‘IoT Edge’ computing.

Bluetooth 5 in Smartphones

Last February we wrote about the progress of Bluetooth 5 in recent smartphones. A few months on and Nordic Semiconductor, the company that produces the System on a Chip (SoC) used in most beacons, has a new blog post on Bluetooth 5 in Smartphones and how we are about to experience a tipping point in support for Bluetooth 5.

The final observation from the article is:

Even if sticking to previous incarnations of Bluetooth may look like the right choice, the marketing power of Bluetooth 5, regardless of whether it’s needed or not, is likely to help companies differentiate products and increase sales.

This is true. Some companies currently claiming Bluetooth 5 support in products don’t actually use Bluetooth 5 yet but instead offer an upgrade path to Bluetooth 5.

Beacon Programming Examples

We have some new documentation for our AnkhMaway customers*. In the Ankhmaway Technical Area we have two new Android examples on:

We also have a new user guide for the iB001W rechargeable wrist beacon.

* Password protected – only available to customers who have purchased products.