Thursday, October 15, 2015

Bluedroid Stack

Directory Structure  of Bluedroid in Android:



BLuedroid Folder Structure description:

a) audio_a2dp_hw/  -->  A set of audio interfaces for external audio module to inject their implementation of these audio interface.

b) bta/  -->  It is Bluetooth application profile layer, The btif will call bta.

c) btif/  --> All the Bluetooth JNIs will direct;ly intract with btif

d) conf/ --> Configuration files for bluedroid ( Ex. debugging level, path of snoop log)

e) embdrv/ ---> SBC encoder/decoder

f) gki/  --> Defines a tiny embedded os based on pthread, It means generic kernel interface

g) HCI/ --> Implementation for HCI ( Ex. To compose the HCI command and emit it)

h) main/ --> The core initialization function for the Bluedroid( Initialze OS/HCI etc

i) osi/ --> OS interface for gki, ( Ex. Alarm/queue/list)

j) stack/ --> the bluetooth core stack, Between BTA and HCI

k) test/ --> A test tool for bluedroid ( framework and command line test tool)

l) udrv/ --> Implementation for UIPC ( IPC)

m) utils/ --> HElper function for bludroid

n) vnd/ --> Implementation for vendor features, ( Android's BLE proprietary features)


------------------------------STACK-------------------------------------



BT IF – Bluetooth Interface layer:
Implements the HAL interfaces that are invoked by the JNI calls
Maintains the callbacks registered by JNI
JNI callbacks are invoked by the IF layer based on the updates from the BTA/Stack
 
BTA – Bluetooth Application Layer:

Implements the Bluetooth profiles 
Maintains the profiles state machines
Handles events from the Stack and sends it back to IF layer

Bluedroid Stack:
Implements all protocols

HCI Layer:
HCI layer built as a shared library (libbt-hci) and acts as an interface between the transport layer and the stack. 
Support for the HCI H4 or the SMD transport – glues the serial driver calls for instance, with the upper layers

-----------> Bluedroid component---<
Structure is split into the following parts 
Application Specific Layer
ex. contains Bluetooth APK and android Services for Profiles. 
Bluetooth Middleware components
 ex. Bluetoothheadsetservice  and JNI System Object (libbluetooth_jni) 
Bluetooth Profile Interface (BTIF)  and stack adaptation layer (BTA =>  libbt-brcm_bta system object)
Core Stack (libbt-brcm_stack) and HCI Transport interface (libbt-hci)
Kernel drivers for transport layers like Serial, USB, SDIO 
Real Physical Hardware  (SOC)


Bluedroid stack, profiles and application run in a single user space process “com.android.bluetooth”
Bluetooth code runs in the context of 4 Tasks
BTIF_TASK
BTU_TASK
A2DP_MEDIA_TASK
GKI_TIMER_TASK
Communication between the above tasks is through MESSAGE_QUEUE
// Example:
void BTA_DmSearch(tBTA_DM_INQ *p_dm_inq, tBTA_SERVICE_MASK services, tBTA_DM_SEARCH_CBACK *p_cback)
208{...
 bta_sys_sendmsg(p_msg);
}
571void bta_sys_sendmsg(void *p_msg)
572{
573    // There is a race condition that occurs if the stack is shut down while
574    // there is a procedure in progress that can schedule a task via this
575    // message queue. This causes |btu_bta_msg_queue| to get cleaned up before
576    // it gets used here; hence we check for NULL before using it.
577    if (btu_bta_msg_queue)
578        fixed_queue_enqueue(btu_bta_msg_queue, p_msg);
579}

API calls from JNI are transferred to BTIF_TASK context by posting messages
JNI/HAL callbacks run in the context of BTIF_TASK
BTIF Task intern will switch the context to BTU_TASK based on the request
Profile and Protocol implementation run in the context of BTU_TASK
Bluetooth transport driver has Rx thread to read data from UART/SMD (bt_hc_worker_thread)

Tuesday, October 13, 2015

Useful macro in Bluetooth

Device Type:
    * Bluetooth device type, Unknown
     */
    public static final int DEVICE_TYPE_UNKNOWN = 0;
    /**
     * Bluetooth device type, Classic - BR/EDR devices
    */
    public static final int DEVICE_TYPE_CLASSIC = 1;
    /**
     * Bluetooth device type, Low Energy - LE-only
    */
    public static final int DEVICE_TYPE_LE = 2;
    /**
     * Bluetooth device type, Dual Mode - BR/EDR/LE
    */
    public static final int DEVICE_TYPE_DUAL = 3;
/**
     * A bond attempt succeeded
     * @hide
     */
    public static final int BOND_SUCCESS = 0;
   /**
     * A bond attempt failed because pins did not match, or remote device did
     * not respond to pin request in time
     * @hide
     */
    public static final int UNBOND_REASON_AUTH_FAILED = 1;

    /**
     * A bond attempt failed because the other side explicitly rejected
     * bonding
     * @hide
     */
    public static final int UNBOND_REASON_AUTH_REJECTED = 2;

   /**
     * A bond attempt failed because we canceled the bonding process
     * @hide
     */
    public static final int UNBOND_REASON_AUTH_CANCELED = 3;

    /**
     * A bond attempt failed because we could not contact the remote device
     * @hide
     */
    public static final int UNBOND_REASON_REMOTE_DEVICE_DOWN = 4;

    /**
     * A bond attempt failed because a discovery is in progress
     * @hide
     */
    public static final int UNBOND_REASON_DISCOVERY_IN_PROGRESS = 5;

    /**
     * A bond attempt failed because of authentication timeout
     * @hide
    */
    public static final int UNBOND_REASON_AUTH_TIMEOUT = 6;

    /**
     * A bond attempt failed because of repeated attempts
     * @hide
     */
    public static final int UNBOND_REASON_REPEATED_ATTEMPTS = 7;

    /**
     * A bond attempt failed because we received an Authentication Cancel
     * by remote end
     * @hide
     */
    public static final int UNBOND_REASON_REMOTE_AUTH_CANCELED = 8;

/**
479     * The user will be prompted to enter a pin or
480     * an app will enter a pin for user.
481     */
482    public static final int PAIRING_VARIANT_PIN = 0;

    public static final int PAIRING_VARIANT_PASSKEY = 1;
489
490    /**
491     * The user will be prompted to confirm the passkey displayed on the screen or
492     * an app will confirm the passkey for the user.
493     */
494    public static final int PAIRING_VARIANT_PASSKEY_CONFIRMATION = 2;
495
496    /**
497     * The user will be prompted to accept or deny the incoming pairing request
498     * @hide
499     */
500    public static final int PAIRING_VARIANT_CONSENT = 3;
501
502    /**
503     * The user will be prompted to enter the passkey displayed on remote device
504     * This is used for Bluetooth 2.1 pairing.
505     * @hide
506     */
507    public static final int PAIRING_VARIANT_DISPLAY_PASSKEY = 4;
508
509    /**
510     * The user will be prompted to enter the PIN displayed on remote device.
511     * This is used for Bluetooth 2.0 pairing.
512     * @hide
513     */
514    public static final int PAIRING_VARIANT_DISPLAY_PIN = 5;

Inquiry in Bluetooth after turn on BT

BT inquiry:

We are going to start form the scanning or inquiring the device, once the BT is turned ON.


/packages/apps/Settings/src/com/android/settings/bluetooth/BluetoothSettings.java:
This function is get called from the top right cornor where we are doing the refresh.
public boolean onOptionsItemSelected(MenuItem item) --> startScanning();

// this will get called when BT is totaly turned ON.
 public void onBluetoothStateChanged(int bluetoothState)--> startScanning();

// This function will get called when any device is getting bonded once the bonding complete then below content will
get updated.
public void onDeviceBondStateChanged(CachedBluetoothDevice cachedDevice, int bondState) --> startScanning();

 /packages/apps/Settings/src/com/android/settings/bluetooth/LocalBluetoothAdapter.java
startScanning()--> mAdapter.startDiscovery()

/frameworks/base/core/java/android/bluetooth/BluetoothAdapter.java
 : Start the remote device discovery process. The discovery process usually involves an inquiry scan of about 12 seconds, followed by a page
scan of each new device to retrieve its Bluetooth name.
It is asynchronous call, it will return immediately. Register for #ACTION_DISCOVERY_STARTED and ACTION_DISCOVERY_FINISHED intents to determin exactly when the disocvery starts and completes.
Register for BluetoothDevice#ACTION_FOUND to be notified as remote bluetooth devices are found.

NOTE: Discovery is not managed by th eActivity, but is run as a system service, so an application should always call BluetoothAdapter#cancelDiscovery().
Device discovery will only find remote device that are currently discoverable.
 mService.startDiscovery();

/packages/apps/Bluetooth/src/com/android/bluetooth/btservice/AdapterService.java

startDiscovery() --> startDiscoveryNative();

 /packages/apps/Bluetooth/jni/com_android_bluetooth_btservice_AdapterService.cpp

startDiscoveryNative(JNIEnv* env, jobject obj) --> start_discovery();

/hardware/libhardware/include/hardware/bluetooth.h[HAL LAYER]

int (*start_discovery)(void);

/external/bluetooth/bluedroid/btif/src/bluetooth.c [STACK LAYER NOW ONWARDS]

static int start_discovery(void)--> btif_dm_start_discovery();

/external/bluetooth/bluedroid/btif/src/btif_dm.c

btif_dm_start_discovery-->   BTA_DmSearch(&inq_params, services, bte_search_devices_evt);

/external/bluetooth/bluedroid/bta/dm/bta_dm_api.c
// This function searches for peer bluetooth devices.It performs an inquiry and gets the rremote name for devices.

BTA_DmSearch()


/external/bluetooth/bluedroid/bta/dm/bta_dm_act.c
//Start an inquiry
bta_dm_search_start() --> BTM_StartInquiry()

/external/bluetooth/bluedroid/stack/btm/btm_inq.c
// for start the inquiry:
BTM_StartInquiry(), p_results_cb  -- is the pointer to callback with inquiry result.

NOTE: Inquiry having 3 second timeout waiting for response.

------------------- after inquiry complete sending data to application side------------------
/external/bluetooth/bluedroid/btif/src/btif_dm.c
//Switches context from BTE to BTIF for DM search events
bte_search_devices_evt()---> btif_dm_search_devices_evt()

/external/bluetooth/bluedroid/btif/src/btif_dm.c
btif_dm_search_devices_evt()-->
  HAL_CBACK(bt_hal_cbacks, device_found_cb,num_properties, properties);

  /hardware/libhardware/include/hardware/bluetooth.h[HAL layer]
device_found_callback device_found_cb;

/packages/apps/Bluetooth/jni/com_android_bluetooth_btservice_AdapterService.cpp
device_found_callback () -->devicePropertyChangedCallback()

/packages/apps/Bluetooth/src/com/android/bluetooth/btservice/JniCallbacks.java

devicePropertyChangedCallback () -->  mRemoteDevices.devicePropertyChangedCallback(address, types, val);


/packages/apps/Bluetooth/src/com/android/bluetooth/btservice/RemoteDevices.java

devicePropertyChangedCallback() -->

Bonding in Bluetooth ( Pairing )


Bonding in BT:

Once the device is get displayed on the device, after the inquiry then we will proceed
for the bonding. Then below function will get called when the user start then bonding procedure from device.


/packages/apps/Settings/src/com/android/settings/bluetooth/BluetoothDevicePreference.java
//
private void pair() ---> mCachedDevice.startPairing()

/frameworks/base/packages/SettingsLib/src/com/android/settingslib/bluetooth/CachedBluetoothDevice.java
mDevice.createBond()

/frameworks/base/core/java/android/bluetooth/BluetoothDevice.java
// Start the bonding (pairing) process with the remote device. It is asynchronous call, it will return immediately.
Register for #ACTION_BOND_STATE_CHANGED intentes to be notified when the bonding process
completes, and its result.
public boolean createBond()

/packages/apps/Bluetooth/src/com/android/bluetooth/btservice/AdapterService.java
// It will send event to BondStateMachine.CREATE_BOND
public boolean createBond(BluetoothDevice device, int transport)

1. /packages/apps/Bluetooth/src/com/android/bluetooth/btservice/BondStateMachine.java
[createBond()]--> mAdapterService.createBondNative(addr, transport):from here the call will go to the native. to create the bond.--> createBondNative();
2. same file : BONDING_STATE_CHANGE--> go for weather the current state is bonded, none, bonding.

 /packages/apps/Bluetooth/jni/com_android_bluetooth_btservice_AdapterService.cpp
sBluetoothInterface->create_bond()

3. /packages/apps/Bluetooth/src/com/android/bluetooth/btservice/AdapterProperties.java
onBondStateChanged()->  This function sahll be invoked from BondStateMachine whenever th bond sate changes.

4. /hardware/libhardware/include/hardware/bluetooth.h [HAL layer]
int (*create_bond)(const bt_bdaddr_t *bd_addr, int transport);

5. /system/bt/btif/src/bluetooth.c
static int create_bond(const bt_bdaddr_t *bd_addr, int transport)

6. /system/bt/btif/src/btif_dm.c
// It will post event #BTIF_DM_CB_CREATE_BOND.
bt_status_t btif_dm_create_bond(const bt_bdaddr_t *bd_addr, int transport)
// and the call will come to here
 btif_dm_cb_create_bond(&create_bond_cb->bdaddr, create_bond_cb->transport);
BTA_DmBondByTransport()
btif_hh_connect(bd_addr); // only for the HID device other wise for BR_EDR above call.

NOTE:
1. When the call will go to [btif_dm_cb_create_bond], it will call [bond_state_changed] and then
call will go to the application layer i.e bond state is changed not , from "bond_none" to bonding.


7. /system/bt/bta/dm/bta_dm_api.c
// It will initiates a bonding procedure with a peer device. and post the event: BTA_DM_API_BOND_EVT
BTA_DmBondByTransport() or BTA_DmBond()

8. /system/bt/bta/dm/bta_dm_act.c
void bta_dm_bond (tBTA_DM_MSG *p_data)

9. /system/bt/stack/btm/btm_sec.c[this file contain regarding securitypairing SSP adn link key]
// It perform bonding with peer device. If the connection is already up, but not secure, pairing
is attempted. If already paired BTM_SUCCESS is returned.
BTM_SecBondByTransport()--> btm_sec_bond_by_transport()
btm_sec_bond_by_transport --->This is bond function that will start either SSP or SMP
//This function is cllled to perform bonding with peer device. If connection is already up, but not secure,
pairing is attempted. If already paired BTM_SUCCESS is returned.
BTM_SecBond() --> btm_sec_bond_by_transport

btm_sec_change_pairing_state (BTM_PAIR_STATE_WAIT_PIN_REQ);
// IF the device matches with stored paring address reset the paring state to idle.
btm_sec_change_pairing_state(BTM_PAIR_STATE_IDLE);


10. /external/bluetooth/bluedroid/stack/btm/btm_sec.c

// This is bond function that will start either SSP or SMP.
btm_sec_bond_by_transport()

Bluetooth Turning ON

Once Phone Bootup is complete, then BT initilization will be go...com.android.bluetooth and com.btservice.AdapterService will get started.

1. Device supporting profile is get added to config.(like, a2dp, hid, pan,map,etc)
2. Register IBluetoothManagerCallback.
3. Init Bluedroid, Load bt_stack.conf and Start BTIF.
4. BluetoothServiceConnection
5. getAdapterPropertiesNative --> get_adapter_properties(at the time of init)
6. Adapterpropertychangedcallback with Set_adapter_property: address, Name.

*********************************************************************
User action: Enable BT(Tuning ON):
once the user turn on BT, the state will go from 10 to 11(turning on )
then it will start all the profile services (hidservice, a2dpservice...),then call will go for the enable BT to JNI-->HAL-->BTIF-->BTE-->HCI--> vendor specific--> UART.
btif will wait for th trigger to init chip and stack. This trigger will be received by btu_task once the UART is opened and ready.


Call flow of BT ON from the APP side:

1. /packages/apps/Settings/src/com/android/settings/bluetooth/BluetoothEnabler.java
call-->  mLocalAdapter.setBluetoothEnabled(isChecked);
2. /packages/apps/Settings/src/com/android/settings/bluetooth/LocalBluetoothAdapter.java
call--> mAdapter.enable();
3.[BluetoothAdapter.java] return mManagerService.enable();
NOTE: 1. Show toast message : BT is not allowed in Airplane Mode.
4. [LocalBluetoothAdapter.java]private static final int SCAN_EXPIRATION_MS = 5 * 60 * 1000; // 5 mins
6. Once BT came to TURN ON then it will initilize or update the local profile objects.(a2dp or handsfree profile)
   call -->  updateLocalProfiles();
7. notifyAdapterStateChange()[AdapterState.java]--> This is responsible for the state change managment.

Saturday, August 8, 2015

Bluetooth Basic Concept

Link Controller:
The link controller implements the Blutooth baseband protocol.

In the Bluetooth system, the link manager uses the services of the link controller to implement the LMP(link Manger protocol).

CONCEPT:

1. Addresses: 
Each BT device is assigned a 48-bit address consisting of three parts: a 24-bit lower address part (LAP) and 8-bit uppder address part(UPA), and a 16-bit so called non-significant address part(NAP).LAP and UAP address parts are used in several places in the Baseband protocol. The 32-bit concatenation of the upper and lower address parts is also used and abbreviated as ULAP.

2. Channels:
The BT standerd uses a number of of diffeerent channels, located at different radio frequencies, to communicate data. Channel hopping, i.e. periodic switching between channels, is used to reduce the impact of other radio sources disturbing particular channels, and to enable the existence of multiple BT network in one area.

3. Clocks and slots:
The BT clock is a 28-bit counter with a clock cycle of 312us.BT communicate at the Baseband level is organised into time slot. Each slot has length of two clock cycle.

4. PACKETS:
BT communicateion at the Baseband level is packet-oriented. Anumber of different packet types of varying lengh and with varying error correction and detection facilites are defined. Packets occupy one, three, or five time slots.

5. PICONETS:
The master in a piconet determines slot timing, the channel hopping sequence, and slot allocation. Slave have to adjust to the master's parameters.

6. INQUIRY Procedure: The inquiry procedure enables devices to locate other devices in its vicinity. The inquiring device  build up a list of neighbouring devices.

7. PAGE Procedure: It enables devices to establish connection b/w each other. A device page scan mode to listen for packets. On hearing a page packet addressd to itself, the scanning device send a page response. Two more packets are exchanged before a link is fully set up.

NOTE: As the result of the page procedure, the scanning device becomes a slave in the paging device's piconet.

*** Master/slave switch:  Sometimes it may be necessary to switch roles in an existing connection, i.e a master may need to join a slave's piconet. Instead of using the page procedure again, they can agree (at the LMP level) to use the Baseband master/slave switch procedure.

8. ACL Links:
Packets on an Asynchronous connection -less link are sent in the next availabel slot. Since there can be contention for slots and transmission errors, they are not guaranteed to arrive within a certain time. Error correction adn detecetion together with flow control ensure though, that packets are eventually delivered, and that happens in the oreder they were sent. ACL links can therfore be compared to TCP internet connection.

An ACL link b/w two devices is established through using the page or master/slave switch procedure.  Normally there will only be one ACL link b/w two devices, but there might be a second with exchanged master/slave roles.

Each device can maintain up to fourteen ACL links: up to seven links to slaves in its own piconet, and up to seven links to master of the other piconets

9. SCO links:
Synchronuous connection-orinted links reserved time slot at regular interval. Packets are guaranteed to be sent in the next reserved slot. Error correcction and detection can be used, but flow control is not provided. If an uncorrected transmission error occurs, the packet is lost. SCO link are therfore best suited to real-time data link audio or video where a continous data flow is more important tath data correctness. SCO link might best be compared to ISDN connections.

Two devices can use an existing ACL link to agree on the parameters for the establishment of an SCO link. Each SCO link is associated with an underlying ACL link. there can be multiple SCO links per ACL, i.e. multiple SCO links b/w two devices. Each devices can have up to Three SCO links altogether.

10. Broadcast:
The master of a piconet has the ability to broadcast ACL packets to all its connected slaves, whereby flow control is not provided.

Broadcast is implemented as an additional ACL link, which is availabe by default and over which packets can only be sent but not received. As a slave, broadcast packets are received on the same ACL link as other packets from the current master.

11. Link timeouts:
According to the Baseband specification, a newly established ACL link needs to be verified by the exchange of initial (possibly empty) packets. If that does not happen within a timeout period of 32 slots, the link is removed and the link manager is notified through the new_connection_timeout callback

Also, if no packet is received from a device within a timeout period of 16000 slots (i.e. 20 seconds), the ACL link to that device is removed and the link manager is notified through the supervision_timeout callback

12. Receive buffers:
As there are only one ACL and one SCO receive buffer, no link identifiers are needed here.

An incoming packet is signalled through a rx_reg_loaded c
After a packet has been read and, if necessary, the payload has been copied, it can be removed from the buffer using a clear_rx_reg command.

13. Transmit buffers
Transmit buffer commands take as their second argument the ID of the ACL or SCO link that the targeted buffer is associated with.

To load a packet into a SCO or ACL transmit buffer, the following two operations are used. The packet type must fit the link type, and for ACL links, the maximum slot number must be adhered to. For ACL packets, the packet length must not be greater than the maximum length allowed for the packet type. For SCO packets, the packet length is implicit in the type. The actual payload is provided through a pointer.
After a packet has been sent and, in the case of ACL links, acknowledged successfully,

14. SCO link establishment:
SCO link parameters have to be agreed at the LMP level. Using the add_sco_link command, the link manager can then tell the link controller about the new link.

Two IDs must be provided: an unused SCO link ID for the new link, and a used ACL link ID that denotes the master or slave device to connect to.


************************************************************************

Generic Steps follow up after BT ON:

A: Inquiry: A device in a new environment will automatically initate an inquriy to discover what access pints are within its range.

B: Paging: A baseband procedure invoked by a device which results in synchronization of the device with the access point.

C: Link establishment: The LMP will now establish a link with the access point. If security mode 3, then pairing begins at this layer.

D: Service Discovery: The LMP will use the SDP (service discovery protocol) to discover what device are available.

E: L2CAP channel created : with information obtained from SDP a L2cap channel is created. this may be directly used by the application or by another protocol (eg. RFCOMM, AVCTP etc)

F: Pairing: begins her if the security mode 2. --> then it will ask for the pin and create the link key and share it with remote device.





Monday, July 27, 2015

                                                    Bluetooth



BT ON/OFF

When we will do the BT ON/OFF on the UI, the call will go to the BluetoothManagerService and it will register the
BluetoothAdapter in this state it will init the stack and load the config file etc.

then the call will go to BluetoothAdapterProperties, BT state will change from 10->11.

after then it will start all the profile severice( like a2dp, pbap, hfp,avrcp etc), after then BT state will change from 11->12.

Now we will go for the bonding of the device{ When Remote device start the bonding or try to connect with local device.

The call will come to (btif_dm.c file) it will change the state to (BT_BOND_sTATE_BONDING) -> HAL(bluetooth.h)[bond_state_changed_callback]-> JNI(com_android_bluetooth_btservice_AdapterService.cpp)[bond_state_changed_callback]-->Application (BondStateMachine.java)[ bondStateChangeCallback]

Then appllication will respond through the JNI and then it will go to the stack {bluetooth.c{create_bond}--> btif_dm.c(btif_dm_create_bond())

Then BTIF layer will get the PIN_Request event (BTA_DM_PIN_REQ_EVT-> btif_dm_pin_req_evt)--> HAL--> JNI-->Application{ setPin--> pinReplyNative}



L BT states:
10[STATE_OFF]- Indicate BT adapter is off.
11[STATE_TURNING_ON]- Indicated the local BT adapter is turning on. However local clients should wait for (@link #STATE_ON) before attempting to use the adapter.
12[STATE_ON]-Indicate the local BT adapter is on, and ready for use.{ Start BREDR Service, Set connectable, discoverable}
13[STATE_TURNING_OFF]- Indicates the local BT adapter is turning off. Local clients should immediately attempt graceful disconnection of any remote links.{ OnBluetoothDisable--> Stop BR-EDR services, clear connectable, discoverable}

M BT state introduce some more states:
14[STATE_BLE_TURNING_ON]-
15[STATE_BLE_ON]-
16[STATE_BLE_TURNING_OFF]-

Turning ON State: 10-->14-->15-->11-->12
Turning OFF State: 12-->13-->15-->16-->10

-------------------- Once the BT is on, now we are going to Connect the i.e for the BOnding:------------
State Machine for BOND:
CREATE_BOND=1
CANCLE_BOND=2
REMOVE_BOND=3
BODING_STATE_CHANGE=4
SSP_REQUEST=5
PIN_REQUEST=6
BOND_STATE_NONE=0
BOND_STATE_BONDING=1
BOND_STATE_BONDED =2




Bonding main file are:
btif_dm.c

Bond types:

1. BOND_TYPE_UNKNOWN
2. BOND_TYPE_PERSISTENT
3. BOND_TYPE_TEMPORARY
4. ENCRYPTED_BREDR
5. ENCRYPTED_LE



Questions:

1. When ACL connection will be initiated??
2. when link key will be stored and how??

Qualcomm Short Term

  113 is the SL. 1st Target by mid July.

Total Pageviews