Message packaging method, terminal device, and storage medium

Abstract

Embodiments of the present application relate to a message packetting method, a terminal device and a storage medium. The method receives a Bluetooth message sent by a user equipment; identifies source information of the Bluetooth message, adds the source information to the Bluetooth message, and stores the updated Bluetooth message in a first preset cache; reads the updated Bluetooth message from the first preset cache, obtains data and source information of the updated Bluetooth message, and allocates a corresponding second preset cache according to the source information; stores the data of the read updated Bluetooth message in the second preset cache corresponding to the source information according to a protocol packet structure, and obtains a corresponding protocol packet. The present application can packet different Bluetooth messages from the user equipment according to the source information of the Bluetooth messages, thereby avoiding packetting failure caused by packetting Bluetooth messages with different source information.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to a message packet assembly method, terminal device, and storage medium. Background Technology

[0002] Devices integrating the Wear Software Development Kit (WearSDK) (hereinafter referred to as WearSDK devices) can establish communication connections with multiple devices (such as mobile phones) or multiple applications (APPs) on a single device simultaneously. For example, a long protocol packet sent by an APP may be divided into multiple protocol packets. Each protocol packet is sent as multiple Bluetooth messages via the Bluetooth module. However, Bluetooth messages from multiple APPs may be sent to the WearSDK device alternately. When the WearSDK device reassembles Bluetooth messages from multiple APPs, it will reassemble multiple consecutively received Bluetooth messages without distinguishing between Bluetooth messages from different APPs. This causes the WearSDK device to lose packets due to verification errors after reassembling the Bluetooth messages from multiple APPs, resulting in packet reassembly failure and affecting the accurate transmission of data. Summary of the Invention

[0003] In view of the above, it is necessary to provide a message packet assembly method, terminal device, and storage medium to solve the problem of packet assembly failure when WearSDK devices assemble Bluetooth messages from multiple apps.

[0004] In a first aspect, embodiments of this application provide a message packet assembly method applied to a terminal device. The method includes: receiving a Bluetooth message sent by a user device; identifying source information of the Bluetooth message, adding the source information to the Bluetooth message, and storing the Bluetooth message in a first preset cache; reading the Bluetooth message from the first preset cache, obtaining the data of the Bluetooth message and the source information, and allocating a corresponding second preset cache according to the source information; and storing the read data of the Bluetooth message in the second preset cache corresponding to the source information according to the protocol packet structure to obtain a corresponding protocol packet.

[0005] When the above technical solution detects the presence of Bluetooth messages in the first preset cache, it reads the Bluetooth messages from the first preset cache, obtains the Bluetooth messages and source information from the read information, allocates different second preset caches according to the source information, stores the Bluetooth messages in the second preset cache corresponding to the source information, and obtains protocol packets by storing the read Bluetooth messages in the corresponding second preset cache according to the protocol packet structure. In this way, different Bluetooth messages from user devices can be distinguished and grouped according to the source information of the Bluetooth messages, avoiding the situation of packet grouping failure caused by grouping Bluetooth messages with different source information.

[0006] In one embodiment of this application, the method further includes: if it is determined that the protocol packets need to be assembled, determining the location marker of the protocol packets, and assembling the protocol packets according to the location marker to obtain a long protocol packet. The above technical solution, after completing the protocol packet, determines the location marker of the protocol packet and assembles the protocol packets according to the location marker to obtain a long protocol packet, thus realizing the application-level data packet assembly function and facilitating application invocation.

[0007] In one embodiment of this application, the protocol packet structure includes a protocol header, and determining to assemble the protocol packet includes: parsing the protocol header of the protocol packet to obtain a first flag bit; if the value of the first flag bit is True, then determining to assemble the protocol packet.

[0008] In one embodiment of this application, the location marker includes a first packet, a middle packet, and a last packet. The step of assembling the protocol packets according to their location markers to obtain a long protocol packet includes: sequentially combining the protocol packet marked as the first packet, the protocol packet marked as the middle packet, and the protocol packet marked as the last packet to obtain the long protocol packet. The above technical solution, by combining the protocol packet marked as the first packet, the protocol packet marked as the middle packet, and the protocol packet marked as the last packet, can achieve the function of assembling multiple protocol packets.

[0009] In one embodiment of this application, identifying the source information of the Bluetooth message and adding the source information to the Bluetooth message includes: identifying the Bluetooth channel information that sent the Bluetooth message and marking the Bluetooth channel information as a handle value; generating a header for the Bluetooth message based on the handle value and the frame length of the Bluetooth message; and updating the Bluetooth message by inserting the header into the head position of the Bluetooth message. The above technical solution, by marking the Bluetooth channel information as a handle value and generating a header for the Bluetooth message based on the handle value and the frame length of the Bluetooth message, can distinguish received Bluetooth messages.

[0010] In one embodiment of this application, if the first preset buffer includes multiple frames of Bluetooth messages, reading the Bluetooth messages from the first preset buffer includes: recording reading information for each frame of Bluetooth messages, the reading information including read data and unread data for each frame of Bluetooth messages; if the reading information of the previous frame of Bluetooth messages includes unread data, reading the previous frame of Bluetooth messages; if the reading information of the previous frame of Bluetooth messages does not include unread data, reading the current frame of Bluetooth messages. This technical solution, by recording the reading information of each frame of Bluetooth messages and reading the Bluetooth messages based on the reading information, ensures that no Bluetooth messages are missed during packet assembly.

