Bluetooth communication method, device and electronic equipment based on cross-application

Abstract

The application is suitable for the technical field of communication, and provides a Bluetooth communication method and device based on cross-application and electronic equipment. The method is applied to the electronic equipment, a plurality of application programs are installed in the electronic equipment, and the application programs perform data communication with a Bluetooth device through the electronic equipment. The method comprises the following steps: obtaining a communication data packet from the Bluetooth device; wherein the communication data packet comprises all data to be communicated generated by the Bluetooth device; for each application program, determining target data corresponding to the application program from the communication data packet according to data declaration information corresponding to the application program; wherein the data declaration information represents the attributes of the data required by the application program; and pushing the target data to the application program. By generating personalized target data for different Apps, the target data can be accurately pushed to different Apps, so that the precision and efficiency of Bluetooth communication are improved.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and in particular relates to a Bluetooth communication method, device and electronic device based on cross-application. Background Technology

[0002] When multiple apps on a mobile device connect to the same BLE (Bluetooth Low Energy) device simultaneously, they mostly rely on the system's native GATT (Generic Attribute Profile) multiplexing capability.

[0003] Traditional system-level BLE multiplexing suffers from problems such as high power consumption and inability to distribute data differently, which affects the accuracy and efficiency of Bluetooth communication. Summary of the Invention

[0004] This application provides a cross-application Bluetooth communication method, apparatus, and electronic device to improve the efficiency and accuracy of Bluetooth communication.

[0005] In a first aspect, embodiments of this application provide a cross-application Bluetooth communication method applied to an electronic device, wherein the electronic device has multiple applications installed, and the applications communicate with a Bluetooth device via the electronic device; including: Obtain communication data packets from the Bluetooth device; wherein the communication data packets include all data to be communicated generated by the Bluetooth device; For each application, the target data corresponding to the application is determined from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application; The target data is pushed to the application.

[0006] Secondly, embodiments of this application provide a cross-application Bluetooth communication device applied to an electronic device. The electronic device has multiple applications installed, and these applications communicate with the Bluetooth device via the electronic device. The device includes: A data packet acquisition module is used to acquire communication data packets from the Bluetooth device; wherein the communication data packets include all data to be communicated generated by the Bluetooth device; A data determination module is used to determine, for each application, the target data corresponding to the application from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application; The data push module is used to push the target data to the application.

[0007] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the method described in the first aspect above.

[0010] In this embodiment, communication data packets can be periodically acquired from the Bluetooth device. These packets include all data generated by the Bluetooth device within a given period, allowing for one-time data acquisition and reducing power consumption from repeated acquisitions. Each application has its own data declaration information, which characterizes the attributes of the data required by the application (e.g., the required data type, sampling frequency, data precision, waveform integrity, etc.). For each application, the target data corresponding to the application is determined from the communication data packets based on its data declaration information, and then pushed to the application. This enables differentiated data extraction and delivery to the application, improving the efficiency and accuracy of Bluetooth communication. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a system architecture diagram provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the cross-application Bluetooth communication method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the cross-application Bluetooth communication method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the cross-application Bluetooth communication method provided in an embodiment of this application; Figure 5 This is an architecture diagram of the Bluetooth communication system provided in the embodiments of this application; Figure 6 This is a flowchart illustrating the cross-application Bluetooth communication method provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a cross-application Bluetooth communication device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0015] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0017] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0018] The cross-application Bluetooth communication method provided in this application can be applied to terminal devices such as mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, computers, servers, ultra-mobile personal computers (UMPCs), netbooks, robots, and personal digital assistants (PDAs). This application does not impose any restrictions on the specific type of terminal device.

[0019] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows: Application-layer persistent proxy service: A middleware service that runs in the user space of the terminal operating system, is maintained in the background by the system keep-alive mechanism, and is specifically responsible for the unified management of communication and data distribution of all BLE devices.

[0020] Data contract subscription mechanism: A set of standard rules and processes established by the proxy service for "data demand negotiation" between various apps and the proxy service. It represents the business needs of the app (such as "I want to see heart rate") through structured contract declarations, which are the data declaration information in this embodiment.

[0021] Currently, the mobile BLE device sharing mechanism relies on the system's native GATT multiplexing capability, which has significant drawbacks. For example, when multiple apps connect to the same BLE health device simultaneously, issues such as connection contention and exclusive conflicts are highly likely to occur. The system layer only supports raw broadcast pass-through without data semantic differentiation. All subscribing apps receive the complete raw data stream, leading to repeated parsing, redundant calculations, and doubled overall device power consumption. Furthermore, it cannot achieve personalized data accuracy adaptation for different applications.

[0022] This application addresses the problems of connection preemption conflicts, full raw stream broadcasting, repeated parsing, high power consumption, and inability to differentiate distribution in traditional system-level BLE multiplexing. By using application-layer persistent proxy services and data contract subscription mechanisms, it achieves unified management of a single connection, one-time parsing, and on-demand differentiated delivery of multiple streams, while taking into account both device sharing capabilities and terminal power consumption optimization.

[0023] The system architecture used in the embodiments of this application Figure 1 This is a system architecture diagram of the cross-application Bluetooth communication method according to an embodiment of this application. It includes a terminal 140, an Internet connection 130, a gateway 120, a server 110, etc.

[0024] Terminal 140 can take various forms, including desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. Terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data.

[0025] Server 110 refers to a computer system that can provide certain services to terminal 140, equivalent to the server in this application embodiment. Compared to ordinary terminal 140, server 110 has higher requirements in terms of stability, security, and performance. Server 110 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines), etc.

[0026] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal 140 to server 110 are forwarded to the corresponding server 110 via gateway 120. Messages sent from server 110 to terminal 140 are also forwarded to the corresponding terminal 140 via gateway 120.

