Rootcause: The PSM employed by L2CAP in LE and BR/EDR contexts are not identical concepts. The LE scenario utilises a simplified PSM, whereas the BR/EDR scenario employs the standard PSM. These differ fundamentally in their allocation methods and are not interoperable.
Consequently, the current implementation of listen and stop listen operations requires distinguishing between connection types. Add a new API `bt_l2cap_stop_listen_with_transport` to support stop listen on BR/EDR PSM. This modification will rectify the error where `bt_l2cap_stop_listen` fails to recognise connection types, whilst filtering operations specific to the BR/EDR type.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Rootcause: Currently, when the bt_hfp_hf_query_current_calls interface receives a request, it retrieves the result from the state machine cache and returns it immediately. However, since the cache may not be updated in a timely manner, the returned data may not be the latest.
Signed-off-by: liyuheng <liyuheng@xiaomi.com>
Rootcause:When reconnect to the headset during a call, the headset will obtain the call status through the cind command. Since Vela does not have modem, the status will be error. So, get cind from Android.
Signed-off-by: zhangyuan20 <zhangyuan20@xiaomi.com>
Whitelist with type API allows adding a BLE address with a specified address type to the whitelist. Note that each address can only have one address type, and the stack will auto handle merging of address type operations.
New API:
bt_status_t BTSYMBOLS(bt_adapter_le_add_whitelist_with_type)(bt_instance_t* ins, bt_address_t* addr, ble_addr_type_t type);
Signed-off-by: zhongzhijie1 <zhongzhijie1@xiaomi.com>
Root Cause: When a C++ file references a Bluetooth file, compilation errors occur due to the Bluetooth file using C++ keywords.
Signed-off-by: jialu <jialu@xiaomi.com>
In order to implement the PTT function of headphone control, it is necessary to add the process of AG send and receive vendor specific AT commands.
Signed-off-by: jialu <jialu@xiaomi.com>
Originally, only the "adapter_disable" function was executed. An additional step was added before that, which disconnects all ACL connections. A timer was also started to wait for the "disconnect" event for 2 seconds, followed by cleaning up profile resources (by following the normal disable procedure).
Signed-off-by: zhongzhijie1 <zhongzhijie1@xiaomi.com>
Rootcause: Due to the diversity of application scenarios, the API for invoking the Connection Enhanced Mode is provided for applications to call. Applications can enable or disable specific enhanced modes according to their own needs.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Reason: usually spp uses pty as a cross-process serial data transmission channel on velaos, in the case of cross-core,
in order to maintain the universality of the solution and dynamic port support, we use rpmsgfs_mount to resolve this problem,
run this command 'mount -t rpmsgfs -o cpu=cp,fs=/dev/pts /dev/cp/pts' in rc.sysinit.ap, mount cp core's 'dev/pts' folder to
ap core's 'dev/cp/pts' folder, access 'dev/pts/x' device on ap core directly to resolve pty cross-core communication.
This solution power is abnormal on some device, pty dev as a device type on cp, but pty's property changed after mounting,
access pty as fsnode on ap core, standard fs don't support 'poll', poll pty fd will cause busyloop on ap core, because fs not support
poll and rpmsg poll is not implemented, kernel just poll_notify POLL_IN to user-process, ap core can't enter lowpower mode.
Fix: use rpmsg_uart replace rpmsgfs way on cross-core case, add new spp api bt_spp_register_app_ext and new type SPP_PORT_TYPE_RPMSG_UART,
user need tell spp server which port type, rpmsg_uart type is fixed at present and don't support dynamic port.
Signed-off-by: fangzhenwei <fangzhenwei@xiaomi.com>
Rootcause: Application does not need to know the Bluetooth ACL handle. Therefore, the corresponding API needs to be removed.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
1. Port Vela Bluetooth Framework Socket Client onto Android.
2. For Socket Server, Service, SAL, we didn't port them onto Android.
3. For bttool, the function is not ready yet.
4. With this libbt-framework-client.so, we can start working on BTIF wrapper over Vela BT Framework Socket Client API.
5. And, we can also start working on bttool over Vela BT Framework Socket Client API later.
Signed-off-by: Haishen Zhang <zhanghaishen@xiaomi.com>
chejinxian1