[0011] In one embodiment of this application, the protocol packet structure includes a protocol header, a protocol packet length, and protocol data. The step of storing the read Bluetooth message data in a second preset cache corresponding to the source information according to the protocol packet structure to obtain the corresponding protocol packet includes: reading the protocol header from the first preset cache and storing the protocol header in the second preset cache; reading the protocol packet length from the first preset cache and storing the protocol packet length in the second preset cache; and reading the protocol packet length data from the first preset cache and storing the protocol packet length data in the second preset cache.

[0012] In one embodiment of this application, after reading the protocol header from the first preset cache and storing the protocol header in the second preset cache, the method further includes: setting a first timer and clearing the second preset cache after the first timer reaches a first preset timeout. The above technical solution, by storing the protocol header in the second preset cache, setting a first timer, and clearing the second preset cache after the first timer reaches the first preset timeout, avoids the program from continuously remaining in the packet assembly process of the current protocol packet.

[0013] In one embodiment of this application, the step of assembling the protocol packets into a long protocol packet based on the position marker of the protocol packet includes: if the position marker of the protocol packet is determined to be the first packet, determining whether a third preset cache exists; if the third preset cache does not exist, establishing the third preset cache, setting a second timer to count down, and releasing the memory of the third preset cache after the countdown time reaches the second preset countdown time; if the third preset cache exists, clearing the existing data in the third preset cache, resetting the second timer to count down; and storing the protocol packet with the position marker of the first packet into the third preset cache.

[0014] In one embodiment of this application, the step of assembling the protocol packets according to their position markers to obtain a long protocol packet includes: if the position marker of the protocol packet is determined to be an intermediate packet, determining whether the third preset cache exists; if the third preset cache exists, and the previous protocol packet stored in the third preset cache is a first packet or an intermediate packet, storing the protocol packet with the position marker of an intermediate packet in the third preset cache; if the third preset cache does not exist, discarding the protocol packet.

[0015] In one embodiment of this application, the step of assembling the protocol packets according to the position marker of the protocol packets to obtain a long protocol packet includes: if it is determined that the position marker of the protocol packet is the tail packet, determining whether the third preset cache exists; if the third preset cache exists, and the previous protocol packet stored in the third preset cache is the first packet or the middle packet, storing the protocol packet with the position marker of the tail packet into the third preset cache, parsing the function instruction from the long protocol packet and executing the function instruction, releasing the third preset cache, and deleting the second timer.

[0016] In one embodiment of this application, the method further includes: verifying the protocol packet according to a preset verification algorithm. The above technical solution verifies the protocol packet according to the preset verification algorithm, which can verify whether the protocol packet after Bluetooth message assembly is correct, so that the protocol packet can be discarded after verification error.

[0017] In one embodiment of this application, the method further includes: parsing functional instructions from the protocol packet or the long protocol packet, and executing the functional instructions.

[0018] Secondly, embodiments of this application provide a terminal device, which includes a memory and a processor: the memory is used to store program instructions; the processor is used to read and execute the program instructions stored in the memory, and when the program instructions are executed by the processor, the terminal device executes the above-described message packet assembly method.

[0019] Thirdly, embodiments of this application provide a computer-readable storage medium storing program instructions that, when executed on a terminal device, cause the terminal device to perform the aforementioned message packet assembly method.

[0020] Furthermore, the technical effects brought about by the second and third aspects can be found in the descriptions of the methods in the above-mentioned method section, and will not be repeated here. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A diagram illustrating the process of repackaging existing Bluetooth messages.

[0023] Figure 2 This is a diagram illustrating the application environment of the message packet assembly method in one embodiment of this application.

[0024] Figure 3 This is a schematic diagram of the Bluetooth message packet flow provided in one embodiment of this application.

[0025] Figure 4 This is a flowchart of a message packet assembly method provided in an embodiment of this application.

[0026] Figure 5 This is a schematic diagram of the Bluetooth message packet flow provided in another embodiment of this application.

[0027] Figure 6 This is a schematic diagram illustrating the packetization of Bluetooth messages according to an embodiment of this application.

[0028] Figure 7 This is a flowchart illustrating a method for assembling Bluetooth messages according to an embodiment of this application.

[0029] Figure 8 This is a flowchart illustrating a method for assembling protocol packets to obtain a long protocol packet, as provided in an embodiment of this application.

[0030] Figure 9 This is a schematic diagram of a terminal device provided in an embodiment of this application. Detailed Implementation

[0031] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used in this application's specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. It should be understood that, unless otherwise stated, " / " in this application means "or". For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. "At least one" refers to one or more. "More than one" refers to two or more. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, and a, b, and c (seven cases).

[0033] A device integrating a Wear Software Development Kit (WearSDK) (hereinafter referred to as a WearSDK device) can establish communication connections with multiple devices (such as mobile phones) or multiple applications (APPs) on a single device simultaneously. For example, a long protocol packet sent by an APP may be divided into multiple protocol packets. Each protocol packet is divided into multiple Bluetooth message frames when sent via the Bluetooth module. However, Bluetooth messages from multiple APPs may be sent alternately to the WearSDK device. When the WearSDK device reassembles Bluetooth messages sent by multiple APPs, it will reassemble multiple consecutively received Bluetooth messages and will not distinguish between Bluetooth messages from different APPs (see reference). Figure 1 As shown in the figure, the WearSDK device may lose packets due to verification errors after assembling Bluetooth messages from multiple apps, resulting in packet assembly failure and affecting the accurate transmission of data.