[0027] General Description of Embodiments in this Application According to one embodiment of this application, a cross-application Bluetooth communication method is provided that does not rely on the system's native crude broadcast mechanism. Through exclusive connection, unified resolution, contract pruning, and differentiated distribution, it enables multiple apps to securely, with low power consumption, and personalizedly share the same BLE health device.

[0028] Figure 2 This is a flowchart illustrating a cross-application Bluetooth communication method, such as... Figure 2 As shown, a cross-application Bluetooth communication method according to one embodiment of this application may include: Step 210: Obtain communication data packets from the Bluetooth device; wherein, the communication data packets include all data to be communicated generated by the Bluetooth device; Step 220: For each application, determine the target data corresponding to the application from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application. Step 230: Push the target data to the application.

[0029] Steps 210-230 are described in detail below.

[0030] In step 210, the electronic device is a terminal carrier equipped with a Bluetooth communication hardware module, capable of running multiple applications, and able to host a proxy service in the background. For example, it could be a user's mobile phone or other terminal device. That is, the proxy service is an application-layer service running on the electronic device, and the two are related as one. The electronic device carries the unified management and control of the Bluetooth communication link, the parsing and processing of raw communication data packets, and the entire data distribution process across multiple applications; it is the main entity responsible for enabling cross-application sharing of Bluetooth devices.

[0031] Bluetooth devices are peripheral hardware that establish wireless connections with electronic devices via the Bluetooth Low Energy protocol, continuously generating raw data from business sensing and encapsulating it into communication data packets. Examples of Bluetooth devices include smart bracelets, smart light bulbs, and Bluetooth mice. Bluetooth devices establish a single communication link with electronic devices, eliminating the need for separate connections with multiple applications and thus avoiding conflicts caused by multiple devices vying for connections. For instance, a proxy service can exclusively control the BLE connection. This means that a persistent proxy service runs in the background of the electronic device's system, exclusively holding the BLE device's GATT connection. All upper-layer business apps no longer directly connect to the Bluetooth device, completely eliminating conflicts caused by multiple apps vying for connections and frequent disconnections and reconnections. This provides unified management of the Bluetooth connection lifecycle, keep-alive strategies, and reconnection mechanisms.

[0032] An application, or App, is upper-layer business software that runs within an electronic device and has differentiated business data usage needs. Different applications can independently define the various attributes of the data they need, and only receive data content that matches their own business requirements, without needing to receive all the raw data output by the Bluetooth device.

[0033] Communication data packets are transmission carriers formed by uniformly encapsulating all service data collected by Bluetooth devices. Each communication data packet completely carries all the raw data to be transmitted generated by the Bluetooth device, i.e., the data to be communicated. Electronic devices can receive communication data packets sent by Bluetooth devices in real time or at regular intervals. These communication data packets serve as a single data source for unified parsing and processing by the electronic device, avoiding the repeated acquisition of raw data through multiple paths.

[0034] In step 220, the data declaration information is a predefined and standardized data contract description information for each application. The data declaration information fully characterizes the various attributes of the data required by the corresponding application, such as the required data type, sampling frequency, data precision, and waveform completeness. The data declaration information serves as the basis for electronic devices to filter and tailor data, supporting differentiated data extraction.

[0035] Each app can have its own data declaration information. Apps can generate and submit standardized data declaration information to the proxy service based on their own business attributes, and independently subscribe to the required data types, sampling frequencies, data precision, and waveform completeness. For example, fitness apps can subscribe to only low-frequency heart rate data, while clinical medical apps can subscribe to only full-fidelity ECG (Electrocardiogram) waveform data, thus achieving semantic definition of business requirements.

[0036] The app can submit data declaration information when installed on an electronic device, or when Bluetooth communication is required. In this embodiment, the format of the data declaration information is not specifically limited. The data declaration information can be generated by the app or pre-stored in the app.

[0037] Target data refers to customized data content that an electronic device obtains by filtering and adapting from a complete communication data packet based on the data claim information corresponding to a single application. Target data aligns with the business usage standards of the corresponding application and is the dedicated data content ultimately pushed to the application. In other words, the data required by the app can be found from the complete communication data packet based on the data claim information, serving as the target data. For example, for a fitness app, if the data claim information indicates that the app needs low-frequency heart rate data, then low-frequency heart rate data can be found from the communication data packet as the target data.

[0038] In step 230, the Bluetooth device and the electronic device transmit raw communication data packets. For each App, the electronic device performs data filtering based on data declaration information to obtain the App's target data, and then pushes the target data in a personalized way to the corresponding App.

[0039] In this embodiment, applications of different business types can independently choose attribute combinations adapted to their own business scenarios to complete the construction of data declaration information. The processing method for electronic devices to determine target data from communication data packets can include various adaptation techniques. Electronic devices can extract target data by only trimming irrelevant fields within the communication data packets, or they can perform dynamic downsampling processing on the original data to obtain the target data, or they can simplify the original waveform data to generate the target data. The timing of pushing target data from electronic devices to applications can have various dynamic adjustment logics. Electronic devices can adjust the push interval based on the number of currently online applications, or dynamically adjust the push throughput rate based on the data accuracy requirements marked in the data declaration information. When there are no active applications, the data push frequency can be reduced or the push operation can be paused.

[0040] By uniformly acquiring complete communication data packets output by Bluetooth devices through electronic devices, and selectively extracting and pushing target data tailored to each application based on its independently configured data declaration information, connection contention conflicts arising from multiple applications directly connecting to Bluetooth devices can be avoided. Furthermore, by performing unified parsing processing on communication data packets only once, the computational overhead caused by multiple applications repeatedly parsing raw data is reduced, lowering the power consumption of electronic devices and enabling cross-application Bluetooth communication with differentiated acquisition of Bluetooth device data by multiple applications.

