Category: Android

Bluetooth MAC Randomization Can Be Defeated

The Register has an article Brilliant Boston boffins blow big borehole in Bluetooth’s ballyhooed barricades: MAC addy randomization broken.

Beneath the hyperbolic alliteration is some research (pdf) that Bluetooth MAC randomization isn’t foolproof. Researchers have found that similarities between the non-MAC information in advertising allows devices to be uniquely identified:

“What is perhaps even more concerning, say the Boston Uni trio, is the message Bluetooth vendors are putting out to the public when they advertise Bluetooth LE as being an untrackable standard.”

In actual fact, very few vendors do MAC randomization. The majority of beacon manufacturers don’t because the whole idea of a beacon is that it can be identified via MAC address or iBeacon id. For the same reason, most Bluetooth accessories don’t as they want to be identified via apps. Android smartphones don’t do MAC randomization but iOS and Windows 10 do to improve end-user privacy. It’s mainly iOS devices that will be moving around and possibly tracked in-store or on-site via the ‘vulnerability’ described in the paper.

Android WiFi Direct via Bluetooth

A problem with many IoT projects is the need to connect the device to WiFi. It’s a ‘chicken and egg‘ situation in that you need to connect to the device in order to set the WiFi settings but you can’t connect because you aren’t WiFi connected. This is usually solved in one of two ways. The first relies on a WPS button on the WiFi router which sets it into a mode where it will accept a new device without the user having to enter or select anything. Security flaws in WPS and the possibility of anyone pressing the WPS button mean this isn’t a great solution for IoT applications. The second method involves the IoT device itself acting as a WiFi router in ‘station mode’ while the user on a phone, laptop or other device connects and uses a http web interface to set the WiFi settings and reboot. Upon reboot, it’s no longer in station mode and connects to the assigned access point. However, users need simpler mechanisms.

Android used to support WPS but this has been deprecated in favour Wi-Fi Easy Connect. The latest Android Q documentation explains that the Wi-Fi Direct connection information (a URI) needs to reach the device somehow such as through a QR Code scan NFC receipt or a Bluetooth scan. Hence, it’s possible for an unprovisioned device to be scanning for a particular beacon that provides a connection URI that’s used for provisioning the WiFi. This allows retailers’ Android apps or Android IoT devices to easily connect to location-specific WiFi.

The API mentions that Easy Connect does not require Location or Wi-Fi permissions which is a bit misleading. It will need the Location permission if you use a Bluetooth scan to provision.

Bluetooth Low Energy now in Amazon FreeRTOS

Amazon has recently announced support for Bluetooth Low Energy in Amazon FreeRTOS. Amazon FreeRTOS is an IoT operating system for microcontrollers. Support for Bluetooth LE allows you to see Bluetooth devices and extract sensor data. Amazon’s implementation also allows you to subscribe to MQTT topics over Bluetooth Low Energy through an iOS or Android mobile device.

There’s an example how to Perform OTA Updates on Espressif ESP32 using Amazon FreeRTOS Bluetooth Low Energy. It shows how to connect Amazon FreeRTOS devices using Bluetooth Low Energy to AWS IoT Core via Android and iOS devices.

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