Category: Android

If you are considering developing Bluetooth LE on Android, you should take a look at Stuart Kent’s Android Bluetooth Low Energy Resources on GitHub. He provides lots of links to introductions, videos, libraries, guides, questions on Stack Overflow and example app source code.

If you need more information take a look at the Android section of the BluetoothLE Wiki. If you need to rely on background processing read Don’t Kill My App.

If you have upgraded to Android 10 then you will find you are asked whether particular apps, especially those using maps or Bluetooth, can use Location permission (all the time, only while using the app or Deny). Something like:

You will find that this screen appears, for each app using Location, at a seemingly random time. Why is this? Why do apps you haven’t just started suddenly ask for the permission? What are they doing? How should you answer?

The change of Android location permissions to include ‘only while using the app’ is part of Android 10. For app architectural purposes, some apps get location or Bluetooth scan in an Android Service that runs in background. This Service can be started and stopped by the Android OS according to whether the OS needs resources and also when an app is upgraded. The starting of the Service might cause it to get location or do an initial Bluetooth scan, as part of startup, even though the app isn’t going to use this information. These things used to be transparent but now have the knock on affect of causing the OS to ask for the first-time permission seemingly at a random time.

If, for example in the above BBC Weather app, you need the app to show the latest weather for a location on a widget or otherwise use location-related data in background then select ‘Allow all the time’. Otherwise select ‘Allow only while using the app’. Beware of selecting ‘Deny’ as it’s likely it might cause the app to malfunction in some way.

Our empirical experiences are that Android 10 background restrictions do actually noticeably improve battery life, unlike previous Android ‘Doze’ and App Standby restrictions that seemed to create pain and no gain.

A large number of Bluetooth LE apps don’t work on Android 10 because of a bug in permissions in Android 10 (API 29). This affects nearly all manufacturer apps used for setting up beacons or using Bluetooth LE devices. The only apps that will work are those that have very recently been developed and target Android 10.

Android 10 introduced the requirement to have the ACCESS_FINE_LOCATION permission when targeting (written for) Android 10. Older apps targeting previous versions of Android should not have been affected but, due to a bug, they no longer work.

App developers can make their app work by adding the permission. Note that the permission must also also be prompted for from the user using the request permission mechanism. Alternatively the user can set manually via Settings -> Apps & Notifications -> Your App Name -> Permissions.

If you are a user and need to use a particular app then you will need to use a device having an Android version prior to Android 10. Alternatively, use the iOS app version if possible.

This issue has been has been detected by us on build QP1A.190711.020 and QP1A.191005.007.A1 and is perhaps related to issue 136774949. We expect it to be fixed in the future via an Android OS update.

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.