[0041] In one implementation, the method further includes: receiving and storing data claim information of the application in response to a Bluetooth communication request from the application.

[0042] Specifically, the application is upper-layer business software running within electronic devices that has differentiated Bluetooth sensor data usage needs. The application can proactively initiate requests to establish data interaction with Bluetooth devices, while simultaneously submitting standardized descriptions of the data required for its business; these standardized descriptions constitute the data declaration information. The Bluetooth communication request is an interactive request instruction sent by the application to the proxy service, requesting access to Bluetooth device sensor data. It can be used to trigger the proxy service to initiate the application's data subscription process.

[0043] Applications in electronic devices can send Bluetooth communication requests to a proxy service. For example, they can send a Bluetooth communication request upon completion of installation, or they can send a Bluetooth communication request at any time based on the user's actual needs. The Bluetooth communication request can include the application's data claim information. After responding to the Bluetooth communication request, the application can retrieve the data claim information from the request and store it.

[0044] Once stored, the data declaration information can continue to serve as the basis for electronic devices to filter and trim the original data in communication data packets, supporting the continuous operation of the differentiated data distribution logic throughout the entire process.

[0045] Application-initiated Bluetooth communication requests can carry various additional interactive information. For example, the request may include the application's own service type identifier, data access permission credentials, and instructions to update or replace data claims. Electronic devices can store data claims using various storage management methods. For instance, they can store data claims from different applications in separate partitions, establish a mapping between application identifiers and data claims for unified storage, set an expiration date for data claims, and periodically clean up expired content. Applications can update data claims using various mechanisms. For example, they can repeatedly initiate Bluetooth communication requests to submit updated data claims, send separate modification instructions to replace stored historical data claims, or send deregistration instructions to delete stored data claims.

[0046] In this embodiment, by responding to Bluetooth communication requests issued by applications and receiving stored data declaration information, the personalized data requirement standards of each application can be reserved in advance. This provides a stable basis for electronic devices to uniformly parse communication data packets and carry out differentiated data trimming, downsampling, and accurate push, thereby realizing a contractual interaction logic for multiple applications to subscribe to Bluetooth device data on demand.

[0047] In this embodiment, communication data packets can be periodically acquired from the Bluetooth device. These packets include all data to be communicated generated by the Bluetooth device within a certain period, enabling data acquisition to be performed only once and reducing the power consumption of repeated acquisitions. Each application has its own data declaration information, which is a standardized data contract declaration submitted by each upper-layer application based on its own business attributes, indicating the required data type, sampling frequency, data precision, waveform integrity, and other information. For each application, the target data corresponding to the application is determined from the communication data packets based on the application's corresponding data declaration information, and then the target data is pushed to the application. This enables differentiated data extraction and delivery to applications, improving the efficiency and accuracy of Bluetooth communication.

[0048] Figure 3 This is a flowchart illustrating a cross-application Bluetooth communication method, such as... Figure 3 As shown, a cross-application Bluetooth communication method according to one embodiment of this application may include: Step 310: Obtain communication data packets from the Bluetooth device; wherein, the communication data packets include all data to be communicated generated by the Bluetooth device; Step 320: Parse the communication data packets to obtain multiple frames of raw communication data; wherein, the raw communication data represents the data to be communicated generated by the Bluetooth device; Step 330: For each frame of raw communication data, determine the target communication data in the raw communication data according to the data declaration information corresponding to the application. Step 340: Determine the target data corresponding to the application based on the target communication data in the original communication data of each frame; Step 350: Push the target data to the application.

[0049] Steps 310 and 350 have been described in detail above and will not be repeated here. Steps 320-340 will be described in detail below.

[0050] In step 320, the communication data packet is a unified transmission carrier formed by the Bluetooth device integrating all data within a certain period of time. The communication data packet carries all the original content to be transmitted output by the Bluetooth device and is the sole data source for the electronic device to perform unified parsing processing, thus avoiding the duplicate data reception behavior caused by multiple applications individually obtaining the original data from peripherals.

[0051] Parsing processing refers to the decoding, verification, and structure conversion operations performed by electronic devices on communication data packets. For example, parsing processing can be performed by a proxy service within the electronic device. Parsing processing operates only on the communication data packet, breaking down the encapsulated transmission medium into recognizable, standardized raw communication data, eliminating the need for multiple applications to perform decoding operations independently. The raw communication data consists of single-frame standardized data units obtained after parsing the communication data packet, capable of completely reconstructing the underlying service information collected and generated by the Bluetooth device. A single communication data packet can include multiple frames of raw communication data; for example, if a Bluetooth device sends one communication data packet per second, the communication data packet may contain 60 frames of raw communication data.

[0052] In step 330, each application has its own data declaration information. This information fully records the attributes of the data required by the corresponding application and can serve as a criterion for distinguishing between valid data content and irrelevant redundant data content. For each application, the target communication data of that application can be determined from each frame of raw communication data.

[0053] The raw communication data serves as the basis for comparison with the matching data declaration information, while the target communication data is a data segment within a single frame of raw communication data that conforms to the constraints of the corresponding application's data declaration information. In other words, the target communication data is valid data content adapted to the application's business requirements within a single frame of data. For example, if the raw communication data contains low-frequency heart rate data and complete ECG waveform data, for a fitness app, the low-frequency heart rate data can be used as the target communication data.

[0054] In step 340, target communication data can be identified in each frame of raw communication data. Multiple frames of target communication data can be aggregated to form complete data content that can be pushed, i.e., the target data. The target data is a complete and customized data set formed by integrating multiple frames of target communication data. It can fully match the data usage requirements of the corresponding application and is the final data body pushed by the electronic device to the application.

