Fix various compilation errors across bluetooth framework, service,
and stack layers including:
- Add missing function declarations and header includes
- Fix type mismatches and implicit function declarations
- Add missing macro definitions in dfx headers
- Add stub implementation for hid device interface
- Fix list utility inline function issues
Signed-off-by: openvela <openvela@xiaomi.com>
bug: v/84212
Rootcase: The lightweight sched_note_printf function in the NuttX backend does not
perform NULL safety checks for the %s format specifier. Passing a NULL pointer from
hsm_get_state_name leads to a NULL pointer dereference, triggering a data abort
exception on systems with memory protection (MMU/MPU) and causing a system crash.
Solution: This commit addresses the issue by modifying the HSM_SAFE_NAME macro to
use the ternary operator. It now explicitly returns the "None" string literal when
hsm_get_state_name returns NULL, guaranteeing that a valid, non-null C-string is always
passed to the logging function.
Signed-off-by: v-chenghuijin <v-chenghuijin@xiaomi.com>
bug: v/83955
Rootcause: euv_pipe_close records the address of the euv_pipe in the data field of each uv_pipe instance to be closed, which is used to release the euv_pipe instance after the close operation completes.
A scenario exists where calling euv_pipe_close followed by euv_pipe_read_stop or euv_pipe_read_start causes the client pipe's data field to be reset to NULL or the reader's address. This prevents the euv_pipe instance from being released after close completes.
This occurs because euv_pipe_read_stop does not check the uv_pipe's state before directly freeing cli_pipe.data, while euv_pipe_read_start only verifies whether cli_pipe is active. Both functions lack a check for the closing state.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
bug: v/80811
Rootcause: In certain scenarios, users of `euv_pipe` must ensure all UV requests have completed execution before releasing resources. Consequently, it is necessary to notify users that `euv_pipe` has been fully released after its close operation is completed, thereby permitting subsequent operational procedures to proceed. Support for the close callback has therefore been added.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Rootcause: The creation of the euv_pipe RPMSG Pipe is conditionally compiled based on the RPMSG configuration, whereas the Close behaviour lacks this restriction. Consequently, in certain scenarios, non-existent RPMSG pipes may be released, triggering an exception.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
in `thread_loop_work_sync`
Rootcause: Replace `zalloc` with the C standard library function `calloc` to avoid compilation errors.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Signed-off-by: miot-robot <miot-robot@xiaomi.com>
Rootcause: uv_loop_close() marks internal data structures as invalid (e.g., set to -1), but pending callbacks in the queue still reference these invalidated structures. When uv_run() is called later, it processes the queue using corrupted pointers, leading to segmentation faults and crashes. Solution: Introduce a new flag in uv_loop_close() to mark the loop as closed and check it in uv_run() and other loop-related functions to prevent execution of callbacks after closure, ensuring memory safety and avoiding invalid pointer access.
Signed-off-by: v-chenghuijin <v-chenghuijin@xiaomi.com>
Signed-off-by: miot-robot <miot-robot@xiaomi.com>
Rootcause: `uv_close` does not guarantee the order in which close callbacks run.
There is a case where `euv_pipe_close2` and `euv_pipe_close` are called in sequence: if the `uv_close` initiated by `euv_pipe_close` completes first and frees the `euv_pipe_t` instance, `euv_pipe_close2` must access the invaliad address during its execution.
Therefore, add a status flag to ensure the `euv_pipe_t` instance is freed safely.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Signed-off-by: miot-robot <miot-robot@xiaomi.com>
When the client clears resources, if tasks are still executing in the worker thread at that time, it will lead to a use-after-free issue.
Signed-off-by: liuxiang18 <liuxiang18@xiaomi.com>
The current execution time of `on_scan_result_cb` is excessively long. Replace `lib_dumpbuffer` with `BT_DUMPBUFFER` (disabled by default) to reduce callback execution time, thereby preventing watchdog timeouts.
Signed-off-by: liuxiang18 <liuxiang18@xiaomi.com>
Signed-off-by: miot-robot <miot-robot@xiaomi.com>
Rootcause: When a pipe connection is successfully established and ready to read data, a reader will be allocated to handle the reading process, and the reader will be associated with the pipe object. When it is necessary to stop reading from the pipe, the reader needs to be released. Specifically, when a pipe disconnection occurs, the allocated reader also needs to be released. However, when a disconnection is initiated by either end of the pipe, the other end may read the EOF symbol from the reader first, causing the pipe to be set to a non-active state. This prevents the current logic of first checking the pipe status before releasing the reader in euv_pipe_read_stop from releasing the reader.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
rootcause: it would leak pipe handle when connect and disconnect many time. client pipe would free pipe handle directly, which does not has handle->data.server pipe would free handle->data(euv connection) first when connected, then free pipe handle when closed.
Signed-off-by: chengkai <chengkai@xiaomi.com>
When adding service data to broadcast data, the data length only includes the length of the type and UUID, without the length of the data.
Signed-off-by: jialu <jialu@xiaomi.com>
Rootcause: In order to reduce the application's judgment on whether the connection is across cores, the original two types of socket pipe connection methods are encapsulated into one interface.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Move bt_time.h and bt_time.c from service to the common framework path, making
them publicly accessible for reuse. No functional changes were made to the APIs.
Signed-off-by: zhongzhijie1 <zhongzhijie1@xiaomi.com>
Rootcause: When using SPP capability in cross-core scenario, it is necessary to perform cross-core communication through RPMSG. Since the Bluetooth service does not know which pipe connection method the application uses when establishing an SPP connection, it waits for the application to connect using both local and RPMSG pipes, and closes the unused pipe after connecting. When not in a cross-core scenario, the Bluetooth service does not use both pipes, which causes the subsequent closing behavior to result in runtime errors, causing the Bluetooth thread to be cleared by the system, thereby stopping the Bluetooth service.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
rootcause: The callbacks list itself is not Locked protection and concurrent access
is incorrect, so releasing it must be done in the client thread.
Signed-off-by: duqunbo <duqunbo@xiaomi.com>
1. Add bt_config.h in uv_thread_loop.c
2. Follow the changs on Vela to redefine the prio definition
Signed-off-by: Haishen Zhang <zhanghaishen@xiaomi.com>
Rootcause: bt_list_add_tail would malloc a new node to save data,
list_delete, however, would not free the previous node.
To solve the memory leak, we use list_add_head and list_add_tail
isdead of bt_list_add_head and bt_list_add_tail
Signed-off-by: Zihao Gao <gaozihao@xiaomi.com>
dependson:4036148
1. Enable Socket(AF_INET) first on Android
2. Fix the improper definition of Struct over Socekt between 64 bits and 32 bits system.
3. Modify the bttool to let it work similar to Vela
Signed-off-by: Haishen Zhang <zhanghaishen@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>
huangyulong3