Bug: 36015415
Test: Modified Class of Device using sample app and verified device icon
change when discovering from a remote device.
Change-Id: Ie25f10be5560f9c090ebe489d5f3bb00cbca81ef
A new defined method of uuidToBytes is used to convert
Bluetooth uuid to bytes in the case of BLE advertising.
But the most significant 16 bits of a 32-bit uuid
will be cleared after the and operations with
0X0000FFFF00000000L in the function of
getServiceIdentifierFromParcelUuid.
0XFFFFFFFF00000000L should be used as bit mask.
Change-Id: I83e22ffbecd718540e644289fee12bf9c3b66305
Test: Advertise with payload contains 32-bit uuid
Bluetooth scanning requires holding these permissions for results
to be delivered.
Bug: 65013767
Test: N/A
Change-Id: I0b5fa9efa7fc8d5cff25319fbd7719cedee6a4aa
* Binder object may become null between null check and actual invocation
if using a instance private variable assignable by service connection
callbacks
* The solution to this problem without locking is to assign existing
binder variable to a local final variable before the null check
* Any further invocation to a disconnected binder object will result in
RemoteException that is caught by the try-catch block
* Read and write to volatile variable is always atomic and hence thread-safe
* Removed unnecessary synchronization in BluetoothAdapter constructor
* Private mConnection objects should be final
* Simplfied several return statements where booleans can be returned
directly
* Removed unnecessary catches for NPE since there won't be any
Bug: 64724692
Test: make, pair and use devices, no functional change
Change-Id: Ifc9d6337c0d451a01484b61243230725d5314f8e
(cherry picked from commit 16eeac356c)
* Binder object may become null between null check and actual invocation
if using a instance private variable assignable by service connection
callbacks
* The solution to this problem without locking is to assign existing
binder variable to a local final variable before the null check
* Any further invocation to a disconnected binder object will result in
RemoteException that is caught by the try-catch block
* Read and write to volatile variable is always atomic and hence thread-safe
* Removed unnecessary synchronization in BluetoothAdapter constructor
* Private mConnection objects should be final
* Simplfied several return statements where booleans can be returned
directly
* Removed unnecessary catches for NPE since there won't be any
Bug: 64724692
Test: make, pair and use devices, no functional change
Change-Id: Ifc9d6337c0d451a01484b61243230725d5314f8e
SCAN_MODE_LOW_POWER is enforced for applications running
in background.
Test: BLE scanning applications.
BUG: 38198694
BUG: 62491228
Change-Id: Ib2b6c297298e05f1b088411e94cfe4789dde0821
With change c4a1e1, unfiltered BLE scans are stopped on screen off
and resumed when screen is turned back on. This is done to save power.
This change updates the documentation accordingly.
BUG: 62264269
Test: Documentation update.
Change-Id: I2d8e9f9f122f978c4d4f59d4139cb51cd4e4a123
Currently, scan throttling happens after client is registered, but
before the scan is started. This might lead to scan client being leaked.
This patch fixed that by moving check before client registration.
Bug: 64887233
Test: manual
Change-Id: I22ae624a0c51110cb69679f796926e3b2b36d0ac
Merged-In: I22ae624a0c51110cb69679f796926e3b2b36d0ac
(cherry picked from commit ee02e1ce77)
Currently, scan throttling happens after client is registered, but
before the scan is started. This might lead to scan client being leaked.
This patch fixed that by moving check before client registration.
Bug: 64887233
Test: manual
Change-Id: I22ae624a0c51110cb69679f796926e3b2b36d0ac
* Manual style corrections with IDE assistance
* Variable name refactors are done through IDE
* Corrected general style errors such as:
- "final private var" -> "private final var"
- "&&", "+", "||" should not be at the end of line
- Non-static private variable should be like "mVar"
- Private static variable should be like "sVar"
- Code file should always end with newline
- Inherited methods should be annotated with @Override
and no @hide tags
- Public methods should always have a JavaDoc entry
- "int[] array" is preferred over "int array[]"
- private methods should be accessed without "this."
when there is no name collisions.
- "boolean ? true : false" -> boolean
- "boolean ? false : true" -> !boolean
- "boolean == true" OR "boolean != false" -> boolean
- "boolean != true" OR "boolean == false" -> !boolean
Bug: 63596319
Test: make checkbuild, no functional changes
Change-Id: Iabdc2be912a32dd63a53213d175cf1bfef268ccd
* Automatic style corrections through IDE
Bug: 63596319
Test: make checkbuild, no manual changes, no functional changes
Change-Id: I2397d55abc34c9b7a9b748bec6137778df3421a7
Calls to old advertising API (startAdvertising), should never throw
exceptions. Instead, it used to post failure callback. This behaviour
was accidentally modified when implementing new API. Right now, instead
of posting error callback, we throw IllegalArgumentException if we fail
to obtain BluetoothGatt object, or the call to startAdvertisingSet
fails.
This patch brings back the old behaviour to the API. It also makes new
API post callback instead of throwing exception in this error case.
Bug: 63819108
Test: manual
Change-Id: I897b99839f899ca3f3dc609918d665c8c327b777
Merged-In: I897b99839f899ca3f3dc609918d665c8c327b777
(cherry picked from commit f7bd6b26c7)
When advertising is stopped while Bluetooth is disabled, we should not
throw any exceptions, just log the failure.
This was the default behaviour before the AdvertisingSet was introduced.
Bug: 63819108
Test: manual
Change-Id: I518e071b77b127973aee6f24fa6ced4f28bc9531
Merged-In: I518e071b77b127973aee6f24fa6ced4f28bc9531
(cherry picked from commit f73863dc29)
When advertising is stopped while Bluetooth is disabled, we should not
throw any exceptions, just log the failure.
This was the default behaviour before the AdvertisingSet was introduced.
Bug: 63819108
Test: manual
Change-Id: I518e071b77b127973aee6f24fa6ced4f28bc9531
Calls to old advertising API (startAdvertising), should never throw
exceptions. Instead, it used to post failure callback. This behaviour
was accidentally modified when implementing new API. Right now, instead
of posting error callback, we throw IllegalArgumentException if we fail
to obtain BluetoothGatt object, or the call to startAdvertisingSet
fails.
This patch brings back the old behaviour to the API. It also makes new
API post callback instead of throwing exception in this error case.
Bug: 63819108
Test: manual
Change-Id: I897b99839f899ca3f3dc609918d665c8c327b777