[0055] For example, a resident proxy service inside an electronic device can undertake all parsing, frame-by-frame comparison, and data aggregation. This proxy service exclusively uses the communication link established with the Bluetooth device, uniformly receives communication data packets, completes global single-pass parsing, splits multiple frames of raw communication data, and then sequentially combines the data declaration information of each application to extract the target communication data within a single frame. Finally, the target communication data obtained by frame-by-frame filtering is integrated into the target data specific to the corresponding application.

[0056] Parsing and processing of communication data packets can encompass various standardized processing methods. These methods may include decoding the data packets, verifying the data packet transmission checksums, and converting binary transmission content into structured field information. The processing method for determining the target communication data within a single frame of raw communication data based on data declaration information can employ various adaptation logics. For example, it can remove irrelevant data fields based on the data type specified in the data declaration information, downsample and truncate the single frame of raw communication data based on the sampling frequency recorded in the data declaration information, and simplify the original waveform-related content based on the data integrity indicated in the data declaration information. The integration method for aggregating multiple frames of target communication data to generate target data can be flexibly adjusted according to the application's business requirements. Electronic devices can continuously splice multiple frames of target communication data to form a complete time-series data stream, or aggregate multiple frames of target communication data according to a fixed time-series window to form segmented target data.

[0057] In this embodiment, standardized raw communication data is obtained by uniformly parsing communication data packets. Valid target communication data is extracted frame by frame based on data declaration information and summarized to form the target data for the corresponding application. This approach can eliminate computational redundancy caused by repeated decoding of multiple applications based on a single global parsing, and accurately remove irrelevant redundant data through frame-by-frame fine-tuning, reducing the memory usage and data transmission bandwidth consumption of electronic devices, and stably achieving the processing effect of extracting differentiated data from multiple applications.

[0058] In one implementation, step 330 includes: segmenting the original communication data to obtain at least one byte block; wherein each byte block represents data corresponding to an attribute; determining a target byte block from the at least one byte block according to the data declaration information corresponding to the application; and performing format conversion processing on the target byte block to obtain the target communication data in the original communication data.

[0059] Specifically, raw communication data consists of standardized single-frame data units output after unified parsing and processing of communication data packets. These units carry complete low-level sensor information collected and generated by the Bluetooth device. As the input carrier for segmentation processing, raw communication data can be split according to data attributes; a single piece of raw communication data can be divided into multiple byte blocks.

[0060] Segmentation is the process by which electronic devices divide and segment raw communication data into individual frames. Segmentation can divide continuous data content according to the corresponding attribute dimensions, breaking down complete raw communication data containing multiple attribute information into independent units, facilitating subsequent targeted filtering based on data declaration information. A byte block is an independent unit obtained after segmentation of the raw communication data; a single byte block carries only the sensor data content corresponding to a single attribute. As the smallest unit for matching and comparing data declaration information, the byte block enables precise filtering of valid data at the attribute granularity. For example, it can be predefined that "the first byte is the heart rate flag, the second and third bytes are the heart rate value, and the fourth and fifth bytes are the step count," and the agent service can segment according to this definition.

[0061] The data declaration information fully records the various attributes corresponding to the data required by the application. For each frame of raw communication data, multiple byte blocks can be determined from the raw communication data according to the data declaration information, serving as target byte blocks. The target byte block is the data segment that matches the attribute constraints of the application's data declaration information among all byte blocks. The target byte block carries the attribute data required by the application's business and is the raw material for generating the target communication data.

[0062] After obtaining the target byte blocks, each block undergoes format conversion processing to transform it into target communication data. Format conversion is a data standardization operation performed by the electronic device on the selected target byte blocks. It converts segmented raw byte data into a data format with unified business readability, eliminating compatibility barriers between the underlying transmission byte format and the upper-layer application's data reading format. Target communication data is a standardized single-frame valid data segment generated after the target byte blocks have undergone format conversion. It possesses a unified and standardized data format and contains only the attributes required by the application, serving as the basic unit for summarizing and generating target data. For example, a proxy service can encapsulate fragmented data such as "heart rate 72" into a structured data object.

[0063] The segmentation of raw communication data can employ various attribute matching and splitting rules. Segmentation can be based on byte boundaries corresponding to data type attributes, byte lengths corresponding to sampling precision attributes, or byte intervals corresponding to waveform data segments. Target byte blocks selected based on data declaration information can adapt to various matching and judgment logics. Electronic devices can directly retain the corresponding byte blocks and discard the rest based on the required attributes recorded in the data declaration information, or perform interval truncation on the corresponding byte blocks based on the precision requirements marked in the data declaration information, or select only byte blocks corresponding to authorized attributes based on business permissions. The format conversion processing performed on the target byte blocks can include various standardized conversion methods. Format conversion processing can include conversion operations from binary bytes to structured text fields, transcoding operations from underlying transmission encoding to application recognition encoding, and standardized processing operations such as byte length regularization and unit conversion.

[0064] In this embodiment, by segmenting the original communication data into byte blocks according to attributes, filtering the target byte blocks according to the data declaration information and completing the format conversion to generate the target communication data, irrelevant data content can be accurately removed with single attribute data segmentation as the filtering granularity, further reducing the amount of data transmitted by electronic devices to upper-layer applications, uniformly outputting data formats that are compatible with the reading specifications of various applications, and improving the fineness and data adaptability of multi-application differentiated data distribution.

[0065] In one embodiment, the communication data packet includes a first checksum, which represents a checksum generated by the Bluetooth device through hashing all data to be communicated based on a preset checksum algorithm. After parsing the communication data packet to obtain the original communication data, the method further includes: hashing the original communication data based on the preset checksum algorithm to obtain a second checksum; if the first checksum and the second checksum are the same, then for each frame of original communication data, the target communication data in the original communication data is determined according to the data declaration information corresponding to the application.

