We would like to use some configuration of the iBeacon , where the user's iPhone will advertise its services, but when the app is closed.
So when a user come across a hardware beacon, it will recognise the user's iPhone(as a beacon) without opening the app, and even connect to it .
I could find here many opinions about that, but i wonder if there are any news with the iOS8 ,and if there is a clear answer for that from Apple ?
A couple of points:
Bluetooth beacons, iBeacons included, are transmit only. They don't see or "recognize" other beacons or phones. The statement "when a user come across a hardware beacon, it will recognise the user's iPhone(as a beacon)" is not possible with the technology regardless of whether the app on the phone is in the foreground or the background.
iBeacons are supported on iOS devices with version 7.x and 8.x of the operating system. On all these versions, however, beacon transmission from the iOS device is only supported when the app is in the foreground. See here for details.
Related
I've a iOS 10 device in my work place and I got curious about it's bluetooth's weird behaviour. So.. I was playing around with my Android's Beacon simulator App and I noticed that every time I unlocked my IPhone and enabled the Bluetooth a new entry was immediately created in my android's near by beacon's list. Is there a reason for that?
UPDATE 1
- handoff disabled
- AirDrop disabled
- No open apps.
= still got a mysterious broadcast on my Beacon Simulator App.
UPDATE 2
Ok, I was digging into the subject and noticed that the iOS device is not being able to find near by devices in a standard bluetooth discovery.
In the other hand, near-by devices can detected the iPhone and when clicking on his entry in their result's list a popup for pairing shows up on Iphone's screen and as if it was magic the name of the device trying to pair shows up on the iphone's list that is always empty, in this case Huawei P9 but tested with a note 4.
I am the developer of Beacon Simulator. I just want to warn that the app is a Beacon simulator before all, not really a Beacon scanner. I added the scanning part because it was easier to do some tests, for the beacon copy feature and also for future developments.
What the scanner will show you is not necessarily a beacon, but any scannable Bluetooth Low Energy devices, connectable or not. Unfortunately, it is difficult to know if a device is connectable or not with the Android API, so the app lists everything.
Since the icon represents a standard Bluetooth logo, it means it is a signal not recognized by the app (here, it isn't an iBeacon nor AltBeacon nor Eddystone beacon). So either it is a non standard beacon, or simply a signal to advertise a possible connection to the device. When a connectable device broadcast its presence, the signal uses the same channel and protocol than the one used by beacons. A connectable device will advert itself as connectable, but as said, the Android API erase this difference, unfortunately.
So what you see is not necessarily a beacon, but maybe simply your iPhone broadcasting its presence as a connectable device. Maybe I should add some disclaimers in the app.
First: I have an iPad Air 2, and an iPhone 7. For further reading we estimate that the app is active and open on iPad and in background mode on iPhone. The app is exactly the same, even with same Bluetooth Service UUIDs and same DataLocalNameKey.
I want to write an app that can advertise a bluetooth service in background and is able to discover this service (optimal in background too). As I already read I can't use apples beacon technology cause there it's only possible to get scanning/notified by beacons in near in background (I tested this, works fine) but not to advertise. So I started to use CoreBluetooth as described in the mentioned SO answer cause there it's possible to advertise in background.
My app calls didDiscoverPeripheral method in CBCentralManagerDelegate on the iPhone (app in background), so it detected the iPad. The isAdvertising property of CBPeripheralManager on iPhone is true. But didDiscoverPeripheral is not called on iPad. I'm a little bit confused. One option is my iPad is not able to detect the iPhone anymore for some reasons or my iPhone is lying and it's not advertising.
So i thought I'm just a little bit of dumb and googled for "CoreBluetooth debug apps". I found Vicinity and AltBeacon. And with both apps the behavior is the same! If you background (press home/sleep button) the advertising app, the browsing app is not able to discover it anymore. If you open the backgrounded the app it will instant discover it. Both apps mention that its possible with them to broadcast in background.
Am I doing something wrong; is this behavior expected? Did I misunderstood the framework? Can you confirm this behavior?
To confirm this, the fastest way is to install Vicinity on two devices (you have to add the NSBluetoothPeripheralUsageDescription key to Info.plist) set one device to broadcast and press the home button.
This isn't anything specific to iOS 10 -- it's always been this way on iOS. On iOS, apps simply cannot send out standard Bluetooth LE advertisements when they are in the background. They have to be in the foreground to do this.
That said, there is limited support in iOS for apps advertising GATT Services in the background. This uses a proprietary technique that only works with other iOS devices that are looking for those services. (Because it uses a non-standard proprietary scheme, the same technique won't work for beacon advertisements, for example.)
Here's how Apple describes it:
...you should be aware that advertising while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is advertising while in the background:
The CBAdvertisementDataLocalNameKey advertisement key is ignored, and the local name of peripheral is not advertised.
All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them.
If all apps that are advertising are in the background, the frequency at which your peripheral device sends advertising packets may decrease.
Read more here: https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html
it was a bug in ios 10.0.(1) and partially fixed in ios 10.1
src: https://forums.developer.apple.com/thread/51309
I have read the docs about the BLE for iOS, and i could see that every device has its UUID instead of mac adress for the BLE.
My question ,in which there is no answer to on the docs, is- when you turn on the bluetooth on the device ( without opening any app) , so the device's bluetooth is on , what does it advertise then, and could I discover that device or get its UUID, while his bluetooth is on,but without any app that is open.
I am pretty sure that when the BLE is on, you can discover that device, or awake him, but I wonder what data can I get from him while its on without an app .
(same for Android.. )
iOS does not advertise any Bluetooth Low Energy services that are visible to another iOS device without an app running. Once an app advertises a service you will see additional services available - device information, time service, battery level.
If you are using different Bluetooth hardware to scan then you may see some advertisements without an app but the reported UUID of an iOS device changes every 15 minutes for privacy reasons - See this answer - Corebluetooth, How to get a unique UUID?
We have an existing iPad app that we are adding iBeacon transmitting capabilities to. I am unable to transmit an iBeacon signal. I won't provide the code at this point because I've also tested the Apple AirLocate example and the Radius Networks Locate iB app as a transmitter and in both cases the iPad won't transmit a beacon.
We tested with iPhone 5 devices and they can both transmit and range beacons.
What could be the issue with our iPad test device that it won't transmit? It can range beacons from the iPhones just fine.
BT is enabled. Location Services are enabled and approved for the apps in question.
Two likely causes:
The Proximity UUID of the iBeacon transmitter is not configured with Locate for iBeacon or Air Locate. Locate cannot see new iBeacons with unknown Proximity UUIDs. Even if the configuration is off by only a single digit, the iBeacon will be invisible.
Many users have reported recently that their phones are getting into a state where they cannot see iBeacons, and a reboot solves the problem. See here for more details.
How do you detect the iBeacon, actually?
I once encountered the problem that CLLocationManager#startMonitoringForRegion: did require a certain period of time, until the regions were updated and a region was ranged. So CLLocationManager#requestStateForRegion:...
In either way. What I first did to validate that beacons were emitting/sending correctly (not receiving): I downloaded a common Bluetooth Scanning-App and checked, whether the App is able to range the emitted beacon. Could you verify this at first? Maybe the iPad Air is sending correctly, but the receives do not range the beacon yet.
Can an iOS7 device act as an iBeacon and figure out when other iOS7 devices come in its range? Do those other iOS7 devices need to have Bluetooth turned on?
An iOS device with BluetoothLE can act as an iBeacon yes.
Check out the AirLocate example code at https://developer.apple.com/downloads/index.action?name=WWDC%202013#
Being an iBeacon doesn't give feedback about devices that come into range so you'd have to implement that yourself. ie you'd have to have the devices that detect the iBeacon then tell the iBeacon they'd seen it through some other means.
Yes, an iOS device can act as a beacon, from iPhone 4s and up (Bluetooth 4.0 required).
You publish a beacon by passing the dictionary from [CLBeaconRegion peripheralDataWithMeasuredPower:] to [CBPeripheralManager startAdvertising:].
Publishing a beacon will not give you any feedback on devices, you'll have to scan for others publishing a beacon.
As for backgrounding, you can not publish a beacon in the background, your app needs to be running in the foreground for that. Scanning is possible in the background.
Yes, an iOS7 device can act as an iBeacon. You can do exactly what you are suggesting if you have an app installed on all phones, and you also write a web service. This would allow phone A to see phones B and C when they are nearby:
Your app on Phone A acts as an iBeacon advertising its presence.
Phones B and C see this iBeacon, waking up your app to make a call to your web service reporting that they both see Phone A's transmission.
Your app on Phone A queries this web service, which returns a list of phones that see Phone A. In this example, the list includes Phones B and C. Your app updates its display with this list.
All phones would need Bluetooth LE, have it turned on, and have your app installed. They would also need internet connectivity to call the web service.
If you're not set on using iBeacons, this project uses Bluetooth LE to share an array of ids between nearby phones- SimpleShare
You could set an ID for the user of each phone, share them between the phones over Bluetooth LE using the SimpleShare project (even while in background mode), and then query a web service to find out more information about the user with that ID.
One point that didn't come out clearly from the previous answers is that in order for the publishing to work (for example in David's answer's Phone A) the application that started publishing must be in foreground.
From the Apple documentation:
While your app is in the background, the local name is not advertised
and all service UUIDs are placed in the overflow area.
As mentioned, an iOS 7 device can act as an iBeacon, so long as it Bluetooth LE technology.
To use iBeacon, you need iOS 7 or later, Bluetooth turned on, and a compatible iOS device:
iPhone 4s or later
iPad (3rd generation) or later
iPad mini or later
iPod touch (5th generation) or later.
http://support.apple.com/kb/HT6048