Obsolete
Status Update
No update yet.
Comments
di...@gmail.com
Update: The system doesn't broadcast the intent BluetoothDevice.ACTION_PAIRING_REQUEST.
I tried to intercept the ACTION_PAIRING_REQUEST broadcast to input the PIN manually with BluetoothDevice.setPin(int), but whereas in Kitkat this (or the normal bonding) works correctly, in Android 5.0 this broadcast is not received by my app.
I tried to intercept the ACTION_PAIRING_REQUEST broadcast to input the PIN manually with BluetoothDevice.setPin(int), but whereas in Kitkat this (or the normal bonding) works correctly, in Android 5.0 this broadcast is not received by my app.
im...@gmail.com
Extra info:
The BLE chip of my device is a TI CC2540.
The pairing variant is BluetoothDevice.PAIRING_VARIANT_PIN
I attach an app that sets broadcasts receivers to show how in Android 5.0 there's no ACTION_PAIRING_REQUEST broadcast and the bond state passes directly from BONDING to BONDED. The screenshot shows the difference with KitKat when pairing the same device.
The BLE chip of my device is a TI CC2540.
The pairing variant is BluetoothDevice.PAIRING_VARIANT_PIN
I attach an app that sets broadcasts receivers to show how in Android 5.0 there's no ACTION_PAIRING_REQUEST broadcast and the bond state passes directly from BONDING to BONDED. The screenshot shows the difference with KitKat when pairing the same device.
ba...@gmail.com
[Comment deleted]
co...@gmail.com
I have same problem, please send me your "ble_bond_test.apk" source code. Thanks very much!
k....@gmail.com
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
sa...@google.com
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
Description
In my family, this has become a contentious issue as people become unreachable by phone because they've accidentally lowered their phone volume too much while working with media and now e.g. they're in a store and have no idea their phone is ringing because it's so quiet.
But in terms of UI, I don't think that most people want to adjust their phone volume all the time. I personally set what I feel is an acceptable level for most purposes and would like to keep it there, retaining the option to quickly switch to vibrate/silent/priority as the situation requires. Aside from this I sometimes wonder why the volume rocker isn't always associated with media volume - but alas my device is a phone at the end of the day and perhaps that would be going too far.
What I would love to see is a button on the volume UI that locks the phone ringer volume in place. When locked, any attempt to change media volume would succeed but an attempt to change phone volume would be denied -- the UI would appear but the lock icon would be shown and would pulsate to indicate the lock was active and preventing the action. Note that this would necessitate some change in the way the user turned on vibrate and silent modes, which you would still want to provide a mechanism for independent of whether or not the phone volume was locked. Perhaps there is a UI button that cycles between ring, vibrate, and silent. I think a lot of people have been asking for an easy way to change between those modes here anyway.
Thanks for consideration.