[0066] Specifically, the communication data packet is a transmission carrier formed by the Bluetooth device integrating all sensor service data and embedding a verification identifier. It carries all the original data content to be transmitted from the Bluetooth device and the accompanying verification information, serving as the unified input data source for the electronic device to perform unified parsing and data verification. It can simultaneously provide complete service data and verification basis, supporting the simultaneous execution of the data integrity verification process and subsequent hierarchical data filtering process. The first verification code is a verification identifier generated by the Bluetooth device after performing a hash operation on all the data to be communicated according to a preset verification algorithm. The first verification code is transmitted to the electronic device synchronously along with the communication data packet, serving as a benchmark for comparing the integrity and correctness of the original communication data. It can be used to identify data loss, tampering, and other anomalies that occur during transmission.

[0067] The preset verification algorithm is a hash operation rule agreed upon in advance by the electronic device and the Bluetooth device. This algorithm ensures that the calculation logic of the Bluetooth device generating the checksum and the electronic device recalculating the checksum remains consistent, preventing normal data from being judged as abnormal data due to differences in the operation rules. This embodiment does not specifically limit the preset verification algorithm. The second checksum is a verification identifier obtained by the electronic device through hash processing of the parsed original communication data. The second checksum is generated using the same set of operation rules as the first checksum and can be directly compared for consistency to determine whether the original communication data is complete and has not been tampered with.

[0068] If the first and second verification codes match, it indicates that the original communication data is a complete set of data to be communicated generated by the Bluetooth device. The target communication data in the original communication data can be determined based on the data declaration information corresponding to the application. If the first and second verification codes do not match, it indicates that there is a problem with the original communication data. The target communication data in the original communication data cannot be determined based on the data declaration information corresponding to the application. In this case, a prompt message can be sent to the user to remind them to check the data.

[0069] When the two sets of check codes do not match, various exception handling logics can be used. The electronic device can discard all the original communication data of the current batch and wait for the Bluetooth device to resend the communication data packet, or it can record the current data exception log and continue to push it to the application, or it can adjust the Bluetooth transmission frequency to reduce the probability of subsequent data transmission errors.

[0070] In this embodiment, a first checksum generated by the Bluetooth device is carried within the communication data packet. After parsing the original communication data, the electronic device recalculates the second checksum and performs a consistency comparison. Only after the verification passes can the target communication data extraction operation be performed. This approach can identify abnormal data packets such as those with transmission distortion or data tampering in advance, avoiding redundant filtering operations based on erroneous original communication data, reducing the power consumption and computing power loss of electronic devices caused by invalid data processing, and ensuring the integrity and accuracy of the data distributed to various applications.

[0071] In one implementation, step 340 includes: downsampling the original communication data of each frame according to the acquisition frequency information corresponding to the application to obtain a target frame; wherein the acquisition frequency information characterizes the accuracy requirements of the application for the target data; and determining the target data corresponding to the application according to the target communication data in each target frame.

[0072] Specifically, communication data packets contain multiple frames of raw communication data. This raw communication data serves as the fundamental input for downsampling processing, providing complete raw data material for apps with varying precision requirements. The acquisition frequency information can be a constraint on the app's data precision within the data declaration information, characterizing the data sampling precision level required for the app's business operations. This guides electronic devices in performing time-series data simplification of the raw communication data, matching the differentiated data acquisition needs of different business scenarios. The higher the precision requirement of the target data for the application, the higher the acquisition frequency, meaning more target frames are needed.

[0073] Downsampling is a frame filtering and compression operation performed by electronic devices on multiple frames of raw communication data arranged in a time sequence based on the acquisition frequency information. It can eliminate redundant data frames that exceed the accuracy requirements of the application, reducing the data volume of the subsequent aggregated target data. The target frame is the raw communication data frame that remains after downsampling and meets the accuracy constraints of the acquisition frequency information. After obtaining the target frame, the target communication data corresponding to that target frame can be extracted from each target frame, and then the target communication data contained in multiple target frames can be integrated to form a customized complete data stream, i.e., the target data.

[0074] Acquisition frequency information can carry various forms of precision constraint expression. For example, acquisition frequency information can limit the standard of data output interval required by the application, or the standard of data frame density retained within a unit time sequence. It can also distinguish the differentiated precision levels corresponding to regular business scenarios and high-fidelity business scenarios. The downsampling processing performed by electronic devices can adopt various frame filtering logics. Downsampling processing can uniformly extract the original communication data frames as target frames at fixed intervals, or dynamically retain key frames and discard redundant frames in the stable range based on data fluctuation characteristics. It can also switch different intensity downsampling compression ratios according to the application's business permissions. For example, medical-grade apps require full fidelity, meaning they need a complete ECG waveform. A Bluetooth device might generate 512 data points per second. The proxy service receives these data points and sends all 512 points directly to the medical app without downsampling, allowing doctors to see every subtle waveform change. Fitness-grade apps, on the other hand, require lower precision. They only look at heart rate values, not the complete waveform. The proxy service receives the 512 data points and performs dynamic downsampling, taking one data point every ten (a downsampling rate of 10:1), or simply calculating an average. Ultimately, only the data point "heart rate 72" is sent to the fitness app. In other words, the fitness app may receive only 1 / 512 the amount of data as a medical app, eliminating the need for frequent large-volume data transfers between the phone and the fitness tracker, significantly reducing power consumption.

[0075] In this embodiment, the target frame is obtained by downsampling multiple frames of original communication data based on the acquisition frequency information corresponding to the App. Then, the target communication data inside the target frame is integrated to generate target data. This can reduce the amount of time-redundant data according to the accuracy requirements of different applications, further reduce the amount of data transmitted from electronic devices to Apps, reduce the power consumption caused by data transmission, and achieve differentiated data distribution effect of multiple Apps at the data timing accuracy level.