[0034] refer to Figure 2 The diagram illustrates an application environment for a message packet assembly method according to an embodiment of this application. The message packet assembly method is applied in a WearSDK device 10. The WearSDK device 10 can be a device that integrates a wearable device software development kit for interaction. The WearSDK device 10 also has Bluetooth functionality. In one embodiment of this application, the WearSDK device 10 can be a headset, speaker, watch, bracelet, or other device. The above examples are merely illustrative and are not limited to these in practical applications.

[0035] In one embodiment of this application, the WearSDK device 10 can communicate with multiple user devices 20 (user devices 20 can be multiple mobile phones, such as mobile phone 1 and mobile phone 2). In one embodiment of this application, the user device 20 includes a first Bluetooth module 21 and at least one APP 22, and the WearSDK device 10 includes a second Bluetooth module 11 and a WearSDK module 12. The APP in the user device 20 can send messages to the WearSDK device 10 through the first Bluetooth module 21. (See reference...) Figure 3 The diagram illustrates a Bluetooth message packet assembly process in one embodiment of this application. The APP 22 in the user equipment 20 can divide a long protocol packet to be sent into multiple shorter protocol packets and send the divided protocol packets to the WearSDK device 10 via the first Bluetooth module 21. When transmitting the protocol packets, the first Bluetooth module 21 can divide the protocol packet into multiple Bluetooth message frames according to the maximum message transmission length defined by the maximum transmission unit (MTU) of the first Bluetooth module 21, and send each Bluetooth message frame to the WearSDK device 10 via a Bluetooth channel, where each Bluetooth channel corresponds to one APP 22. In one embodiment of this application, the protocol packet includes a protocol packet structure, which includes a protocol header, a protocol packet length, and protocol data. The protocol header includes the APP's interaction information, the protocol packet length includes the data length information of the protocol packet, and the protocol data includes the data content of the protocol packet. Each Bluetooth message frame can carry the protocol header, protocol packet length, protocol data, and other content.

[0036] In one embodiment of this application, the second Bluetooth module 11 of the WearSDK device 10 receives Bluetooth messages sent by the user device 20, identifies the Bluetooth channel information that sent the Bluetooth messages, and marks the identified Bluetooth channel information as a handle value. The second Bluetooth module 11 sends the identified Bluetooth message and the corresponding handle value to the WearSDK module 12. The WearSDK module 12 assembles the received Bluetooth messages according to the handle value corresponding to the Bluetooth messages. In this way, the WearSDK module can distinguish and assemble Bluetooth messages from different apps according to the handle value.

[0037] To avoid package assembly failure.

[0038] In one embodiment of this application, WearSDK device 10 can also communicate with other WearSDK devices. For example, WearSDK device 10 can communicate with other WearSDK devices via a master-slave communication method. Another example is that WearSDK device 10 acts as a slave device, communicating with other WearSDK devices that act as masters.

[0039] The following will combine Figure 4 This application provides a flowchart of a message packet assembly method according to an embodiment. Figure 4 The example method includes one or more steps, but does not constitute a limitation of this application. Furthermore, the order of the steps in the method is merely illustrative and may be changed. Additional steps may be added or steps may be removed without departing from the disclosure of this application. The method specifically includes the following steps.

[0040] Step S401: Receive Bluetooth messages sent by the user equipment.

[0041] In one embodiment of this application, the Bluetooth message can be one of the following: setting sound effect information, querying device information, querying configuration information, or downloading an Over-the-Air Technology (OTA) upgrade package. The above example is merely illustrative, and is not limited to this in actual applications. The following uses a mobile phone as the user device, headphones as the WearSDK device, and Bluetooth messages such as setting sound effect information and querying device information as examples to illustrate the message packetization method of this application embodiment.

[0042] In one embodiment, the first app on the mobile phone (such as a music app) divides the long protocol packet for setting sound effect information into multiple shorter first protocol packets, and transmits the divided first protocol packets through a first Bluetooth module (such as...). Figure 1 The first Bluetooth module 21) sends the first protocol packet to the headset. When transmitting the first protocol packet, the first Bluetooth module divides the first protocol packet into multiple frames of first Bluetooth messages according to the maximum message transmission length defined by the maximum transmission unit of the first Bluetooth module, and sends each frame of first Bluetooth message to the headset through the first Bluetooth channel, wherein the first Bluetooth channel corresponds to the first APP.

[0043] A second app on the phone (such as a system settings app) divides the long protocol packet for querying device information into multiple shorter second protocol packets and sends these packets to the earphones via the first Bluetooth module. When transmitting the second protocol packets, the first Bluetooth module divides them into multiple frames of second Bluetooth messages according to the maximum message transmission length defined by the first Bluetooth module's maximum transmission unit. Each frame of the second Bluetooth message is then sent to the earphones via a second Bluetooth channel, which corresponds to the second app. In one embodiment of this application, both the first and second Bluetooth messages carry a protocol header, protocol packet length, and protocol data.

[0044] refer to Figure 3 The second Bluetooth module of the headphones (such as Figure 2 The second Bluetooth module 11) in the mobile phone receives the first Bluetooth message and the second Bluetooth message sent by the first Bluetooth module of the mobile phone.

[0045] Step S402: Identify the source information of the Bluetooth message, update the Bluetooth message by adding the source information to the Bluetooth message, and store the updated Bluetooth message in the first preset cache.

