It's returned by getReport() when callback data is ready.
Change-Id: I751c9e31de3d82a454a62cb8485a230e722b740d
Signed-off-by: Mike J. Chen <mjchen@google.com>
So we don't have to do conversion when using getReport/setReport
and can pass the value to the BT HAL directly.
Change-Id: I8d4af72d2e040d43cc9ff8a8cddfbe6cc8cfdb9a
Signed-off-by: Mike J. Chen <mjchen@google.com>
Perform ParcelFileDescriptor close after detach to avoid bluetooth
socket leaks in strict mode.
bug:12647433
Change-Id: I22f422547b2fb33b9bf12065dc689ed7785a7269
If calling connect succeed, we should not see this NPE.
An IOException may happen after call BluetoothSocket.connect.
If you still call write after the IOException,
you will get this NPE.
add NPE protection for possible wrong calling sequence from application,
To make bluetoothSocket more error-tolerant.
bug:12104154
Change-Id: I7fa4e847b500ca9b9d2a43df432f31a1bb016c0a
This is caused by access fetchUuidsWithSdp after bluetooth is turned off.
We can add check null pointer for sService,
before call sService.fetchRemoteUuids(this) to fix this problem;
bug:12533948
Change-Id: Id2cab92a56185073fabcabcfb21a243e99a60cee
If calling connect succeed, we should not see this NPE.
An IOException may happen after call BluetoothSocket.connect.
If you still call write after the IOException,
you will get this NPE.
add NPE protection for possible wrong calling sequence from application,
To make bluetoothSocket more error-tolerant.
bug:12104154
Change-Id: I7fa4e847b500ca9b9d2a43df432f31a1bb016c0a
The APIs are createBond, setPin, setPairingConfirmation
The intent is ACTION_PAIRING_REQUEST
bug 11101076
Change-Id: I3a314efd973b3ce078ab5347159c336f222d9f15
Note that this CL does not change any behaviour.
At the center of this change is
CaptivePortalTracker#detectCaptivePortal(), which does nothing
except call back into ConnectivityService. Removing it allows us to
simplify code in ConnectivityService. It also allows us to remove
ConnectivityService#captivePortalCheckComplete which was only ever
called in response to this method.
While this does not change any behaviour, it preserves existing
bad behaviour, i.e, that the CAPTIVE_PORTAL_CHECK NetworkInfo
state does not correspond to actual captive portal detection.
We transition into that state and immediately (and unconditionally)
out of it and into CONNECTED.
Change-Id: Ib3797f956d2db5e3cacaaa53e899d81aa8e958af
Adds another vendor-specific command AT+ANDROID in Bluetooth Hands-Free
Profile. And creates an API function that sends an unsolicited result
code +ANDROID .
Bug: 8736189
Change-Id: I4757c410d31b97511c92f66d71035eb929f9fd29
This change starts tracking traffic quality data for WiFi and mobile
networks. The quality is tracked based on incidental traffic, and not
on specific measurements. Theoretical bandwidths are hard-coded, as
well as sampling interval; although sampling interval can be changed
by setting a system policy.
Bugs filed to remove shortcomings of this change -
10342372 Change LinkInfo name to something better
10342318 Move hardcoded values of MobileLinkInfo to resources
so they can be updated without changing code
Bug: 10006249
Change-Id: I83d8c7594da20fe53abbd5e1f909b1f606b035bb
BluetoothGatt.abortReliableWrite() should not take a BluetoothDevice
parameter. Instead, it should use mDevice instance variable.
bug 10152994
Change-Id: I7fc79b9011cf878414128cc9f1696e5ccc597056
If a remote devices offers multiple descriptors with the same UUID, the
instance ID is used to differentiate between them.
Change-Id: I0c36494c980c86abd23f9647196af8d59ef663e9
When captive portal checking completes pass back the result.
This is used to enable/disable failing fast for mobile. When
failing fast is enabled we don't check for data stalls and thus
won't be continually trying to do recovery operations, such as
restarting the radio.
Bug: 9462512
Change-Id: I0dea0eee519f8ee7f94e79d40e82c18f30d7fe2e
The bindService() and startService() calls have always had
undefined behavior when used with an implicit Intent and there
are multiple matching services. Because of this, it is not
safe for applications to use such Intents when interacting with
services, yet the platform would merrily go about doing... something.
In KLP I want to cause this case to be invalid, resulting in
an exception thrown back to the app. Unfortunately there are
lots of (scary) things relying on this behavior, so we can't
immediately turn it into an exception, even one qualified by the
caller's target SDK version.
In this change, we start loggin a WTF when such a call happens,
and clean up some stuff in Bluetooth that was doing this behavior.
Change-Id: I62e25d07890588d2362104e20b054aebb6c0e007