[0076] In this embodiment, communication data packets can be periodically acquired from the Bluetooth device. These packets include all data to be communicated generated by the Bluetooth device within a certain period, enabling data acquisition to be performed only once and reducing the power consumption of repeated acquisitions. Each application has its own data declaration information, which is a standardized data contract declaration submitted by each upper-layer application based on its own business attributes, indicating the required data type, sampling frequency, data precision, waveform integrity, and other information. For each application, the target data corresponding to the application is determined from the communication data packets based on the application's corresponding data declaration information, and then the target data is pushed to the application. This enables differentiated data extraction and delivery to applications, improving the efficiency and accuracy of Bluetooth communication.

[0077] Figure 4This is a flowchart illustrating a cross-application Bluetooth communication method, such as... Figure 4 As shown, a cross-application Bluetooth communication method according to one embodiment of this application may include: Step 410: Determine the application quantity information; wherein, the application quantity information represents the number of applications in the electronic device that communicate with the Bluetooth device. Step 420: Determine the data packet collection cycle based on the application quantity information; Step 430: Obtain communication data packets from the Bluetooth device according to the data packet acquisition cycle; Step 440: For each application, determine the target data corresponding to the application from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application. Step 450: Push the target data to the application.

[0078] Steps 440 and 450 have been described in detail above and will not be repeated here. Steps 410-430 will be described in detail below.

[0079] In step 410, the Bluetooth device is a peripheral hardware that relies on the Bluetooth Low Energy protocol to establish a single wireless connection with electronic devices, continuously generates raw sensor data, and encapsulates it into communication data packets. The application quantity information is the total number of applications currently initiating Bluetooth data communication requests, as statistically obtained by the electronic device. It directly reflects the current load scale of concurrent subscription services and is a core parameter for dynamically adjusting the Bluetooth data transmission rhythm.

[0080] Application quantity information can carry statistical identifiers across multiple dimensions. For example, statistical identifiers can represent the number of all applications currently in an active data subscription state; they can also represent the separate statistical counts of applications with high-fidelity data requirements and those with ordinary accuracy requirements; and they can simultaneously statistically analyze the trends of new and unsubscribed applications. By combining statistical identifiers from multiple dimensions, the final application quantity information can be determined. For example, weighted processing of statistical identifiers from different dimensions can be applied to obtain the application quantity information.

[0081] Figure 5 This is an architecture diagram of a Bluetooth communication system. Figure 5 In this context, an electronic device has N applications installed that need to communicate with a Bluetooth device; the number of applications is N.

[0082] In step 420, the data packet acquisition period is the time interval between two consecutive attempts by the electronic device to retrieve communication data packets from the Bluetooth device, calculated based on the application quantity information. The data packet acquisition period directly controls the frequency of communication data packet acquisition, achieving balanced Bluetooth transmission power consumption in multi-application sharing scenarios. In other words, the electronic device can uniformly manage the transmission throughput and sleep strategies of the Bluetooth connection.

[0083] Determine the current number of applications, calculate the scale of online applications, and match the corresponding data packet collection cycle. For example, a pre-defined correlation between the number of applications and the data packet collection cycle can be used to find the corresponding data packet collection cycle.

[0084] The matching data packet acquisition cycle of electronic devices can adopt a variety of adaptive adjustment logics. For example, the data packet acquisition cycle can be shortened as the application size represented by the application quantity information increases, thereby improving the real-time performance of data transmission, or it can be extended as the application size represented by the application quantity information decreases, thereby reducing the working frequency of the Bluetooth module.

[0085] In step 430, after obtaining the data packet acquisition period, communication data packets can be received periodically based on the data packet acquisition period. Electronic devices can acquire communication data packets according to the data packet acquisition period using various interaction modes. For example, the electronic device can actively poll the Bluetooth device to read communication data packets according to the data packet acquisition period, or it can send a data packet acquisition period configuration command to the Bluetooth device, which will then actively push communication data packets according to the configured period. Alternatively, an idle sleep period can be set within the data packet acquisition period, during which the interaction of communication data packets is suspended.

[0086] In this embodiment, by statistically analyzing the number of applications representing the scale of online communication applications and matching them with corresponding data packet collection cycles, communication data packets are obtained from the Bluetooth device according to the data packet collection cycle. This allows for dynamic adjustment of the data interaction frequency based on the actual load of multiple concurrent subscriptions, ensuring data acquisition needs of multiple applications while reducing overall power consumption caused by continuous operation of the Bluetooth module. It also enables dynamic adjustment of the Bluetooth throughput strategy based on the number of currently subscribed apps, and automatic frequency reduction and sleep mode when there are no subscriptions, ensuring dynamic power balance management in scenarios where multiple applications share a Bluetooth device.

[0087] In this embodiment, communication data packets can be periodically acquired from the Bluetooth device. These packets include all data to be communicated generated by the Bluetooth device within a certain period, enabling data acquisition to be performed only once and reducing the power consumption of repeated acquisitions. Each application has its own data declaration information, which is a standardized data contract declaration submitted by each upper-layer application based on its own business attributes, indicating the required data type, sampling frequency, data precision, waveform integrity, and other information. For each application, the target data corresponding to the application is determined from the communication data packets based on the application's corresponding data declaration information, and then the target data is pushed to the application. This enables differentiated data extraction and delivery to applications, improving the efficiency and accuracy of Bluetooth communication.

[0088] Figure 6 This is a flowchart illustrating a cross-application Bluetooth communication method, such as... Figure 6 As shown, a cross-application Bluetooth communication method according to one embodiment of this application may include: Step 610: Determine the data packet acquisition period based on the acquisition period information corresponding to each application; wherein, the acquisition period information represents the maximum acquisition period required by the application for communication data packets; Step 620: Obtain communication data packets from the Bluetooth device according to the data packet acquisition cycle; Step 630: For each application, determine the target data corresponding to the application from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application. Step 640: Push the target data to the application.