[0046] refer to Figure 5 The second Bluetooth module of the headphones (such as Figure 2 When the second Bluetooth module 11 in the headset receives the first Bluetooth message sent by the mobile phone, it identifies the Bluetooth channel information that sent the first Bluetooth message, marks the identified Bluetooth channel information as a first handle value, and sends the first Bluetooth message and the first handle value of the first Bluetooth message to the WearSDK module of the headset (e.g., Figure 2 The WearSDK module 12 of the headset receives a first Bluetooth message and a first handle value of the first Bluetooth message sent by the second Bluetooth module. Based on the first handle value and the frame length of the first Bluetooth message, the WearSDK module generates a header for the first Bluetooth message. The WearSDK module inserts the header of the first Bluetooth message into the header position of the first Bluetooth message to update the first Bluetooth message, and stores the updated first Bluetooth message in a first preset buffer (e.g., marked R_Buffer). In this embodiment, the first handle value in the header is used to indicate the source information of the first Bluetooth message. For example, the first handle value indicates that the first Bluetooth message originates from a first APP.

[0047] Similarly, when the second Bluetooth module of the headset receives the second Bluetooth message sent by the mobile phone, it identifies the Bluetooth channel information that sent the second Bluetooth message, marks the identified Bluetooth channel information as a second handle value, and sends the second Bluetooth message and the second handle value of the second Bluetooth message to the headset's WearSDK module. The headset's WearSDK module receives the second Bluetooth message and the second handle value sent by the second Bluetooth module, and generates a header for the second Bluetooth message based on the second handle value and the frame length of the second Bluetooth message. The headset's WearSDK module inserts the header of the second Bluetooth message into the header position of the second Bluetooth message to update the second Bluetooth message, and stores the updated second Bluetooth message in the first preset buffer R_Buffer. In this embodiment, the second handle value in the header is used to indicate the source information of the second Bluetooth message. For example, the second handle value in the header is used to indicate that the second Bluetooth message originates from a second APP.

[0048] In one embodiment of this application, the WearSDK module of the earphone updates the Bluetooth messages by inserting the received Bluetooth messages into the header according to the order of Bluetooth message reception, and stores the updated Bluetooth messages in the first preset buffer R_Buffer.

[0049] Step S403: Read Bluetooth messages from the first preset cache, obtain the data and source information of the Bluetooth messages from the read Bluetooth messages, and allocate different second preset caches according to different source information.

[0050] In one embodiment of this application, when the WearSDK module detects that there is a Bluetooth message in the first preset buffer R_Buffer, it reads the Bluetooth message from the first preset buffer R_Buffer, obtains the Bluetooth message data and the source information of the Bluetooth message from the read Bluetooth message, and allocates a second preset buffer according to the source information. For different source information, the WearSDK module can allocate different second preset buffers.

[0051] In this embodiment, when the WearSDK module detects that a first Bluetooth message exists in the first preset cache R_Buffer, it reads the first Bluetooth message from the first preset cache R_Buffer, obtains the data of the first Bluetooth message and the first handle value of the first Bluetooth message from the read first Bluetooth message, and allocates a second preset cache corresponding to the first handle value according to the first handle value.

[0052] In this embodiment, when the WearSDK module detects that there is a second Bluetooth message in the first preset cache R_Buffer, it reads the second Bluetooth message from the first preset cache R_Buffer, obtains the data of the second Bluetooth message and the second handle value of the second Bluetooth message from the read second Bluetooth message, and allocates the second preset cache corresponding to the second handle value according to the second handle value.

[0053] Step S404: Store the read data in the second preset cache corresponding to the source information according to the protocol packet structure to obtain the protocol packet.

[0054] In one embodiment of this application, the WearSDK module reads Bluetooth message data stored in a first preset cache, stores the read data in a second preset cache according to the protocol packet structure consisting of protocol header, protocol packet length, and protocol data, and then assembles the stored data into a protocol packet.

[0055] In this embodiment, the WearSDK module obtains the protocol header, protocol packet length, and protocol data from the data of the first Bluetooth message. It then stores the read data according to the protocol packet structure in a second preset buffer corresponding to the first handle value, and finally assembles the stored data into a first protocol packet. In this embodiment, the WearSDK module obtains the protocol header, protocol packet length, and protocol data from the data of the second Bluetooth message. It then stores the read data according to the protocol packet structure in a second preset buffer corresponding to the second handle value, and finally assembles the stored data into a second protocol packet.

[0056] In one embodiment of this application, the WearSDK module stores the protocol packets obtained after assembling Bluetooth messages in a first preset cache.

[0057] Step S405: Determine whether to reassemble the protocol packets. If the protocol packets are to be reassembled, proceed to step S406; otherwise, if the protocol packets are not to be reassembled, proceed to step S407.

[0058] In one embodiment of this application, the WearSDK module reads protocol packets from a first preset cache and parses the protocol header of the protocol packets to determine whether to reassemble the protocol packets. In another embodiment of this application, the WearSDK module parses the protocol header of the protocol packets to obtain a first flag bit. If the value of the first flag bit is a preset first value (such as a False value), it is determined that the protocol packets will not be reassembled; if the value of the first flag bit is a preset second value (such as a True value), it is determined that the protocol packets will be reassembled.

[0059] In this embodiment, the WearSDK module parses the header of the first protocol packet to obtain a first flag bit. If the value of the first flag bit of the first protocol packet is False, it is determined that the first protocol packet will not be reassembled; if the value of the first flag bit of the first protocol packet is True, it is determined that the first protocol packet will be reassembled. Similarly, the WearSDK module parses the header of the second protocol packet to obtain a first flag bit. If the value of the first flag bit of the second protocol packet is False, it is determined that the second protocol packet will not be reassembled; if the value of the first flag bit of the second protocol packet is True, it is determined that the second protocol packet will be reassembled.

[0060] Step S406: Determine the location marker of the protocol packet, and assemble the protocol packets according to the location marker to obtain a long protocol packet.

[0061] In one embodiment of this application, after determining that protocol packets need to be assembled, the WearSDK module determines the position markers of the protocol packets from the protocol header. For example, according to the position of the protocol packets in the long protocol packet, the position markers of the protocol packets are divided into first packet, middle packet, and last packet, where the first packet indicates that the protocol packet is located at the beginning of the long protocol packet, the last packet indicates that the protocol packet is located at the end of the long protocol packet, and the middle packet indicates that the protocol packet is located in the middle position between the beginning and the end of the long protocol packet. Assembling the protocol packets according to their position markers to obtain the long protocol packet includes: sequentially combining the protocol packets marked as first packets, the protocol packets marked as middle packets, and the protocol packets marked as last packets to obtain the long protocol packet. In one embodiment of this application, the number of middle packets may include multiple. Assembling the protocol packets according to their position markers to obtain the long protocol packet includes: sequentially combining the protocol packets marked as first packets, all protocol packets marked as middle packets, and the protocol packets marked as last packets to obtain the long protocol packet.

[0062] In this embodiment, the WearSDK module sequentially combines the first protocol packet marked as the first packet, the first protocol packet marked as the middle packet, and the first protocol packet marked as the last packet to obtain the first long protocol packet; and sequentially combines the second protocol packet marked as the first packet, the second protocol packet marked as the middle packet, and the second protocol packet marked as the last packet to obtain the second long protocol packet.

[0063] Step S407: Parse the function instructions from the protocol packet or long protocol packet, and execute the corresponding function according to the function instructions.

[0064] In this embodiment, the WearSDK module parses the setting instructions corresponding to the sound effect setting function from the first protocol packet or the first long protocol packet, and sets the sound effect of the headphones according to the setting instructions; it also parses the query instructions corresponding to the device information query function from the second protocol packet or the second long protocol packet, and queries the device information of the headphones according to the query instructions.

[0065] In one embodiment of this application, after step S404, the method further includes: verifying the protocol packet according to a preset verification algorithm. In one embodiment of this application, the preset verification algorithm includes one of Cyclic Redundancy Check (CRC) algorithm, parity check algorithm, and Hamming code check algorithm. In this embodiment, verifying the protocol packet according to the preset verification algorithm can verify whether the protocol packet after Bluetooth message assembly is correct; if incorrect, the protocol packet is discarded.

[0066] In the above embodiments of this application, when the WearSDK module detects the presence of Bluetooth messages in the first preset cache, it reads the Bluetooth messages from the first preset cache, obtains the Bluetooth messages and source information from the read information, allocates different second preset caches according to the source information, stores the Bluetooth messages in the second preset cache corresponding to the source information, and obtains protocol packets by storing the read Bluetooth messages in the corresponding second preset caches according to the protocol packet structure. This allows for the differentiation and packetization of Bluetooth messages from different apps based on their source information (see reference). Figure 6 As shown in the diagram, this avoids packet assembly failures caused by reassembling continuously sent Bluetooth messages. Simultaneously, after completing a protocol packet, the WearSDK module determines its location marker and reassembles it into a long protocol packet based on this marker. This implements application-level data packet assembly functionality, facilitating application calls.

[0067] refer to Figure 7 The diagram shown is a flowchart of a method for assembling Bluetooth messages in a first preset cache according to an embodiment of this application. Specifically, it includes the following steps.

[0068] Step S701: Determine that a Bluetooth message exists in the first preset cache.

[0069] In one embodiment of this application, the WearSDK module stores each received Bluetooth message frame in a first preset buffer and records the read information for each Bluetooth message frame. The read information includes the read data and unread data of the Bluetooth message.

[0070] Step S702: Determine whether the previous frame of Bluetooth message in the first preset buffer has been completely read. If the previous frame of Bluetooth message has been completely read, proceed to step S703; if the previous frame of Bluetooth message has not been completely read, proceed to step S704.

[0071] In one embodiment of this application, if it is determined from the reading information of the previous Bluetooth message frame that there is unread information in the previous Bluetooth message frame, the WearSDK module determines that the previous Bluetooth message frame has not been read completely; if it is determined from the reading information of the current Bluetooth message frame that there is no unread information in the previous Bluetooth message frame, the WearSDK module determines that the previous Bluetooth message frame has been read completely.

[0072] Step S703: Read the current frame Bluetooth message from the first preset buffer and determine whether the current frame Bluetooth message has a header. If the current frame Bluetooth message has a header, proceed to step S704; if the current frame Bluetooth message does not have a header, proceed to step S719.

[0073] Step S704: Obtain the handle value from the current frame Bluetooth message or the previous frame Bluetooth message, and determine the second preset cache corresponding to the handle value.

[0074] In one embodiment of this application, the WearSDK module establishes a second preset cache corresponding to the handle value in the header of each acquired Bluetooth message frame. The second preset cache can be a structure. If the second preset cache corresponding to the handle value of the current Bluetooth message frame already exists, it is directly acquired; if the second preset cache corresponding to the handle value of the current Bluetooth message frame does not exist, it is created.

[0075] Step S705: Determine whether the previous protocol packet in the second preset buffer has been successfully assembled. If the previous protocol packet has been successfully assembled, proceed to step S706; if the previous protocol packet has not been successfully assembled, proceed to step S708.

[0076] In one embodiment of this application, the WearSDK module records the packet assembly status of each protocol packet, wherein the packet assembly status includes the status of reading the protocol packet length (indicating that the current status is that the WearSDK module is reading the protocol packet length), the status of reading the protocol packet data (indicating that the current status is that the WearSDK module is reading the protocol packet data), and the packet assembly completion status. If it is determined that the packet assembly status of the previous protocol packet in the second preset cache is a completion status, it is determined that the previous protocol packet is assembled successfully; if it is determined that the packet assembly status of the previous protocol packet in the second preset cache is not a completion status (such as the status of reading the protocol packet length or the status of reading the protocol packet data), it is determined that the previous protocol packet is not assembled successfully.

[0077] Step S706: Read the data of the current frame Bluetooth message from the first preset buffer and determine whether the Bluetooth message data contains a protocol header. If the Bluetooth message data contains a protocol header, proceed to step S707; if the Bluetooth message data does not contain a protocol header, proceed to step S719. Step S707: Store the protocol header in the second preset buffer, set the first timer, and clear the second preset buffer after the first timer reaches the first preset timeout period.

[0078] In this embodiment, the protocol header is stored in a second preset cache, a first timer is set, and the second preset cache is cleared after the first timer reaches a first preset timeout, so as to prevent the program from staying in the current protocol packet assembly process.

[0079] Step S708: Determine whether the packet assembly status of the previous frame protocol packet is in the state of reading the protocol packet length. If the packet assembly status of the previous frame protocol packet is in the state of reading the protocol packet length, proceed to step S709; if the packet assembly status of the previous frame protocol packet is not in the state of reading the protocol packet length, proceed to step S711.

[0080] Step S709: Read the data of the current frame Bluetooth message from the first preset buffer, and determine whether the data of the current frame Bluetooth message contains a protocol packet length. If a protocol packet length exists, proceed to step S710; otherwise, proceed to step S719.

[0081] Step S710: Store the protocol packet length in the data of the current frame Bluetooth message into the second preset buffer.

[0082] Step S711: Determine that the packet assembly state of the previous frame protocol packet is in the state of reading protocol packet data.

[0083] In one embodiment of this application, if it is determined that the packet assembly state of the previous frame protocol packet is in the state of reading protocol packet data, the WearSDK module determines that the length of the data read from the current frame Bluetooth message is less than the protocol packet length.

[0084] Step S712: Read Bluetooth message data from the first preset buffer and determine whether the length of the read data is greater than or equal to the protocol packet length. If the length of the read data is greater than or equal to the protocol packet length, proceed to step S713; if the length of the read data is less than the protocol packet length, proceed to step S719.

[0085] Step S713: Store the read data in the second preset cache.

[0086] Step S714: Confirm that a protocol packet has been assembled.

[0087] Step S715: Verify the protocol packet according to the preset verification algorithm and determine whether the verification passes. If the verification passes, proceed to step S716; if the verification fails, proceed to step S719.

[0088] In one embodiment of this application, the preset verification algorithm includes at least one of the following: cyclic redundancy check algorithm, parity check algorithm, and Hamming code check algorithm.

[0089] Step S716: Determine whether to reassemble the protocol packets. If the protocol packets are to be reassembled, proceed to step S717; otherwise, proceed to step S718.

[0090] In one embodiment of this application, the WearSDK module parses the protocol header of the protocol packet to obtain a first flag bit. If the value of the first flag bit is False, it is determined that the protocol packet will not be reassembled; if the value of the first flag bit is True, it is determined that the protocol packet will be reassembled.

[0091] Step S717: Assemble the protocol packets to obtain a long protocol packet.

[0092] In one embodiment of this application, the WearSDK module determines the position marker of the protocol packet from the protocol header, and sequentially combines the protocol packet with the position marker as the first packet, the protocol packet with the position marker as the middle packet, and the protocol packet with the position marker as the last packet to obtain a long protocol packet.

[0093] Step S718: Process protocol packets or long protocol packets.

[0094] In one embodiment of this application, processing a protocol packet or a long protocol packet includes: the WearSDK module sending the protocol packet to a business module (not shown in the figure) in WearSDK; the business module parsing the function instructions from the protocol packet and executing the corresponding function according to the function instructions.

[0095] Step S719: Process the remaining Bluetooth messages in the first preset cache.

[0096] In the above embodiments of this application, the WearSDK module can read the Bluetooth message data stored in the first preset cache, and store the read data in the second preset cache according to the protocol packet structure consisting of protocol header, protocol packet length, and protocol data, and then assemble the stored data into a protocol packet.

[0097] refer to Figure 8 The diagram shown is a flowchart of a method for assembling protocol packets to obtain a long protocol packet according to an embodiment of this application. Specifically, it includes the following steps.

[0098] Step S801: Read a protocol packet from the first preset buffer.

[0099] Step S802: Parse the protocol header of the protocol packet to determine whether to reassemble the protocol packet. If the protocol packet is to be reassembled, proceed to step S803; otherwise, proceed to step S804.

[0100] In one embodiment of this application, the WearSDK module parses the protocol header of the protocol packet to obtain a first flag bit. If the value of the first flag bit is False, it is determined that the protocol packet will not be reassembled; if the value of the first flag bit is True, it is determined that the protocol packet will be reassembled.

[0101] Step S803: Process the protocol packet.

[0102] In one embodiment of this application, the processing of the protocol packet includes: the WearSDK module sending the protocol packet to the business module in the WearSDK module, the business module parsing the function instructions (such as the setting instruction corresponding to the setting sound effect function or the query instruction corresponding to the query device information function) from the protocol packet, and executing the corresponding function according to the function instructions.

[0103] Step S804: Determine the location marker of the protocol packet.

[0104] In one embodiment of this application, the WearSDK module determines the location marker of the protocol packet from the protocol header. For example, according to the position of the protocol packet in the long protocol packet, the location marker of the protocol packet can be divided into the first packet, the middle packet, and the last packet.

[0105] Step S805: If the location of the protocol packet is determined to be the first packet, determine whether a third preset cache exists. If no third preset cache exists, proceed to step S806; if a third preset cache exists, proceed to step S808.

[0106] Step S806: Establish the third preset cache.

[0107] In this embodiment of the application, the third preset cache is used to store protocol packets, and the stored protocol packets are reassembled to obtain a long protocol packet.

[0108] Step S807: Set the second timer to start timing, and release the memory of the third preset cache after the timing time reaches the second preset timing time.

[0109] In this embodiment, a second timer is set to keep track of the time, and after the timer reaches the second preset time, the memory of the third preset cache is released to prevent the program from staying in the current long protocol packet assembly process.

[0110] Step S808: Clear the existing data in the third preset cache.

[0111] Step S809: Reset the second timer to start timing.

[0112] In this embodiment of the application, the second timer is reset to start the packet assembly process of a new long protocol packet.

[0113] Step S810: Store the protocol packet marked as the first packet in the third preset cache.

[0114] Step S811: If the location of the protocol packet is determined to be an intermediate packet, determine whether a third preset cache exists. If a third preset cache exists, proceed to step S812; otherwise, proceed to step S815.

[0115] Step S812: Determine whether the previous protocol packet stored in the third preset cache is the first packet or an intermediate packet. If the previous protocol packet stored in the third preset cache is the first packet or an intermediate packet, proceed to step S813. If the previous protocol packet stored in the third preset cache is neither the first packet nor an intermediate packet, proceed to step S814.

[0116] Step S813: Store the protocol packet whose location is marked as an intermediate packet into the third preset cache.

[0117] Step S814: Release the third preset buffer and delete the second timer.

[0118] Step S815: Discard the protocol packet.

[0119] Step S816: If the position of the protocol packet is determined to be the tail packet, determine whether a third preset cache exists. If a third preset cache exists, proceed to step S817; if a third preset cache does not exist, proceed to step S822.

[0120] Step S817: Determine whether the previous protocol packet stored in the third preset cache is the first packet or an intermediate packet. If the previous protocol packet stored in the third preset cache is the first packet or an intermediate packet, proceed to step S818. If the previous protocol packet stored in the third preset cache is neither the first packet nor an intermediate packet, proceed to step S821.

[0121] Step S818: Store the protocol packet whose position is marked as the tail packet into the third preset cache.

[0122] Step S819: Process the protocol packet.

[0123] The specific implementation details of step S819 are the same as those of step S803, and will not be repeated here.

[0124] Step S820: Release the third preset cache and delete the second timer.

[0125] Step S821: Release the third preset cache and delete the second timer.

[0126] Step S822: Discard the protocol packet.

[0127] In the above embodiments, after completing the protocol packet, the WearSDK module can determine the location marker of the protocol packet and assemble the protocol packet into a long protocol packet according to the location marker, thus realizing the packet assembly function.

[0128] The terminal devices involved in the embodiments of this application will be described below.

[0129] refer to Figure 9 The diagram shown is a hardware structure schematic of a terminal device provided in an embodiment of this application. The terminal device 100 may include a processor 110, an internal memory 130, an external memory interface 120, a display screen 140, and a sensor module 150. The sensor module 150 may include a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an accelerometer, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

[0130] It is understood that the structure illustrated in the embodiments of the present invention does not constitute a specific limitation on the terminal device 100. In other embodiments of this application, the terminal device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware. The terminal device 100 may be... Figure 2 WearSDK devices.

[0131] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0132] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0133] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are being used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0134] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0135] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the terminal device 100. In other embodiments of this application, the terminal device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0136] The terminal device 100 implements display functions through a GPU, a display screen 140, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 140 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0137] The display screen 140 is used to display images, videos, etc. The display screen 140 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a minimized display, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the terminal device 100 may include one or N display screens 140, where N is a positive integer greater than 1.

