I am porting an app which is already on Google Play to Nokia X. I removed all unnecessary resources to keep the installation file small. I want to prevent users from using the app on other devices and having a bad experience since the resources for higher density (xhdpi) or bigger screens (tablets) are no longer available.
Currently, I don't have access to a real device, and the code below only produces "unknown" as the manufacturer on the Nokia X device emulator.
My Question: What is the manufacturer of all three Nokia X devices, or is there a better method for identifying such a device?
if (!"nokia".equalsIgnoreCase(android.os.Build.MANUFACTURER)) {
// do something
}
The android.os.Build.MANUFACTURER is "Nokia" in all three announced Nokia X devices, so your code is correct.
Barring physical access to a device, I still recommend double checking your logic with a Nokia X device in Remote Device Access: http://developer.nokia.com/resources/remote-device-access
As pointed before by viviaino, the device manufacturer is "unkown" when running over a Nokia X emulator(AVD), it is needed to run a remote device or real Nokia X device to check the current manufacturer.
Related
When performing a BLE scan using startScan(onFoundBLEDevice, onBLEScanError). First, is the parameter sent to onFoundBLEDevice a single device or is it a list of devices? And if the answer is "single device" what happens when there is more than one BLE device in the local vicinity when performing the scan?
Secondly, Since my goal is to retrieve the battery level from my own smartphone (the one that is paired AND connected to my smartwatch) how can I tell which of the devices found by my scan is the one that's connected? Or do I even need to perform a scan? Is there another way to retrieve the device object in order to then get the battery service 0x180F and then the battery level characteristic, 0x2a19? In other words, I want to be sure that the battery level I retrieve is that of my phone, not my buddies sitting next to me.
UPDATE: my smartphone is a Samsung Galaxy S3 running Android 4.3 and my smartwatch is a Samsung Gear S2 running Tizen 2.3.1. I'm using Tizen Bluetooth API.
The BluetoothLEScanCallback (In your case onFoundBLEDevice) is invoked everytime a device is found. (For 3 nearby devices -> 3 calls)
I've scanned nearby devices from my gear while it's connected with a Mobile through 'Samsung Gear' app. No, There's no way to distinguish specific Mobile connected via Gear Manager from other devices. So, You can't find the connected device in this procedure. (Unless you are developing the app for personal use, In that case you can hardcode your Mobile device's UUID)
Samsung Provides 'Accessory' SDK for such purposes.
Samsung Accessory SDK
Any data you exchange using Accessory SDK would provide you info of specific 'The Connected' device via Samsung Gear. Check Out the API References, Programming Guides and Android-End Sample apps and Tizen-End Sample apps in Accessory SDK section.
I have a bluetooth headset. When connecting it to Windows 10, it installs two profiles in Playback devices list:
Hands-Free. (HSP profile)
Stereo. (A2DP profile)
The Second one (Stereo) is set to be the "Default Device" and the "Default Communication Device" on the system.
When I start any program that uses the mic (recorder, chat, VoIP Calls, gaming, etc.) The sound suddenly stops working And I can only use the mic until I stop the recorder or the call.
To enable the sound again I need to make the Hands-Free (HSP) profile handle both input and output (sound and mic). Unfortunately, HSP gives really poor sound quality.
I want to know If there is a way, using code, I can change Bluetooth behavior so the two profiles work simultaneously. One handles the sound and one handles the mic so I can have high quality sound and use the mic at the same time.
You will probably never find a solution. I had the same problem (I was trying to create a walkie talkie with 2 headsets connected to the same smartphone).
On Windows (but also on Android) you can't access directly to a BT-microphone or BT-speaker because it is automatically detected as BT headset and the OS take the control of the device.
Your app can then access the OS-device and not directly the hardware device. The only OS able to do that was Symbian I think which had the most BT-protocols. On Windows you will probably never be able to do that and on Android you have to write your own A2DP-protocol if you want to access the device directly without OS interference.
So sad...
Luckily, under windows you can define different devices for communications and sound.
So, you have two choices:
Choosing Hands-free for both mic/speaker only for communication (which will switch back to A2DP after the call/teams).
Choosing another mic for communication which allow you to still use the speaker profile even in communication.
That is a bluetooth restriction : A2DP (high quality audio) cannot be use simultaneously with HFP (hands-free profile)
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 Bluetooth embedded in my car its default mediasystem. When my phone (Nexus 4) is connected it displays the signalstrength and batterylevel of the phone on the display.
What Bluetooth profile/protocol is used for this? I've investigated the HFP and MAP profiles but couldn't find anything on signalstrength or batterylevel.
In the end I want to make an Android app which sends the batterylevel to the car its Bluetooth 'carkit' to enable a charging 'animation'.
Most probably this is using Hands Free Profile (see sections 4.5 and 4.7), where the Audio Gateway (your phone) can report both signal strength and battery level to the Hands Free (your car).
I'm not familiar with the internals of Android, but I would imagine the Audio Gateway is part of the platform and not programmatically modifiable - here's no good reason to let a developer modify the battery or signal strength being reported to other devices.
I am trying to find a clever way to keep a BLE app active in the background on iOS 6, without breaking any of Apple's rules. I plan to use the phone as a peripheral device and another BLE circuit as the central. My app will automatically be opened when a user arrives to a building using geofencing. After that the iPhone will connect to the first BLE central device it sees (the device will be in its white list). The user will then be able to move throughout the building switching to different BLE "nodes".
My question is: What do I need to do in the background when a user is stationary at their desk so that the app does not get suspended due to memory resources?
My idea is based on this solution for a separate problem: There could potentially (not regularly) be 10-50 users in an area with only a few BLE "nodes" and I read at bluetooth.org that I could setup a dynamic connection system, basically rotating connections through all the users.
My idea is to setup a similar dynamic system where the central device (not the iPhone) disconnects the device on regular intervals (30-40 minutes) and then the iPhone will reconnect.
Is this something that some feasible? Is this against the iOS development guidelines? I was unable to find anything explicit about this. I have also asked on the iOS developer forum, but unfortunately it is not as popular as this site.
Thanks in advance!
Xcode -> Project target -> Capabilities -> Enable background mode
Check Uses Bluetooth LE Accessories
Capabilities
Also enable the following key in .plist file
Required background modes
App communicates using CoreBluetooth
Plist