[0089] Steps 630 and 640 have been described in detail above and will not be repeated here. Steps 610 and 620 will be described in detail below.

[0090] In step 610, the application can pre-store collection cycle information representing its own data timeliness requirements. The collection cycle information can differ between different applications. The data declaration information may include the collection cycle information; that is, the collection cycle information can be the timeliness constraints synchronously submitted by each application through the data declaration information. The time corresponding to the collection cycle information is the longest data acquisition interval that the application can tolerate. In other words, the collection cycle information can reflect the minimum real-time standard of a single application, providing an individual requirement benchmark for calculating the globally unified data packet collection cycle.

[0091] The data packet acquisition cycle is a standardized data retrieval interval determined uniformly by the electronic device after considering the acquisition cycle information of all applications. As a unified data interaction timing constraint between the electronic device and the Bluetooth device, the data packet acquisition cycle can take into account the real-time requirements of all online applications and realize the control logic of dynamically adjusting the Bluetooth throughput strategy and balancing transmission accuracy and power consumption according to the needs of each application service.

[0092] For example, a resident agent service deployed inside an electronic device can retrieve the collection cycle information corresponding to all applications stored locally, determine the data packet collection cycle adapted to all applications based on the complete collection cycle information, and then periodically initiate data reading operations to the Bluetooth device according to the data packet collection cycle, thereby continuously obtaining the communication data packets output by the Bluetooth device.

[0093] The data collection cycle information can take many forms. For example, the data collection cycle information can directly indicate the maximum data acquisition interval allowed by the application, or it can be calculated by reverse conversion of the data sampling frequency to obtain the corresponding maximum collection interval. It can also distinguish between the regular business mode and the high real-time business mode and configure two different sets of data collection cycle information.

[0094] Electronic devices can use various calculation and judgment logics to determine the data packet acquisition period based on multiple acquisition period information. For example, electronic devices can select the period with the smallest value among all acquisition period information as the data packet acquisition period to meet the minimum real-time requirements of all applications; they can also perform weighted operations on multiple acquisition period information to obtain a compromise and suitable data packet acquisition period; or they can classify the acquisition period information into different levels and set priority data packet acquisition periods separately for applications with high real-time requirements.

[0095] In step 620, after obtaining the data packet acquisition period, communication data packets can be received periodically based on the data packet acquisition period. The electronic device can acquire communication data packets according to the data packet acquisition period using various interaction modes. For example, the electronic device can actively poll the Bluetooth device to read communication data packets according to the data packet acquisition period, or it can send a data packet acquisition period configuration command to the Bluetooth device, which will then actively push communication data packets according to the configured period. Alternatively, an idle sleep period can be set within the data packet acquisition period, during which the interaction of communication data packets is suspended.

[0096] In this embodiment, the global data packet collection cycle is determined by summarizing the collection cycle information of each application that represents its maximum collection interval. Then, communication data packets are obtained from the Bluetooth device according to the data packet collection cycle. This can simultaneously take into account the real-time data requirements of all online applications, avoid data lag caused by the mismatch between the unified collection cycle and the timeliness requirements of some applications, improve transmission accuracy when there are high precision requirements, and achieve ultimate power consumption balance in multi-App sharing scenarios.

[0097] In this embodiment, communication data packets can be periodically acquired from the Bluetooth device. These packets include all data to be communicated generated by the Bluetooth device within a certain period, enabling data acquisition to be performed only once and reducing the power consumption of repeated acquisitions. Each application has its own data declaration information, which is a standardized data contract declaration submitted by each upper-layer application based on its own business attributes, indicating the required data type, sampling frequency, data precision, waveform integrity, and other information. For each application, the target data corresponding to the application is determined from the communication data packets based on the application's corresponding data declaration information, and then the target data is pushed to the application. This enables differentiated data extraction and delivery to applications, improving the efficiency and accuracy of Bluetooth communication.

[0098] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0099] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0100] Description of apparatus and devices in embodiments of this application Reference Figure 7 , Figure 7 This is a schematic diagram of the structure of a cross-application Bluetooth communication device 700 provided in an embodiment of this application. The cross-application Bluetooth communication device 700 is applied to an electronic device, which has multiple applications installed. These applications communicate with a Bluetooth device via the electronic device. The device includes: The data packet acquisition module 701 is used to acquire communication data packets from the Bluetooth device; wherein, the communication data packets include all data to be communicated generated by the Bluetooth device; The data determination module 702 is used to determine the target data corresponding to each application from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application. The data push module 703 is used to push target data to the application.

[0101] In one example, the data determination module 702 includes: The data parsing unit is used to parse and process communication data packets to obtain multiple frames of raw communication data; wherein, the raw communication data represents the data to be communicated generated by the Bluetooth device; The data determination unit is used to determine the target communication data in each frame of raw communication data based on the data declaration information corresponding to the application. The target determination unit is used to determine the target data corresponding to the application based on the target communication data in the original communication data of each frame.

[0102] In one example, the data determination unit is specifically used for: The original communication data is segmented to obtain at least one byte block; each byte block represents data corresponding to an attribute. Based on the data declaration information corresponding to the application, determine the target byte block from at least one byte block; The target byte block is format-converted to obtain the target communication data from the original communication data.

[0103] In one example, the communication data packet includes a first checksum, which represents the checksum generated by the Bluetooth device through hashing all the data to be communicated based on a preset checksum algorithm. Also includes: The hash module is used to perform hash processing on the original communication data after parsing and processing the communication data packets to obtain the original communication data, based on a preset verification algorithm, to obtain the second verification code; The verification module is used to determine the target communication data in each frame of original communication data based on the data declaration information corresponding to the application, if the first verification code and the second verification code are the same.