[0138] Internal memory 130 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM). The RAM may include static random-access memory (SRAM), dynamic random-access memory (DRAM), synchronous dynamic random-access memory (SDRAM), double data rate synchronous dynamic random-access memory (DDR SDRAM, such as fifth-generation DDR SDRAM, generally referred to as DDR5 SDRAM), etc. The NVM may include disk storage devices and flash memory. Flash memory can be classified according to its operating principle, including NOR FLASH, NAND FLASH, 3D NAND FLASH, etc.; according to the level of the storage cell, including single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), etc.; and according to the storage specification, including universal flash storage (UFS) and embedded multimedia card (eMMC), etc.

[0139] The random access memory can be directly read and written by the processor 110. It can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data.

[0140] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct reading and writing by the processor 110.

[0141] The external memory interface 120 can be used to connect to external non-volatile memory, thereby expanding the storage capacity of the terminal device 100. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be stored in the external non-volatile memory.

[0142] Internal memory 130 or external memory interface 120 is used to store one or more computer programs. The one or more computer programs are configured to be executed by processor 110. The one or more computer programs include multiple instructions, which, when executed by processor 110, can implement the message packet assembly method executed on terminal device 100 in the above embodiments, thereby realizing the message packet assembly function of terminal device 100.

[0143] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the message packet assembly method described in the above embodiment.

