I want to use an emulator to "pretend" to be in the presence of a beacon given a UUID, major and minor.
I understand that emulators themselves don't directly support Bluetooth but is there any way to inject a Bluetooth device into the list of devices the emulator sees?
Does there exist an Xposed Module or some sort of root that can adhere to this behaviour?
Standard Android emulators provide no way to simulate Bluetooth detections, so this is not possible at an Android API level.
If you use the open source Android Beacon Library, however, it does provide a BeaconSimulator (See here ) Interface so you can inject beacon detections when using an Android Emulator.
To do this, simply create a new class that implements this interface, construct an instance and then register it like this: BeaconManager.setBeaconSimulator(myBeaconSumulator)
After doing this, your app will detect any beacons in the list returned by your myBeaconSimulator object’s getBeacons() method when your app is running in debug mode on both Android Emulators and physical Android devices.
Related
I am developing an app that controls a product's operation. The communication is via BLE. My configuration is
App - Peripheral (iOS, Android)
Product - Central (uses Laird BT900 module)
iOS as a peripheral works fine (pairing and bonding) ; Android PIN pairing works fine, but subsequent bonding (or reconnect when in range) there are a lot of issues and termination of connection. I am using the supported list of devices for Android BLE and I also understand that there are many known issues that come with different manufacturers/chipset vendors
The issue I am getting is, as seen by nrfConnect, is with descriptors. Android app doesnt show descriptors when seen in nrfConnect whereas iOS shows. I do not know what is the difference
Is it a common practice to use a phone as a peripheral ? Or is it a risk - because this is a medical device.
Are there any best practices for Android as a peripheral ?
I have following back up plans in case Android issue is not resolved. I think following would work on any BLE supported phones without having any issues with the variability.
Plan A : PIN pairing on every connection with the product. This is the most secure and most annoying
Plan B : Implement just works pairing with a app layer password before taking control of the product.
Question : Is just works safe and encrypted ? Is it snoop-safe or MITM-safe ?
Thanks in advance!
A few thoughts from your questions:
1a. (From my Android experience) I think its uncommon to have the phone be the peripheral. To my knowledge all iOS devices support peripheral mode but only a very small subset of Android devices are able to support it. I say this because I've been experimenting with BTLE beacons using the AltBeacon library. From this work I have discovered that only certain Android phones can broadcast BTLE advertise packets. Given that BTLE advertising is the first step in initiating a BTLE session I imagine that this prevents many Android phones from being compatible with peripheral mode.
If all of your users can use an iOS device, then you're set, otherwise this may be a problem.
1b) I can't speak to the specific risk of using a mobile device with your medical device, that depends on what the medical device is doing and how you're using the mobile app.
2) See 1a
3) The specific encryption scheme you used is also based on your product's risk profile. I would say that Just Works is not an ideal solution. The just works pairing process is not snoop-safe and can be re-initiated via a MITM. Other than that I can't speak to the strength of BTLE encryption.
I have a BLE thermometer and I'd like to record the data from it as the monitoring application (available for both Android and iOS) that comes with it doesn't do it, it merely displays the data on the screen for a limited time.
I tried all BLE apps on both Android (I have a Nexus5 with Android 4.4) and iOS 7.1 iPad with but, while some discovered the device, none of them could display any data because all try to connect to the sensor whereas the sensor returns 0 for kCBAdvDataIsConnectable.
Is this possible? It must be because its own app does it, but I'm not too familiar with BLE and I may be missing something. I was surprised that none of the apps in the App/Play store had the feature of "listening" what a device sends without connecting. But then again, I'm not very familiar with BLE.
A few pointers are appreciated.
I've been playing with the Bluetooh sample from the Xcode RFCOMM_SPP which is what would do the job for me so I modified it but the discover devices does not pick a few simpler SPP devices(like a GPS)
I had a similar issue when doing the Android version and after digging I found out if I set up a proper UUID manually I'm on easy street and that got me rolling there really cool
Now back to the MAC I'm trying to see if the same process can be applied I see they have this IOBluetoothSDPUUID which picks a pre-cooked UUID, my guess is that if I do there what I did in Android I'd be able to see and interface with the GPS.
Is it possible to set a UUID manually like adding it to the h files? Or is it blocked for "Made for Apple" devices like in the iPhone?
Are you programming for the MAC or iOS devices (iphone / ipad )
Bluetooth SPP profile is not supported (publicly) on iOS devices.
see this http://support.apple.com/kb/HT3647?viewlocale=en_US
So if you want to do something custom on these devices using non public interfaces, the only way is joining the MFi program
I want to know if the developer team which made the emulator have some information to make bluetooth work in the Android emulator, indicate some links about it, if they have some date for release or if they'll make it works in the future.
as far as I know there is no support in the emulator for bluetooth. And I will have to teach android and bluetooth in some classes. And the students will need to code stuff and test (guess it) in the android emulator.
So I came up with a bare-bone reimplementation of the android bluetooth API on top of tcp. You can find it on here on github.
Basically, you run a tcp-server on your machine, and the emulators will connect through it.
Instead of using the classes in the package android.bluetooth, you just need to use the classes in the package dk.itu.android.bluetooth (and other 2 little modifies).
As for now it supports:
switch on/off the "radio"
discovery devices (only other android emulators)
creating bluetooth services
connecting to bluetooth services
It's not much, but until we got some more from the android guys, I guess there is nothing else around.
Hope it'll be useful, cheers!
The documented bluetooth limitation appears inconsistent with the qemu -bt option. So, how is bluetooth enabled in the emulator so the -bt options can be used, or at least to know that bluetooth is supported?
The target/board/.../BoardConfig.mk having "BOARD_HAVE_BLUETOOTH := true" doesn't provide a bluetooth icon or enable bluetooth. So, how do we turn on bluetooth on the android qemu emulator?
What does it mean that bluetooth is not supported given the -bt option for emulating USB devices that were provided in 2008? The post and limitations are outdated.
The functional limitations of the emulator include:
No support for placing or receiving actual phone calls. You can simulate phone calls (placed and received) through the emulator console, however.
No support for USB connections
No support for device-attached headphones
No support for determining network connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insert/eject
No support for Bluetooth
http://developer.android.com/tools/devices/emulator.html#limitations
I'm trying to register a midlet for push registration, in order to wake up from a bluetooth connection.
The requested behavior is that the application will wake up when a car's kit (hands free) will be in the range of the device.
Is it possible at all?
If yes, how should it be done?
Thanks in advance,
I can confirm that it is possible to wakeup a MIDlet in Nokia Devices trough a registered service in the push-registry.
The registration can be defined in the JAD (static registration) or dynamically in the code.
Nokia phones S60 3ed and up and S40 3ed should support this functionality, on other phones (sony,samsung,motorola etc..) I didn't find this feature working.
Google this JAD attribute: MIDlet-Push-1
Good luck!
I don't think it's possible to start up a midlet when it comes into range of a device, even with Bluetooth push registry compatibility (were you to find a handset supporting it).
Your best bet might be to have a midlet running in the background, constantly checking which devices are in the vicinity. When it discovers your hands-free kit, you could bring it to the foreground (if the handset supports it; this is usually achieved by Display.setCurrent(null) for background, and Display.setCurrent(<Displayable instance>) for foreground).
JSR 82 provides the functionality you need.
Beware though, this constant Bluetooth polling will drain the device's battery!
This is advanced stuff. Nice.
While this can be available on mobile phones according to the JSR-118 and JSR-82 specifications, I suspect not many handset manufacturers have actually implemented it.
Symbian provided a TCK-compliant reference implementation for Java BlueTooth Push to its licensees but testing it is a nightmare and I don't know whether either Nokia, Motorola or Sony-Ericsson actually included the functionality in a phone.
My best guess of Symbian phones to try this on: Nokia N95, Sony-Ericsson P990 or W960, Motorola Z8. I would also advise trying on as recent a Bluetooth-enabled non Symbian Sony-Ericsson phone as you can find.
If you find a handset specification that actually says it supports J2ME BT Push, you then need to check whether that is supposed to work using RFComm, L2CAP or both. I don't know what your car kit uses.
As far as writing Java code to use Bt push, you can start by reading the example code in the 2 JSRs and the J2ME SDK from Sun Ltd.