[0104] In one example, the target determination unit is specifically used for: Based on the acquisition frequency information corresponding to the application, the original communication data of each frame is downsampled to obtain the target frame; where the acquisition frequency information represents the accuracy requirements of the application for the target data; Based on the target communication data in each target frame, determine the target data corresponding to the application.

[0105] In one example, it also includes: The declaration receiving module is used to receive and store the application's data declaration information in response to the application's Bluetooth communication request.

[0106] In one example, packet acquisition module 701 is specifically used for: Determine the application quantity information; where the application quantity information represents the number of applications in the electronic device that communicate with the Bluetooth device for data. Determine the data packet collection cycle based on the number of applications; According to the data packet acquisition period, communication data packets are obtained from the Bluetooth device.

[0107] In one example, packet acquisition module 701 is specifically used for: Based on the collection period information corresponding to each application, the data packet collection period is determined; whereby the collection period information represents the maximum collection period required by the application for communication data packets. According to the data packet acquisition period, communication data packets are obtained from the Bluetooth device.

[0108] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0109] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0110] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 800 of this embodiment includes: at least one processor 801 ( Figure 8 (Only one is shown in the diagram), memory 802, and computer program 803 stored in said memory 802 and executable on said at least one processor 801, wherein said processor 801 executes said computer program 803 to implement the steps of any of the above embodiments of the Bluetooth communication method based on cross-application.

[0111] Electronic device 800 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 801 and a memory 802. Those skilled in the art will understand that... Figure 8 This is merely an example of electronic device 800 and does not constitute a limitation on electronic device 800. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0112] The processor 801 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0113] In some embodiments, the memory 802 may be an internal storage unit of the electronic device 800, such as a hard disk or memory of the electronic device 800. In other embodiments, the memory 802 may be an external storage device of the electronic device 800, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 800. Furthermore, the memory 802 may include both internal and external storage units of the electronic device 800. The memory 802 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 802 can also be used to temporarily store data that has been output or will be output.

[0114] This application also provides an electronic device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0115] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0116] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.

[0117] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a photographic device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0118] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0119] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0121] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A Bluetooth communication method based on cross-application communication, characterized in that, The method is applied to an electronic device, which has multiple applications installed thereon, and the applications communicate data with a Bluetooth device through the electronic device; the method includes: Obtain communication data packets from the Bluetooth device; wherein the communication data packets include all data to be communicated generated by the Bluetooth device; For each application, the target data corresponding to the application is determined from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application; The target data is pushed to the application.

2. The method according to claim 1, characterized in that, The step of determining the target data corresponding to the application from the communication data packet based on the data declaration information corresponding to the application includes: The communication data packets are parsed to obtain multiple frames of raw communication data; wherein, the raw communication data represents the data to be communicated generated by the Bluetooth device; For each frame of the original communication data, the target communication data in the original communication data is determined according to the data declaration information corresponding to the application. Based on the target communication data in the original communication data of each frame, the target data corresponding to the application is determined.

3. The method according to claim 2, characterized in that, The step of determining the target communication data in the original communication data based on the data declaration information corresponding to the application includes: The original communication data is segmented to obtain at least one byte block; wherein each byte block represents data corresponding to an attribute; Based on the data declaration information corresponding to the application, the target byte block is determined from the at least one byte block; The target byte block is subjected to format conversion processing to obtain the target communication data in the original communication data.

4. The method according to claim 2, characterized in that, The communication data packet includes a first check code, which represents a check code generated by the Bluetooth device by hashing all the data to be communicated based on a preset check algorithm. After parsing the communication data packets to obtain the original communication data, the process further includes: Based on a preset verification algorithm, the original communication data is hashed to obtain a second verification code; If the first check code and the second check code are the same, then for each frame of the original communication data, the target communication data in the original communication data is determined according to the data declaration information corresponding to the application.

5. The method according to claim 2, characterized in that, The step of determining the target data corresponding to the application based on the target communication data in the original communication data of each frame includes: Based on the acquisition frequency information corresponding to the application, the original communication data of each frame is downsampled to obtain the target frame; wherein, the acquisition frequency information represents the accuracy requirements of the application for the target data; Based on the target communication data in each target frame, the target data corresponding to the application is determined.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: In response to a Bluetooth communication request from an application, the application's data claim information is received and stored.

7. The method according to any one of claims 1-5, characterized in that, The step of obtaining communication data packets from the Bluetooth device includes: Determine the application quantity information; wherein, the application quantity information represents the number of applications in the electronic device that communicate with the Bluetooth device; The data packet collection cycle is determined based on the number of applications. According to the data packet acquisition period, communication data packets are obtained from the Bluetooth device.

8. The method according to any one of claims 1-5, characterized in that, The step of obtaining communication data packets from the Bluetooth device includes: The data packet collection period is determined based on the collection period information corresponding to each application; wherein, the collection period information represents the maximum collection period required by the application for communication data packets; According to the data packet acquisition period, communication data packets are obtained from the Bluetooth device.

9. A Bluetooth communication device based on cross-application, characterized in that, The device is applied to an electronic device, which has multiple applications installed thereon, and these applications communicate with a Bluetooth device via the electronic device; the device includes: A data packet acquisition module is used to acquire communication data packets from the Bluetooth device; wherein the communication data packets include all data to be communicated generated by the Bluetooth device; A data determination module is used to determine, for each application, the target data corresponding to the application from the communication data packet based on the data declaration information corresponding to the application; wherein, the data declaration information characterizes the attributes of the data required by the application; The data push module is used to push the target data to the application.

10. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as claimed in any one of claims 1 to 8.

Images