Cordova, previously called PhoneGap, is a mobile cross platform development tool that uses web pages and Javascript.
Don Coleman of Chariot Solutions maintains the open source cordova-plugin-ble-central custom plugin (blue area in above diagram) that provides a Bluetooth API for scanning, connecting to service characteristics, reading and writing values and characteristic change notification. Examples are provided.
The recent updates provide support for new permissions and API changes in Android 10+. It’s great to see the plugin updated because the problem with many tools and libraries is that they rarely keep up to date with changes in the underlying iOS and Android APIs.
There’s a new app for iOS called Stepping In & Out that uses iBeacons to remind you when you move into or out of an area containing a beacon.
The source code is available on GitHub. It provides an example how to create an app using Swift that triggers when going into and out of zones. This can also be used for commercially oriented applications.
Flutter is Google’s UI toolkit for building native applications for mobile, web, and desktop from a single codebase. There are plugins that add functionality to Flutter. One such plugin is the beacon_plugin that makes it easier to scan and range iBeacons on iOS and Android. The plugin is open source on GitHub.
We often get asked the question which beacons are compatible with iOS and Android. All beacons, whether iBeacon, Eddystone or sensor beacons can be used with iOS and Android. The compatibility is achieved through the implementation of common Bluetooth standards on these mobile platforms.
However, there are some caveats:
Android only supported Bluetooth LE as of Android 4.3. Older devices can’t see Bluetooth beacons. Over 95% of users are on Android 4.3 or later so most people can see beacons.
Apple iOS doesn’t have background OS support for Eddystone triggering. While iOS apps can scan for, see and act on Eddystone beacons, the iOS operating system won’t create a notification to start up your app when there’s an Eddystone beacon in the vicinity.
Rather than beacons being compatible with iOS/Android, we find that there are more problems with particular Android devices not seeing beacons, when in background, due to some manufacturers killing background services.
On iOS 14, Apple has changed the permissions required for iBeacon region ranging and monitoring. There’s a new Precise Location permission that needs to be set to ON for the app to continue to work. Apps that granted location permissions prior to iOS 14 default to Precise Location ON after upgrading so as not to break old code.
Apps should now detect if Precise Location is enabled. Apple has unfortunately deprecated the class function authorizationStatus(). The best way of determining whether you can detect iBeacons is to examine the location accuracy.
The key thing about this research is that it uses iOS rather than a beacon to advertise iBeacon. The system allows the entire team to determine the location of other members, perform location based tasks, receive announcements and communicate via instant chat.
iBeacon Team Management Screens
The paper contains some useful analysis of accuracy of distance measurement on distance, interference, measured power and obstructions:
Effect of iBeacon distance accuracy with obstructions
Effect of iBeacon distance accuracy with presence of another iBeacon
Effect of measured power variation on proximity and accuracy
Effect of obstructing objects on RSSI and Accuracy
On iOS it’s only possible to advertise iBeacon if the app is in foreground:
The major limitation of the proposed app is battery drainage while keeping the app active all the time in the foreground
A more practical system would have been implemented by having the users carry a separate wearable beacon. This would have allowed presence to be detected when the app isn’t in foreground and there wouldn’t have been a problem with excessive iOS battery use.
Nordic Semiconductor, the manufacturer of the System in a Chip in beacons and other smart devices has a new iOS CoreBluetooth Mock Library. The library allows an app to be used with dummy Bluetooth calls rather than real APIs.
The main use is for automated testing. If testing code on a server or test bed you want tests to run reliably and predictably so that you can get a pass or fail indication. Replacing the wireless part of the app allows other parts of the app to be tested.
The library also has other uses:
Taking screenshots without setting up a particular physical scenario
Developing code quicker through better repeatability
Developing code without need of a physical phone or tablet
Developing code when a Bluetooth peripheral isn’t available yet and/or is still under development
A caveat is that this library is for CoreBluetooth and not for CoreLocation. The former is intended for communication with devices that are not iBeacon. Apple forces you to use CoreLocation to detect iBeacons because they don’t provide the standard Bluetooth advertising via CoreBluetooth when seeing iBeacons.
The CoreBluetooth Mock Library is useful for detection of non-iBeacon Bluetooth devices such as fitness trackers, health monitors, Eddystone beacons and sensor beacons.
We recently started selling beacons that can advertise LINE. This post explains LINE advertising with information on the packet format.
LINE Beacons are used with the LINE messenger service that allows users to send text, video, and voice messages on smartphones and the PC. It’s currently available in Japan, Taiwan, Thailand, and Indonesia. LINE have iOS and Android developer APIs that allow you to hook into the LINE service and include LINE services in your app. The LINE beacon allows your LINE code, called a bot, to receive beacon webhook events whenever a LINE user enters the proximity of a beacon. The beacons allow you to customise your bot app to interact with users in specific contexts. There’s also a beacon banner feature, available for corporate users, that causes a banner to appear in the LINE messenger app when it comes close to a LINE beacon.
LINE Bluetooth Advertising
Unlike iBeacon, LINE Beacon packets have a secure message field to prevent packet tampering and replay attacks. The secure data is 7 bytes long containing a message authentication code, timestamp and battery level. Secure messages are sent to the LINE platform for verification.
Generating LINE Advertising
LINE recommend LINE beacon packets be sent at a very high rate of every 152ms. In addition, LINE recommend advertising iBeacon (UUID D0D2CE24-9EFC-11E5-82C4-1C6A7A17EF38, Major 0x4C49, Mino 0x4E45) to notify iOS devices that the LINE Beacon device is nearby. This is because an iOS app can only see iBeacons when in background and LINE beacons can’t wake an app.
We observe that the high advertising rate and concurrent iBeacon advertising aren’t battery friendly and the beacon battery isn’t going to last long.
Bluetooth SIG have updated their Introduction to Bluetooth Beacons. It provides advice and examples how to use beacons from iOS, Android and Raspberry Pi using the respective Bluetooth APIs.
The examples show how to scan for AltBeacon which is unusual because most people will want to scan for iBeacon because AltBeacon is sent by very few beacons. This is less of a problem on Android and Raspberry Pi where slightly modified code can be used. However, on iOS, the suggested APIs won’t work for iBeacon because Apple removes the iBeacon data from the Bluetooth scan response data to force you to use the iBeacon specific APIs which aren’t mentioned in the guide.