[0144] In addition, some embodiments of this application also provide an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor can execute the computer execution instructions stored in the memory to cause the chip to execute the message packet assembly method in the above method embodiments.

[0145] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding method provided above, and will not be repeated here.

[0146] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0147] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus 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 device, or some features may be ignored or not executed. Furthermore, the mutual 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.

[0148] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application 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 units described above can be implemented in hardware or as software functional units.

[0149] 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 readable storage medium. Based on this understanding, the technical solutions of some embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0150] The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the above preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of this application should not depart from the spirit and scope of the technical solutions of this application.

Claims

1. A message packet assembly method, applied to a terminal device, characterized in that, The method includes: Receive Bluetooth messages sent by user equipment through different Bluetooth channels; Identifying the source information of the Bluetooth message includes: identifying the Bluetooth channel information that sent the Bluetooth message, marking the Bluetooth channel information as a handle value, and indicating the source information through the handle value; Based on the handle value and the frame length of the Bluetooth message, the header of the Bluetooth message is generated, and the Bluetooth message is updated by inserting the header into the head position of the Bluetooth message, and the Bluetooth message is stored in the first preset cache; Read the Bluetooth message from the first preset cache, obtain the data of the Bluetooth message and the source information, and allocate a corresponding second preset cache according to the source information, including: if the second preset cache corresponding to the handle value does not exist, create a second preset cache corresponding to the handle value; The data of the read Bluetooth message is stored in a second preset cache corresponding to the source information according to the protocol packet structure to obtain the corresponding protocol packet. When the Bluetooth message includes a protocol header, a first timer is set when the protocol header is stored in the second preset cache, and the second preset cache is cleared after the first timer reaches a first preset timeout. If the Bluetooth message does not contain the protocol header, the remaining Bluetooth messages in the first preset cache are processed.

2. The message packet assembly method as described in claim 1, characterized in that, The method further includes: When determining to assemble the protocol packets, the location marker of the protocol packets is determined, and the protocol packets are assembled according to the location marker to obtain a long protocol packet.

3. The message packet assembly method as described in claim 2, characterized in that, The step of determining to assemble the protocol packets includes: The protocol header of the protocol packet is parsed to obtain a first flag bit. If the value of the first flag bit is a preset value, then it is determined that the protocol packet will be assembled.

4. The message packet assembly method as described in claim 2, characterized in that, The location markers include a first packet, a middle packet, and a last packet. The process of assembling the protocol packets according to their location markers to obtain a long protocol packet includes: The protocol packet marked as the first packet, the protocol packet marked as the middle packet, and the protocol packet marked as the last packet are combined sequentially to obtain a long protocol packet.

5. The message packet assembly method as described in claim 1, characterized in that, If the first preset cache includes multiple Bluetooth message frames, reading the Bluetooth message from the first preset cache includes: Record the reading information for each Bluetooth message frame, including the read data and unread data for each Bluetooth message frame; If the read information of the previous Bluetooth message frame of the current frame includes unread data, then read the previous Bluetooth message frame. If the reading information of the previous Bluetooth message frame does not include unread data, then read the current Bluetooth message frame.

6. The message packet assembly method as described in claim 1, characterized in that, The protocol packet structure includes a protocol header, a protocol packet length, and protocol data. The step of storing the read Bluetooth message data in a second preset cache corresponding to the source information according to the protocol packet structure to obtain the corresponding protocol packet includes: Read the protocol header from the first preset cache and store the protocol header in the second preset cache; Read the protocol packet length from the first preset cache and store the protocol packet length in the second preset cache; Read the protocol packet length data from the first preset cache and store the protocol packet length data in the second preset cache.

7. The message packet assembly method as described in claim 2, characterized in that, The step of assembling the protocol packets according to their position markers to obtain a long protocol packet includes: If the location of the protocol packet is determined to be the first packet, determine whether a third preset cache exists; If the third preset cache does not exist, the third preset cache is created, a second timer is set to count down, and the memory of the third preset cache is released after the countdown time reaches the second preset countdown time. If the third preset cache exists, clear the existing data in the third preset cache and reset the second timer to start timing; The protocol packet marked as the first packet at the specified location is stored in the third preset cache.

8. The message packet assembly method as described in claim 7, characterized in that, The step of assembling the protocol packets according to their position markers to obtain a long protocol packet includes: If the location of the protocol packet is determined to be an intermediate packet, determine whether the third preset cache exists; If the third preset cache exists, and the previous protocol packet stored in the third preset cache is the first packet or an intermediate packet, the protocol packet marked as an intermediate packet is stored in the third preset cache; If the third preset cache does not exist, the protocol packet is discarded.

9. The message packet assembly method as described in claim 8, characterized in that, The step of assembling the protocol packets according to their position markers to obtain a long protocol packet includes: If the location of the protocol packet is determined to be the tail packet, determine whether the third preset cache exists; If the third preset cache exists, and the previous protocol packet stored in the third preset cache is the first packet or the middle packet, the protocol packet marked as the tail packet is stored in the third preset cache, the function instruction is parsed from the long protocol packet and executed, the third preset cache is released, and the second timer is deleted.

10. The message packet assembly method as described in claim 1, characterized in that, The method further includes: The protocol packet is verified according to a preset verification algorithm.

11. The message packet assembly method as described in claim 2, characterized in that, The method further includes: The function instructions are parsed from the protocol packet or the long protocol packet and then executed.

12. A terminal device, characterized in that, The terminal device includes a memory and a processor: The memory is used to store program instructions; The processor is configured to read and execute the program instructions stored in the memory, and when the program instructions are executed by the processor, the terminal device performs the message packet assembly method as described in any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program instructions that, when executed on a terminal device, cause the terminal device to perform the message packet assembly method as described in any one of claims 1 to 11.

Images