A firmware upgrade method and system

Abstract

This specification provides a firmware upgrade method and system. The method, executed by a mobile terminal, includes: acquiring firmware data; generating target image data based on the firmware data; in response to an established communication connection between the mobile terminal and a target device and the mobile terminal triggering an audio playback session, transmitting the target image data to the target device via a data transmission channel; and controlling the target device to perform a firmware upgrade based on the target image data. The method, executed by the target device, includes: receiving target image data transmitted during an audio playback session with the mobile terminal via a data transmission channel, wherein the target image data encapsulates firmware data; decoding the target image data to obtain the firmware data; and performing the upgrade using the firmware data.

Description

Technical Field

[0001] This manual relates to the field of embedded devices, and in particular to a firmware upgrade method and system. Background Technology

[0002] In the field of embedded device technology, as embedded devices become increasingly complex, firmware upgrades are frequently required after product release to fix defects or add new features. Currently, the mainstream Bluetooth firmware upgrade methods include upgrades based on Bluetooth Low Energy (BLE), which has low power consumption but limited transmission bandwidth; when the firmware is large, the upgrade time can be as long as 15-30 minutes, severely impacting user experience. Another method is based on a custom classic Bluetooth protocol. While high-speed transmission can be achieved on the Android platform through open interfaces, on the iOS platform, it requires Made for iPhone (MFi) certification to use classic Bluetooth for custom data transmission. This certification process is lengthy and costly, posing significant challenges to product time-to-market and cost control. Therefore, how to achieve a cross-platform firmware upgrade solution that combines transmission speed and reliability without relying on specific platform certifications has become a pressing technical problem in this field. Summary of the Invention

[0003] This specification provides one or more embodiments of a firmware upgrade method. The firmware upgrade method is executed by a mobile terminal and includes: acquiring firmware data; generating target image data based on the firmware data; in response to a communication connection being established between the mobile terminal and a target device and the mobile terminal triggering an audio playback session, transmitting the target image data to the target device via a data transmission channel; and controlling the target device to perform a firmware upgrade based on the target image data.

[0004] This specification provides one or more embodiments of a firmware upgrade method. The firmware upgrade method is executed by a target device and includes: receiving target image data transmitted during an audio playback session with a mobile terminal via a data transmission channel, wherein the target image data encapsulates firmware data; decoding the target image data to obtain the firmware data; and performing an upgrade using the firmware data.

[0005] One embodiment of this specification provides a firmware upgrade system applied to a mobile terminal, comprising: an acquisition module configured to acquire firmware data; a generation module configured to generate target image data based on the firmware data; a transmission module configured to transmit the target image data to the target device via a data transmission channel in response to the establishment of a communication connection between the mobile terminal and a target device and the triggering of an audio playback session by the mobile terminal; and a control module configured to control the target device to perform a firmware upgrade based on the target image data.

[0006] One embodiment of this specification provides a firmware upgrade system applied to a target device, comprising: a receiving module configured to receive target image data transmitted in an audio playback session with a mobile terminal via a data transmission channel, wherein firmware data is encapsulated within the target image data; a decoding module configured to decode the target image data to obtain the firmware data; and an upgrade module configured to perform an upgrade using the firmware data.

[0007] This specification provides an electronic device according to one or more embodiments, including at least one processor and at least one memory; the at least one memory is used to store computer instructions; the at least one processor is used to execute at least a portion of the computer instructions to implement the firmware upgrade method described above.

[0008] This specification provides one or more embodiments of a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions from the storage medium, the computer executes a firmware upgrade method. Attached Figure Description

[0009] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0010] Figure 1 These are schematic diagrams illustrating application scenarios of the firmware upgrade system based on some embodiments of this specification; Figure 2A This is an exemplary block diagram of a firmware upgrade system applied to a mobile terminal, according to some embodiments of this specification; Figure 2B This is an exemplary block diagram of a firmware upgrade system applied to a target device, according to some embodiments of this specification; Figure 3 This is an exemplary flowchart of a firmware upgrade method performed by a mobile terminal according to some embodiments of this specification; Figure 4 These are exemplary schematic diagrams illustrating the determination of target image data according to some embodiments of this specification; Figure 5 This is an exemplary flowchart of a firmware upgrade method performed by a target device according to some embodiments of this specification. Detailed Implementation

[0011] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0012] Figure 1 This is a schematic diagram illustrating an application scenario of a firmware upgrade system based on some embodiments of this specification.

[0013] like Figure 1 As shown, the application scenario 100 of the firmware upgrade system includes target device 110, network 120, processing device 130, storage device 140 and mobile terminal 150.

[0014] Firmware refers to the low-level software embedded in the internal chip of hardware devices (such as Bluetooth headsets and smartwatches), which can directly control and coordinate the operation of the hardware. Internal memory includes, but is not limited to, read-only memory (ROM) and flash memory.

[0015] A firmware upgrade system is a hardware and software collaboration system that enables firmware updates between a mobile terminal and a target device via a data transmission channel. This system can be widely used in smart wearable devices, Bluetooth audio devices, and IoT terminal devices, achieving fast and secure firmware upgrades across iOS / Android platforms without MFi certification.

[0016] Mobile terminal 150 refers to one or more terminal devices or software used by a user. In some embodiments, mobile terminal 150 may include one or any combination of other devices with input and / or output functions, such as mobile phone 150-1, tablet 150-2, and computer 150-3. In some embodiments, terminal device 150 may be configured to perform a firmware upgrade process.

[0017] Target device 110 refers to the hardware device that needs firmware upgrade. For example, the target device can be a smartwatch 110-1, a Bluetooth speaker 110-2, an IoT sensor 110-3, etc.

[0018] In some embodiments, during the firmware upgrade process, the mobile terminal 150 encapsulates the firmware data into target image data and transmits it to the target device 110 through an audio playback session. The target device 110 then decodes the data and performs the firmware upgrade operation.

[0019] Network 120 is used to connect the firmware upgrade system, processing device 130, and storage device 140. Network 120 enables communication between the various parts of the firmware upgrade system application scenario, facilitating the exchange of data and / or information. In some embodiments, network 120 can be any one or more of a wired network or a wireless network. For example, network 120 includes a cable network, a fiber optic network, a telecommunications network, or any combination thereof.

[0020] Processing device 130 refers to a device used to process data related to the firmware upgrade system. For example, processing device 130 can acquire firmware data, generate target image data based on the firmware data, and control the target device 110 to perform a firmware upgrade based on the target image data. Alternatively, processing device 130 can receive target image data, decode the target image data to obtain firmware data, and use the firmware data to perform a firmware upgrade on the target device. In some embodiments, processing device 130 is integrated into or installed on the firmware upgrade system. For example, processing device 130 is integrated into or installed on the mobile terminal and / or the target device.

[0021] In some embodiments, the processing device 130 is a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, the processing device 130 may be local or remote. In some embodiments, the processing device 130 is implemented on a cloud platform. By way of example only, the cloud platform includes private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-tiered cloud, etc., or any combination thereof.

[0022] For more information on target image data, firmware data, and firmware upgrades, please refer to [link / reference]. Figures 3-5 Related descriptions.

[0023] Storage device 140 refers to a device used to store data, instructions, and / or any other information. In some embodiments, the storage device stores data and / or instructions related to a firmware upgrade system. For example, the storage device stores target image data and firmware data.

[0024] Storage device 140 may include one or more storage components, each of which may be a standalone device or part of other devices (such as processing device 130). In some embodiments, the storage device may be implemented on a cloud platform.

[0025] The above description is illustrative and does not limit the scope of this disclosure. Many alternatives, modifications, and variations will be apparent to those skilled in the art. The features, structures, methods, and other characteristics of the exemplary embodiments described herein can be combined in various ways to obtain other and / or alternative exemplary embodiments. For example, the configuration and / or functionality of application scenario 100 of the firmware upgrade system may be varied or modified depending on the specific implementation scenario. However, these variations and modifications do not depart from the scope of this disclosure.

[0026] Figure 2A This is an exemplary block diagram of a firmware upgrade system applied to a mobile terminal, according to some embodiments of this specification.

[0027] like Figure 2A As shown, the firmware upgrade system 200 applied to a mobile terminal includes an acquisition module 210, a generation module 220, a transmission module 230, and a control module 240.

[0028] A firmware upgrade system 200 for a mobile terminal refers to a system applied to a mobile terminal that performs data (such as firmware data) packaging and transmission, for example, a firmware upgrade application installed on a smartphone. In some embodiments, the firmware upgrade system 200 for a mobile terminal acquires firmware data, generates target image data, and sends the target image data to the target device via a data transmission channel when a communication connection is established with the target device and an audio playback session is triggered, in order to control the target device to perform a firmware upgrade.

[0029] In some embodiments, the acquisition module 210 is used to acquire firmware data. For example, the acquisition module 210 may download the latest firmware data required by the target device 110 from a cloud server, or read preset firmware data from local storage and perform integrity verification on it to ensure that the data source for subsequent processing is reliable.

[0030] In some embodiments, the generation module 220 is used to generate target image data based on firmware data. For example, the generation module 220 is responsible for preprocessing the firmware data, such as fragmentation, encryption, and adding protocol headers, and encapsulating the processed firmware data into target image data conforming to a standard image format (such as JPEG) for subsequent transmission via a data transmission channel (such as a Bluetooth image transmission channel).

[0031] In some embodiments, the transmission module 230 is configured to transmit target image data to the target device via a data transmission channel in response to the establishment of a communication connection between the mobile terminal and the target device and the mobile terminal triggering an audio playback session. For example, the transmission module 230 utilizes the high bandwidth characteristics of classic Bluetooth to sequentially send each target image data disguised as an album cover image to the target device via the BIP cover image transmission channel in the AVRCP protocol, while simultaneously maintaining command interaction with the device via Bluetooth Low Energy to ensure synchronization and reliability of the transmission process.

[0032] In some embodiments, the control module 240 controls the target device to perform firmware upgrades based on target image data. For example, the control module 240 sends an upgrade trigger command to the target device via Bluetooth Low Energy, monitors the receiving status returned by the target device during transmission, dynamically adjusts the transmission strategy (such as retransmitting missing fragments) based on the feedback information, and finally controls the target device to complete the decoding, verification, and writing of firmware data.

[0033] In some embodiments of this specification, the firmware upgrade system, through a modular design applied to mobile terminals, achieves cross-platform high-speed firmware upgrades without MFi certification. Specifically, the acquisition module is responsible for obtaining firmware data from the cloud, the generation module encapsulates the firmware data into target image data to adapt to the Bluetooth image transmission protocol, the transmission module sends the target image data to the target device via the classic Bluetooth high-speed channel when an audio playback session is triggered, and the control module coordinates the entire process to ensure a smooth upgrade. This system fully utilizes existing Bluetooth standard protocols, circumventing the certification restrictions of the iOS platform and achieving covert firmware transmission through image data encapsulation. Furthermore, the modular architecture design makes the system easy to integrate and maintain, significantly improving the efficiency and data security of firmware upgrades.

[0034] Figure 2B Exemplary block diagrams of a firmware upgrade system applied to a target device are shown in some embodiments of this specification.

[0035] like Figure 2B As shown, the firmware upgrade system 201 applied to the target device includes a receiving module 250, a decoding module 260, and an upgrade module 270.

[0036] The firmware upgrade system 201 applied to the target device refers to a system applied to the target device 110 that performs data (such as target image data) decoding and performs upgrade operations, for example, a firmware upgrade module integrated into a Bluetooth speaker. In some embodiments, the firmware upgrade system 201 applied to the target device receives target image data transmitted in an audio playback session, decodes the target image data to extract firmware data, and then performs the upgrade operation.

[0037] In some embodiments, the receiving module 250 receives target image data transmitted during an audio playback session with a mobile terminal via a data transmission channel. For example, the receiving module 250 monitors the BIP cover image transmission channel in the AVRCP protocol via classic Bluetooth, sequentially acquiring target image data disguised as album cover images sent by the mobile terminal during the audio playback session, and temporarily storing the received target image data in a device buffer (such as ROM) for subsequent processing by the decoding module.

[0038] Decoding module 260 refers to a module used for data decoding. In some embodiments, decoding module 260 is used to decode target image data to obtain firmware data. For example, decoding module 260 first parses the received target image data using a standard image format, locates and extracts the encrypted firmware fragment written in the application data segment; then, it uses a pre-stored public key to verify the digital signature in the data, and after the signature verification is successful, it uses the session key to decrypt the encrypted fragment, restoring the original firmware fragment with the protocol header added; finally, it reassembles multiple firmware fragments in an orderly manner according to the index information in the fragment to obtain complete firmware data.

[0039] In some embodiments, the upgrade module 270 is used to perform a firmware upgrade using firmware data. For example, the upgrade module 270 is responsible for atomically writing the decoded complete firmware data into the device's Flash storage area. During the writing process, upgrade groups are divided according to the firmware logic modules. After each upgrade group is successfully written, the upgrade progress status in the non-volatile memory is updated. After the writing is completed, a global integrity check is performed on the firmware. If the check passes, the device is restarted to make the new firmware effective, and the upgrade result is fed back to the mobile terminal via Bluetooth Low Energy.

[0040] For more information on data reception, decoding, and firmware upgrades for the target device, please refer to [link / reference]. Figure 5 Related descriptions.

[0041] In some embodiments of this specification, a modular design of the firmware upgrade system applied to the target device enables accurate reception and efficient parsing of target image data encapsulated on the mobile terminal. Specifically, the receiving module acquires the target image data containing firmware data via a classic Bluetooth channel during an audio playback session. The decoding module extracts encrypted firmware fragments from the application data segment of the target image data and decrypts and verifies them. The upgrade module then orderly reassembles the restored firmware data and writes it to the device storage area to complete the upgrade. This firmware upgrade system applied to the target device fully adapts to the image transmission mechanism of the mobile terminal on the target device side. Through segmented decoding and real-time verification, it effectively reduces the device processing burden while ensuring the integrity and security of the firmware data. This allows for high-speed cross-platform firmware upgrades without additional hardware modifications, reducing the complexity of target device maintenance and improving the success rate of firmware upgrades.

[0042] It should be noted that the above description of the firmware upgrade system and its modules is for convenience only and should not be construed as limiting this specification to the scope of the illustrated embodiments. It is understood that those skilled in the art, after understanding the principles of this system, may arbitrarily combine the various modules or construct subsystems connected to other modules without departing from these principles. In some embodiments, Figure 2A The disclosed firmware upgrade system for mobile terminals includes an acquisition module, a generation module, a transmission module, and a control module. Figure 2B The receiving module, decoding module, and upgrade module in the firmware upgrade system for the target device disclosed herein can be different modules within their respective systems, or a single module can implement the functions of two or more of the aforementioned modules. For example, the modules can share a single storage module, or each module can have its own separate storage module. Such variations are all within the scope of protection of this specification.

[0043] Figure 3 This is an exemplary flowchart illustrating a firmware upgrade method according to some embodiments of this specification. Figure 3 As shown, process 300 includes steps 310-340. In some embodiments, process 300 may be executed by a mobile terminal.

[0044] For more information about mobile terminals, please see [link / reference]. Figure 1 And its related descriptions.

[0045] Step 310: Obtain firmware data.

[0046] Firmware data refers to a collection of binary data used to update the runtime program of a target device. For example, firmware data includes code and configuration parameters required for the target device to run.

[0047] In some embodiments, a mobile terminal can download firmware data from a device manufacturer's or service provider's cloud server via a dedicated application. During the acquisition process, the mobile terminal can verify the integrity of the firmware data, for example, through MD5 (Message-Digest Algorithm 5) or SHA (Secure Hash Algorithm) verification, to ensure the accuracy and integrity of the data. A dedicated application refers to an application developed for the target device to enable interaction and management with the target device. For example, if the target device is a smart speaker, the dedicated application could be a mobile application developed by the smart speaker manufacturer, allowing users to perform firmware upgrades, function settings, and other operations on the smart speaker.

[0048] In some embodiments, the mobile terminal may also obtain firmware data locally. For example, the firmware data may be pre-stored in the mobile terminal's storage space, or received from other devices (such as personal computers) via Near Field Communication (NFC), USB connection, or other means.

[0049] The methods for obtaining firmware data are not limited to those mentioned above; any other suitable data acquisition technology can also be used.

[0050] Step 320: Generate target image data based on firmware data.

[0051] Target image data refers to data that carries firmware data and conforms to a standard image format file.

[0052] Standard image format files are files that follow open and universal data structure specifications and are used to store and represent image data. For example, standard image format files can be JPEG (Joint Photographic Experts Group) format files, BMP (Bitmap) format files, or PNG (Portable Network Graphics) format files, etc.

[0053] In some embodiments, the target image data may include image file data in formats such as JPEG, BMP, and PNG generated by encapsulating firmware data.

[0054] Mobile terminals can generate target image data in various ways based on firmware data.

[0055] In some embodiments, the mobile terminal can encapsulate firmware data to generate target image data. For example, the mobile terminal can embed the firmware data as a data block into the structure of a standard image format file, so that the firmware data conforms to the requirements of a standard image format file.

[0056] In some embodiments, the mobile terminal segments the firmware data into at least two firmware segments according to a preset size; adds a protocol header to each of the at least two firmware segments; and encapsulates each firmware segment after adding the protocol header into target image data to generate at least two target image data sets. For details, please refer to [link to documentation]. Figure 4 And its related descriptions.

[0057] Step 330: In response to the establishment of a communication connection between the mobile terminal and the target device and the triggering of an audio playback session by the mobile terminal, the target image data is transmitted to the target device via the data transmission channel.

[0058] For more information about the target device, please refer to [link / reference]. Figure 1 Related descriptions.

[0059] A communication connection refers to the link established between a mobile terminal and a target device for data exchange. For example, a communication connection can be a wired communication connection (such as a USB connection) or a wireless communication connection (such as a WiFi connection) between the mobile terminal and the target device.

[0060] An audio playback session refers to the process or state in which a mobile terminal streams audio data to a target device. For example, an audio playback session can be the process by which a mobile terminal plays music, call audio, or a silent audio clip used to activate the data transmission channel to the target device.

[0061] A data transmission channel refers to a pathway used to transmit data between a mobile terminal and a target device during an audio playback session. For example, a data transmission channel can be a data transmission channel in a wired communication connection or a data transmission channel in a wireless communication connection.

[0062] In some embodiments, the mobile terminal and the target device can establish a communication connection in various ways. For example, for a USB connection, the mobile terminal connects to the target device via a USB data cable. Once the physical connection is established, the mobile terminal immediately detects the access of the new device and triggers a handshake protocol. After the handshake is successful, a USB connection is successfully established between the mobile terminal and the target device. As another example, for a WiFi connection, the mobile terminal and the target device need to authenticate and associate with a wireless access point (such as a router) based on the wireless network name selected by the user and the entered password. After a handshake based on the 802.11 protocol is successful, a WiFi connection is successfully established between the mobile terminal and the target device.

[0063] In some embodiments, after confirming a successful communication connection, the application on the mobile terminal calls the audio playback interface of the operating system running on the mobile terminal to transmit a piece of audio data to the target device, thereby triggering an audio playback session. To avoid interfering with the user, the audio data can be a silent audio clip, that is, audio data without sound content but still capable of activating the audio transmission protocol. The audio playback interface refers to the underlying audio service or multimedia framework provided by the operating system, which allows applications to access hardware codecs, audio output devices (such as speakers, Bluetooth headsets), etc.

[0064] In some embodiments, the communication connection between the mobile terminal and the target device is a Bluetooth connection, which is established via Bluetooth Low Energy; the target image data is transmitted to the target device via Bluetooth Classic and through a data transmission channel.

[0065] A Bluetooth connection refers to a wireless communication link established between devices based on Bluetooth technology. For example, a Bluetooth connection can be a wireless communication connection established between a mobile terminal and a target device for data exchange. In some embodiments, the mobile terminal sends a connection command to the target device via its Bluetooth module. After receiving and accepting the connection request, the target device sends back an acknowledgment response. After successfully receiving the acknowledgment response and completing the necessary Bluetooth protocol handshake, the mobile terminal marks the Bluetooth connection status as "established" or "connected".

[0066] Bluetooth Low Energy (BLE) is a Bluetooth wireless communication technology characterized by low power consumption. For example, BLE can be used for device discovery, connection maintenance, or transmission of small amounts of data such as control commands and status feedback.

[0067] In some embodiments, the mobile terminal activates its Bluetooth Low Energy (BLE) module and sets it to scanning mode; simultaneously, the target device activates its BLE module and broadcasts a broadcast packet containing its own device identifier. After the mobile terminal scans the broadcast packet and parses the target device's identifier, it initiates a connection request to the target device. Once the target device receives and acknowledges the request, a Bluetooth Low Energy connection is successfully established between the mobile terminal and the target device. This BLE connection is suitable for long-term maintenance and is used for subsequent transmission of upgrade commands, status feedback, and other control information.

[0068] In some embodiments, Bluetooth Low Energy (BLE) connections can also be established using NFC-assisted pairing. For example, the mobile terminal and the target device exchange necessary information such as Bluetooth addresses and pairing keys by touching each other via NFC, and then automatically initiate and complete the BLE connection, thereby simplifying the user's search and selection process.

[0069] There are various ways to establish a Bluetooth Low Energy connection, such as obtaining connection information by scanning a QR code and then initiating a connection. This manual does not impose any specific limitations.

[0070] Bluetooth Classic refers to a Bluetooth wireless communication technology with a high data transfer rate. For example, Bluetooth Classic is suitable for transmitting large files such as target image data.

[0071] In some embodiments, when the communication connection is a Bluetooth connection, the data transmission channel can be a Basic Imaging Profile (BIP) channel based on the Audio / Video Remote Control Profile (AVRCP) protocol.

[0072] The BIP channel based on the AVRCP protocol refers to a standard mechanism defined in the Bluetooth protocol stack. When a mobile terminal and a target device trigger an audio playback session via the AVRCP protocol, the mobile terminal can synchronously transmit the album art corresponding to the currently playing audio through the BIP channel.

[0073] AVRCP is a standard application layer configuration file in the Bluetooth protocol stack. AVRCP defines a standardized set of commands and procedures for remotely controlling the audio and video media playback functions of one device (such as a mobile terminal) on another device (such as a target device). For example, using a mobile phone to control the playback, pause, and volume of a Bluetooth speaker.

[0074] BIP refers to the Bluetooth standard configuration file in the AVRCP protocol used for handling image-related functions.

[0075] When the mobile terminal and the target device control audio playback via the AVRCP protocol, the BIP channel can be used synchronously to transmit the album art corresponding to the currently playing audio. For example, the mobile terminal uses the generated target image data as the "album art of the currently playing audio" and transmits the target image data to the target device via the BIP channel. It is understood that any channel available during the audio playback session and capable of carrying image data can be used as the data transmission channel in this specification.

[0076] During the data transmission phase, the mobile terminal utilizes the high-speed transmission capabilities of classic Bluetooth to encapsulate the target image data into a data packet conforming to a standard image format file within the established audio playback session. This data is then transmitted at high speed via the BIP channel as the album cover image. The target device is configured to listen to the BIP channel, and upon receiving the target image data, it parses and reassembles it into the original firmware data.

[0077] In some embodiments, when the communication connection is a Bluetooth connection, the data transmission channel can also be a virtual serial port channel established based on the classic Bluetooth Serial Port Profile (SPP). After the mobile terminal and the target device establish a classic Bluetooth connection, a stable data stream channel is negotiated and established through the SPP protocol. The target image data is packetized and continuously transmitted to the target device through the virtual serial port channel.

[0078] The transmission of target image data can also be achieved using other data transmission protocols of classic Bluetooth or custom protocols, as long as the data transmission channel can provide sufficient data transmission bandwidth. This manual does not make specific limitations on this.

[0079] In some embodiments of this specification, Bluetooth Low Energy (BLE) is used to establish and maintain a connection, effectively reducing power consumption of the mobile terminal and target device during standby and control interaction phases. When large data transmission is required, the system switches to Bluetooth Classic and utilizes the data transmission channel to transmit data, fully combining the advantages of both Bluetooth technologies. This achieves efficient and reliable large data transmission while ensuring low power consumption, significantly shortening firmware upgrade time.

[0080] Step 340: Control the target device and perform firmware upgrade based on the target image data.

[0081] Firmware upgrade refers to the process of updating or replacing existing firmware data in a target device with a new version of firmware data. For example, a firmware upgrade can be used to add features, optimize performance, or fix security vulnerabilities in the target device.

[0082] In some embodiments, after the mobile terminal has completed transmitting the target image data, it sends a control command to the target device to trigger a firmware upgrade. Upon receiving the control command, the target device receives the target image data, parses and reassembles the target image data to obtain firmware data, and finally writes the extracted firmware data into the storage area of ​​its non-volatile memory (such as flash memory), replacing the old firmware version, and restarts after verification to complete the upgrade.

[0083] In some embodiments, the target device receives target image data transmitted during an audio playback session with a mobile terminal via a data transmission channel; decodes the target image data to obtain firmware data; and performs an upgrade using the firmware data. For details, please refer to [link to relevant documentation]. Figure 5 And its related descriptions.

[0084] In some embodiments, the control methods for triggering firmware upgrades can include various approaches. For example, the firmware upgrade process can be designed to be automatically triggered after the target device successfully receives and verifies target image data in a specific format, without requiring the mobile terminal to send additional control commands.

[0085] In some embodiments, during firmware upgrades, the terminal device may also, in response to a transmission interruption of target image data due to reasons other than power failure, obtain the firmware fragment index that the target device has successfully received after the connection is restored, and transmit the remaining target image data to the target device starting from the next target image data corresponding to the firmware fragment index. In response to a transmission interruption of target image data due to power failure, the mobile terminal retransmits all target image data after the connection is restored.

[0086] Transmission interruptions not caused by power outages refer to any reason other than a power failure that causes data transmission to be interrupted. For example, non-power outage causes include, but are not limited to, unstable communication signals, devices entering sleep mode, or communication module malfunctions.

[0087] Transmission interruption refers to the state in which the transmission of data from the mobile terminal to the target device is stopped or abnormally terminated. For example, during the transmission of target image data, if the Bluetooth signal is interfered with, the target image data cannot continue to be sent, which is a transmission interruption.

[0088] Connection restoration refers to the re-establishment of a communication link between communication devices after a communication connection is interrupted, enabling normal data transmission. For example, after a Bluetooth connection is lost, the mobile terminal and the target device re-search and pair, successfully establishing a communication link, allowing the target image data to continue to be transmitted.

[0089] In some embodiments, the mobile terminal continuously monitors the Bluetooth connection status with the target device during the transmission of target image data. If the connection status is detected to be disconnected, but the power supply status of both the mobile terminal and the target device is normal, and no power-loss related hardware signals are detected (such as power failure interruption reported by the power management unit), then it is determined that the transmission was interrupted due to reasons other than power failure.

[0090] In some embodiments, after detecting a transmission interruption not caused by a power outage, the mobile terminal continuously scans for the connection signal of the target device. When the target device's identifier is re-scanned and a connection request is initiated, and the target device reports a successful connection, and the communication link between the two devices can transmit instructions and data normally, then the connection is determined to have been restored.

[0091] A firmware fragment index is information used to uniquely identify a specific fragment into which firmware data is divided. For example, if firmware data is divided into 100 fragments, numbered from 0 to 99, then the number 50 can be used as a firmware fragment index, representing the 51st fragment. For more information on firmware fragmentation, see [link to documentation]. Figure 4 And its related descriptions.

[0092] In some embodiments, after a transmission interruption not caused by a power outage and the connection is restored, the mobile terminal sends a command to the target device via Bluetooth Low Energy to retrieve the index of the firmware fragment that has been successfully received. Upon receiving the command, the target device queries its local storage for the index of the last firmware fragment that has been successfully received and verified, and then sends that firmware fragment index back to the mobile terminal.

[0093] Transmission interruptions caused by power outages include, but are not limited to, the mobile terminal or target device running out of battery or the power supply being unplugged.

[0094] In some embodiments, if the mobile terminal detects that the Bluetooth connection with the target device is lost during transmission, and the target device's Bluetooth signal cannot be detected by scanning for a relatively long period of time (e.g., 5 minutes), it can be determined that the transmission was interrupted due to a power outage of the target device.

[0095] In some embodiments, determining whether a transmission interruption was caused by a power outage can also be achieved through the target device's status reporting. For example, after the target device regains power and restarts, it includes a startup reason code in its broadcast information or post-connection status information. This startup reason code indicates that the target device restarted due to a power outage. After parsing the startup reason code, the mobile terminal can determine that the previous transmission interruption was caused by a power outage.

[0096] The methods for determining the cause of transmission interruption due to power failure are not limited to this. Other methods include the mobile terminal detecting its own power supply abnormality or receiving an alarm message from the target device indicating a power supply abnormality before the power failure.

[0097] In some embodiments, after determining that the transmission interruption was caused by a power outage and the connection is restored, the mobile terminal will ignore any previous transmission progress, reset the firmware fragment index to the initial value (e.g., 0), and retransmit all target image data to the target device starting from the first target image data.

[0098] In some embodiments of this specification, the causes of transmission interruptions are intelligently distinguished, and different recovery strategies are adopted. For transmission interruptions caused by reasons other than power failure, such as signal instability, a breakpoint resumption mechanism is used to transmit only the incomplete target image data, significantly saving transmission time and device power consumption, and improving the efficiency and reliability of firmware upgrades. For transmission interruptions caused by device power failure, a full retransmission strategy is adopted, effectively avoiding the problem of corruption of existing target image data that may be caused by power failure, ensuring the integrity and reliability of firmware data, thereby avoiding the risk of the device becoming "bricked" due to firmware corruption, and enhancing the fault tolerance of firmware upgrades.

[0099] In some embodiments of this specification, firmware data is transmitted using a data transmission channel in a common Bluetooth audio playback session (such as a BIP channel based on the AVRCP protocol), circumventing the authentication restrictions of custom Bluetooth protocols. By disguising the firmware data as target image data, there is no need to develop a dedicated transmission protocol, thereby reducing the development complexity and resource consumption of the target device firmware. Simultaneously, it improves the universality and compatibility of firmware upgrades. The use of mature audio transmission mechanisms ensures the stability of data transmission, enhancing cross-platform compatibility and transmission stability for firmware upgrades.

[0100] To more intuitively understand the generation process of target image data during the upgrade, the following will combine... Figure 4 The specific process of generating target image data is described in detail. Figure 4 This is an exemplary schematic diagram illustrating the generation of target image data according to some embodiments of this specification.

[0101] In some embodiments, such as Figure 4 As shown, the mobile terminal can segment the firmware data 410 into at least two firmware segments 420 according to a preset size; add a protocol header 430 to each of the at least two firmware segments 420; and encapsulate each firmware segment 420 after adding the protocol header 430 into target image data 440 to generate at least two target image data 440. Figure 4 For example, the mobile terminal can segment the firmware data 410 into firmware segments 420-1, 420-2, ..., 420-n according to a preset size. Protocol headers 430-1, 430-2, ..., 430-n are added to each of the firmware segments 420-1, 420-2, ..., 420-n. Firmware segment 420-1 after protocol header 430-1 is encapsulated into target image data 440-1; firmware segment 420-2 after protocol header 430-2 is encapsulated into target image data 440-2; ...; and firmware segment 420-n after protocol header 430-n is encapsulated into target image data 440-n.

[0102] The preset size refers to a pre-set numerical value. For example, the preset size can be 200KB, which specifies the size of each firmware fragment when fragmenting firmware data.

[0103] Fragmentation refers to the process of dividing firmware data into multiple firmware fragments.

[0104] Firmware fragmentation refers to the partial firmware data obtained by dividing the firmware data into smaller segments. The target device can decode a firmware fragment as soon as it receives it, without waiting for all firmware fragments to be transmitted before decoding.

[0105] Mobile terminals can divide firmware data into segments of a preset size in various ways.

[0106] In some embodiments, the mobile terminal can read the binary data stream of firmware data and divide the firmware data into multiple firmware fragments according to a fixed number of bytes (i.e., a preset size). For example, the mobile terminal can start from the beginning of the firmware data, read data in 200KB increments (i.e., a preset size), and save it as an independent firmware fragment. If the total size of the firmware data is not an integer multiple of the preset size, the size of the last firmware fragment will be smaller than the preset size.

[0107] In some embodiments, the mobile terminal obtains the Bluetooth transmission bandwidth and the total amount of firmware data; determines the target fragment size based on the Bluetooth transmission bandwidth and the total amount of data; fragments the firmware data based on the target fragment size to obtain multiple main firmware fragments; in response to the existence of fragmented fragments with a data amount smaller than the target fragment size after fragmentation, merges the fragmented fragments with adjacent main firmware fragments to obtain merged firmware fragments.

[0108] Bluetooth bandwidth refers to the rate at which data can be transferred within a Bluetooth connection. For example, Bluetooth bandwidth could be 100KB / s.

[0109] Total data size refers to the total size of all data contained in the firmware data to be transmitted. For example, the total data size could be 5000KB.

[0110] In some embodiments, after establishing a Bluetooth connection with the target device, the mobile terminal continuously sends several standard test data packets to the target device, records the total data transmission volume of each standard test data packet and the transmission time required to successfully complete the transmission, and calculates the single Bluetooth transmission bandwidth by the ratio of the total data transmission volume to the transmission time; at the same time, the test process is executed multiple times, and the average value of the Bluetooth transmission bandwidth is used as the Bluetooth transmission bandwidth.

[0111] In some embodiments, Bluetooth transmission bandwidth can also be obtained based on historical transmission data. For example, the mobile terminal can record the average transmission rate in historical Bluetooth connections with the target device and use the historical average Bluetooth transmission rate as the Bluetooth transmission bandwidth.

[0112] In some embodiments, the total amount of firmware data can be obtained by reading the file attributes of the firmware data file. In some embodiments, the total amount of firmware data can also be obtained by querying through the file system's application programming interface (API).

[0113] The target fragment size refers to the size of each firmware data fragment set when fragmenting firmware data. For example, the target fragment size could be 200KB.

[0114] Mobile terminals can determine the target fragment size in various ways based on Bluetooth transmission bandwidth and total data volume.

[0115] In some embodiments, the mobile terminal can use the product of Bluetooth transmission bandwidth and a preset single transmission duration as the initial target fragment size. Then, the initial target fragment size is adjusted to a normalized number that conforms to the hardware characteristics of the target device (such as the size of a Flash memory cell) (e.g., adjusting 198.7KB to 200KB). Finally, it is verified whether the number of firmware fragments after normalization exceeds a preset reasonable upper limit (e.g., 21 fragments). If the number of firmware fragments after normalization does not exceed the preset reasonable upper limit, the normalized number is used as the target fragment size; if the number of firmware fragments after normalization exceeds the preset reasonable upper limit, the ratio of the total data volume to the reasonable upper limit is calculated as a baseline value. If the baseline value is a normalized number, it is directly used as the target fragment size; if the baseline value is not a normalized number, the reasonable upper limit is lowered to make the baseline a normalized number, and the baseline value is used as the target fragment size, ensuring that the final fragment size does not exceed the reasonable upper limit. For example, if the total firmware data size is 5000KB and the initial target fragment size is 200KB, then 25 firmware fragments will be generated, exceeding the upper limit of 21. In this case, since the baseline value is an irregular integer, the reasonable upper limit can be lowered to 20, thereby adjusting the target fragment size to 5000KB / 20=250KB.

[0116] In some embodiments, the preset single transmission duration and reasonable quantity limit can be set by technicians based on experience.

[0117] In some embodiments, the mobile terminal can determine the target fragment size by querying a preset table. The preset table records the target fragment size corresponding to different Bluetooth transmission bandwidth ranges and total firmware data volume ranges. This preset table can be pre-built based on historical data that meets preset conditions. Preset conditions may include: a transmission success rate higher than a preset success rate threshold, a single transmission duration lower than a preset transmission duration, and a fragment size that is a regular integer. The mobile terminal searches for and matches the corresponding target fragment size in the preset table based on the obtained actual Bluetooth transmission bandwidth and total data volume.

[0118] Other strategies can be used to determine the target fragment size, such as prediction using machine learning models or dynamic adjustment based on the success rate of the first few fragments during transmission.

[0119] A main firmware fragment is a firmware fragment whose data size is equal to the target fragment size. For example, if the target fragment size is 200KB, then a firmware fragment of size 200KB is a main firmware fragment.

[0120] In some embodiments, the mobile terminal can start from the beginning of the firmware data file and sequentially extract data blocks equal to the target fragment size, with each data block equal to the target fragment size constituting a main firmware fragment. This process continues until the remaining amount of firmware data is less than the size of a complete target fragment.

[0121] A fragment is a firmware fragment whose data size is smaller than the target fragment size. For example, if the target fragment size is 200KB, a firmware fragment of size 100KB is a fragment.

[0122] Merged firmware fragments refer to firmware fragments that contain a main firmware fragment and a fragment fragment. For example, merging a 100KB fragment fragment with a 200KB main firmware fragment can form a 300KB merged firmware fragment.

[0123] In some embodiments, the mobile terminal can append the last remaining fragment after fragmentation to the end of its adjacent last main firmware fragment to generate a merged firmware fragment. Simultaneously, the protocol header of the merged firmware fragment is updated by adding a merge identifier. The merge identifier may include a merge identifier bit (e.g., set to 1 to indicate a merged fragment), the original index of the fragment, and the data size of the fragment. Therefore, after receiving the merged firmware fragment, the target device can separate the original main firmware fragment and the fragment fragment according to the merge identifier and reassemble the firmware data according to the original index.

[0124] In some embodiments, the mobile terminal may also merge the fragmented data with the first main firmware fragment in the firmware data to form a merged firmware fragment. The identification information added during merging can also use other formats, as long as it ensures that the target device can correctly parse and reassemble the merged firmware fragment.

[0125] In some embodiments of this specification, the target fragment size is dynamically determined based on the Bluetooth transmission bandwidth and the total amount of firmware data, and fragment fragments are merged. This ensures transmission stability while reducing the number of fragments and interaction overhead, thereby improving the overall transmission efficiency of firmware upgrades.

[0126] A protocol header is data appended to the beginning of a data block and used to describe or manage the data block. In some embodiments, the protocol header includes index information and verification information for firmware fragments.

[0127] Index information refers to information used to identify the order or position of data blocks within the original data. For example, index information can be used to indicate which fragment the current firmware fragment is within the entire firmware data.

[0128] Verification information refers to information used to verify the integrity or accuracy of data.

[0129] In some embodiments, the mobile terminal may set a counter starting from 0 or 1 during the fragmentation process. Each time a firmware fragment is generated, the current count value is used as the index information of the firmware fragment, and then the counter is incremented.

[0130] In some embodiments, the verification information can be generated using a Cyclic Redundancy Check (CRC) algorithm. For example, the mobile terminal can apply the CRC32 algorithm to the data of each firmware segment to generate a 32-bit checksum as verification information.

[0131] In some embodiments, the verification information can also be generated using a hash algorithm. For example, the mobile terminal can apply the SHA-256 algorithm to the data of each firmware segment to generate a 256-bit hash value as verification information.

[0132] After generating index information and verification information, the index information and verification information are combined according to a predefined format to form a protocol header, and the protocol header is attached to the front end of the corresponding firmware segment.

[0133] In some embodiments, in addition to index information and verification information, the protocol header may also include other management information, such as the data length of the current firmware fragment and the total number of fragments in the entire firmware data, to facilitate management by the target device. In some embodiments, the algorithm for generating the verification information is not limited to CRC or SHA series algorithms, but may also use other algorithms such as MD5, checksum, etc., which are not specifically limited in this specification.

[0134] In some embodiments, the mobile terminal embeds each firmware fragment, after adding a protocol header, into a standard image format file. For example, the mobile terminal can create a PNG format image data structure and write each firmware fragment, after adding a protocol header, to a specific location in the metadata area (such as a tEXt block) or pixel data area of ​​the image data structure, thereby generating target image data that is formally valid image data but actually carries firmware data.

[0135] In some embodiments, encapsulation may include various methods, as long as it generates a data unit that can be recognized and received by the target device. Besides encapsulating in a standard or custom image data format, each firmware fragment with a protocol header added may also be encapsulated in other data packet formats suitable for transmission; this specification does not specifically limit this.

[0136] In some embodiments, the mobile terminal encrypts each firmware segment after adding a protocol header; the encrypted firmware segments are written into the application data segment of a standard image format file to generate target image data.

[0137] Mobile terminals can encrypt each firmware fragment after adding a protocol header in various ways.

[0138] In some embodiments, the mobile terminal may employ a symmetric encryption algorithm to encrypt each firmware fragment after adding the protocol header. For example, the Advanced Encryption Standard (AES) algorithm may be used. Exemplarily, a pre-shared key can be used to encrypt the firmware fragments after adding the protocol header using the AES-128 algorithm, generating encrypted firmware fragments.

[0139] In some embodiments, the mobile terminal may also employ Chinese national cryptographic algorithms for encryption. For example, the SM4 block cipher algorithm may be used. Similar to the AES algorithm, a preset key is used to encrypt the firmware fragments after the protocol header is added.

[0140] Mobile terminals can also use other encryption methods, such as the Triple Data Encryption Algorithm (3DES) or asymmetric encryption algorithms (such as Rivest Shamir Adleman, RSA).

[0141] The application data segment refers to a reserved area within the data structure of a standard image format file for storing specific application or custom information. For example, in a JPEG file, the application data segment can be an APPn (Application Marker Segments) segment. Writing data to this segment typically does not alter the structure or display characteristics of the standard image format file.

[0142] In some embodiments, the mobile terminal can write encrypted firmware fragments into the application data segment of a JPEG format file. For example, the mobile terminal can first create a standard JPEG format file, then locate a specific application data segment of the JPEG format file (e.g., the APP1 marker segment used to store Exif information), and completely write an encrypted firmware fragment into that application data segment. After writing is complete, the file is saved, and the generated target image data is formatted identically to a regular JPEG format file, thus achieving firmware fragment hiding.

[0143] In some embodiments, the mobile terminal can also write encrypted firmware fragments into a custom data block of a PNG file. For example, the mobile terminal can create a PNG file and define a private data block. Then, the encrypted firmware fragments are written into the data field of this private data block. Since standard image viewers ignore unrecognizable private data blocks, this operation does not affect the normal display of the image, thus achieving the covert storage of firmware fragments.

[0144] In some embodiments, the mobile terminal can also write encrypted firmware fragments into other standard image format files (such as BMP), as long as the specification of the standard image format file supports embedding custom data. The writing location and method can be adjusted according to the format specification of the corresponding standard image format file.

[0145] In some embodiments of this specification, encryption of firmware fragments ensures confidentiality during transmission and storage, preventing data theft or malicious analysis. By embedding encrypted firmware fragments into the application data segment of a standard image format file, the firmware fragments are disguised as ordinary image files, ensuring that the encapsulated target image data conforms to the Bluetooth image transmission specification, thus achieving covert transmission of firmware data.

[0146] In some embodiments, the mobile terminal encrypts each firmware fragment using a first key; and writes the digital signature generated by the second key along with the encrypted firmware fragment into the application data segment.

[0147] The first key refers to a specific sequence of numbers temporarily negotiated and generated by the mobile terminal and the target device at the start of a firmware upgrade. In some embodiments, the first key is a session key.

[0148] A session key is a temporary key that is valid only during a single communication session. For example, a session key is used to encrypt firmware fragments during a firmware upgrade session.

[0149] In some embodiments, at the start of a firmware upgrade session, the mobile terminal and the target device temporarily negotiate and generate a random and unique first key through a secure key negotiation protocol (e.g., the Diffie-Hellman key exchange protocol). The first key is only valid within this firmware upgrade session and is destroyed after the firmware upgrade session ends, thereby ensuring forward security.

[0150] In some embodiments, the mobile terminal uses the firmware fragment with the protocol header added as input data and calls a symmetric encryption algorithm to encrypt the firmware fragment. For example, the AES algorithm can be used, with the first key as the encryption key, to perform the encryption operation on the firmware fragment and generate an encrypted firmware fragment.

[0151] For example, mobile terminals can use the national cryptographic algorithm SM4 to encrypt each firmware fragment.

[0152] Mobile terminals can also achieve encrypted protection for each firmware fragment through other secure key negotiation mechanisms and symmetric encryption algorithms.

[0153] The second key refers to the key used to generate the digital signature. In some embodiments, the second key is the private key in an asymmetric key pair. For example, the second key may include an RSA private key or an ECC (Elliptic Curve Cryptography) private key.

[0154] A digital signature is an electronic signature used to verify the integrity and authenticity of data. For example, a digital signature can be data generated by encrypting the hash value of an encrypted firmware fragment using a second key, used to prove the origin and integrity of the encrypted firmware fragment.

[0155] An asymmetric key pair is a key pair consisting of a public key and a private key, which are mathematically related. For example, the public key in an asymmetric key pair can be made public, while the private key is kept secret by the owner. Data signed with the private key can be verified using the corresponding public key.

[0156] A private key is a key in an asymmetric key pair that is kept secret by the key owner.

[0157] In some embodiments, the mobile terminal applies a hash algorithm (e.g., SHA-256 algorithm) to the encrypted firmware fragment to calculate a fixed-length hash digest; and uses a second key to perform a signature operation on the hash digest to generate a digital signature.

[0158] In some embodiments, the mobile terminal encapsulates the generated digital signature and encrypted firmware fragment together according to a predefined format. For example, the digital signature and encrypted firmware fragment can be written together into the application data segment (such as the APP1 tag segment) of a JPEG format file to form a complete data unit containing authentication information and encrypted firmware fragment.

[0159] In some embodiments, the hash algorithm and asymmetric encryption algorithm used to generate the digital signature can also be other security standard algorithms, such as SHA-3. In some embodiments, the carrier for the encrypted firmware fragments and digital signatures is not limited to image format files, but can also be other format files that support custom data segments or custom data packet structures.

[0160] In some embodiments of this specification, firmware fragments are encrypted using a first key, ensuring the confidentiality of transmission and preventing replay attacks. Simultaneously, a digital signature is generated using a second key, ensuring the authenticity and integrity of the firmware data, preventing tampering, and significantly improving the security and reliability of the firmware upgrade process.

[0161] In some embodiments of this specification, firmware data is fragmented and transmitted by adding a protocol header containing index and verification information. This reduces the memory required for the target device to process target image data at once, improving memory utilization efficiency. Simultaneously, the index information ensures the correctness of target image data reassembly, and the verification information guarantees the integrity of firmware fragments, thereby reducing the firmware data transmission error rate.

[0162] Figure 5 This is an exemplary flowchart illustrating a firmware upgrade method performed by a target device according to some embodiments of this specification. Figure 5 As shown, process 500 includes steps 510 to 530. In some embodiments, process 500 may be executed by a target device.

[0163] Step 510: The target device receives target image data transmitted during the audio playback session with the mobile terminal via the data transmission channel. Firmware data is encapsulated within the target image data.

[0164] For more information on data transmission channels, target image data, firmware data, and audio playback sessions, please refer to [link / reference]. Figure 3 Related descriptions.

[0165] In some embodiments, the target device can establish a classic Bluetooth connection with the mobile terminal and trigger an audio playback session. During audio playback, the target device listens to a data transmission channel, such as the BIP channel in the AVRCP protocol. When it detects that the mobile terminal is transmitting target image data containing firmware data through this data transmission channel, the target device receives the target image data through the same channel.

[0166] Step 520: Decode the target image data to obtain firmware data.

[0167] In some embodiments, the target device parses the target image data, locates the application data segment of a standard image format file (such as JPEG), and extracts the encrypted firmware fragment. Then, it performs preliminary decryption of the firmware fragment using a decryption key (such as a first key) and decryption algorithm (such as the AES algorithm) pre-agreed with the mobile terminal. This preliminary decryption allows the acquisition of the protocol header verification information of the firmware fragment.

[0168] In other embodiments, the decryption process may also employ other symmetric encryption algorithms, such as the Chinese national standard SM4 algorithm. The decoding process is similar to the aforementioned AES algorithm; in this case, the decryption algorithm pre-agreed upon by the target device and the mobile terminal is the SM4 algorithm.

[0169] In some embodiments, the target device can verify the data integrity of firmware fragments based on verification information. In some embodiments, the verification method includes: recalculating the checksum of the decrypted data using the same verification algorithm (such as CRC32) as the sending end (such as a mobile terminal), and comparing it with the original checksum carried in the protocol header. After successful verification, the firmware fragments are extracted, and all firmware fragments are cached or reassembled in the correct order according to the index information in the protocol header, ultimately obtaining complete firmware data.

[0170] For more information on firmware fragmentation, the first key, protocol headers, index information, and application data segments, please refer to [link to relevant documentation]. Figures 3-4 Related descriptions.

[0171] In some embodiments, firmware data can also be directly encapsulated within the target image data without encryption. In this case, the decoding process mainly involves parsing the image file format, directly extracting firmware fragments from the specified data segments, and then performing verification and reassembly.

[0172] In some embodiments, firmware data may not be fragmented but instead encrypted and encapsulated as a whole within a larger target image dataset. In this case, the decoding process involves extracting the complete encrypted firmware at once, followed by overall decryption and verification. Furthermore, in addition to symmetric encryption, asymmetric encryption algorithms (such as RSA and ECC algorithms) can be used to protect firmware data. In this case, the target device needs to use a pre-set private key for decryption.

[0173] In some embodiments, the target device parses the encrypted firmware fragment and digital signature from the target image data; verifies the digital signature using a pre-stored public key; and in response to the successful verification of the digital signature, decrypts the encrypted firmware fragment using a first key to obtain the firmware fragment.

[0174] For more information on encrypted firmware fragmentation and digital signatures, please refer to [link / reference]. Figure 4 Related descriptions.

[0175] In some embodiments, the target device parses the target image data in a standard image format, such as JPEG or PNG, to locate specific data segments in the image file, such as application data segments (e.g., APPn marker segments in JPEG format). Subsequently, within the located data segments, encrypted firmware fragments and digital signatures are identified and extracted according to preset storage rules.

[0176] Pre-defined storage rules refer to the pre-agreed data organization method in the application data segment. They are used to specify the storage location, storage order, and corresponding starting identifier of encrypted firmware fragments and digital signatures in the data segment, thereby ensuring that the sending end (such as a mobile terminal) and the receiving end (such as a target device) can accurately write and retrieve data according to a unified specification.

[0177] In some embodiments, the preset storage rules are based on specific identifier bits. For example, the preset storage rules may stipulate that a fixed hexadecimal identifier (e.g., 0x5A5A5A5A) is added to the beginning of the storage area for the encrypted firmware fragment, and another set of hexadecimal identifiers (e.g., 0xA5A5A5A5) is added to the beginning of the storage area for the digital signature. After the target device finds these specific identifier bits in the application data segment, it can determine the starting position of the corresponding data block and extract data of the corresponding length from that position, thereby obtaining the encrypted firmware fragment and the digital signature respectively.

[0178] A flag bit is a feature marker pre-set in the application data segment of an image file to mark the starting position of different data types (such as firmware fragments and digital signatures). The target device can accurately locate and extract the corresponding data block by recognizing the flag bit.

[0179] In other embodiments, the preset storage rules can also be based on offset and length rules. For example, a header is defined at the beginning of the application data segment, which explicitly records the starting offset of the digital signature, the length of the digital signature, the starting offset of the encrypted firmware fragment, and the length of the encrypted firmware fragment. When parsing, the target device only needs to read this header to accurately extract the complete digital signature and encrypted firmware fragment from the target image data based on the offset and length information recorded therein.

[0180] A header is a fixed-format management information located at the beginning of an application data segment. It describes the organization and access method of subsequent data. For example, a data structure containing the starting offset and length of digital signatures and encrypted firmware fragments can be defined at the beginning of the APPn segment of a JPEG image. The target device can learn the specific location of each data block by parsing this header.

[0181] Offset refers to the byte distance between the data header and the starting position of the data block (such as a digital signature). It is used to locate the storage location of the data block. For example, "0x0040" recorded in the data header means that the digital signature is stored starting from the 64th byte after the starting address of the application data segment.

[0182] Length refers to the number of bytes occupied by the data block, which is used to determine the range of data to be extracted. For example, "0x0100" recorded in the data header indicates that the length of the digital signature is 256 bytes. The target device can obtain the complete digital signature by continuously reading 256 bytes from the beginning of the data block.

[0183] A public key is a publicly disclosed key in an asymmetric key pair. The target device pre-stores a public key paired with the mobile terminal's private key before leaving the factory or through a secure channel. This pre-stored public key can be used to verify that the firmware data originated from a trustworthy source and has not been tampered with during transmission.

[0184] In some embodiments, the target device uses a pre-stored public key to decrypt the digital signature parsed from the target image data, obtaining a hash value denoted as H1. This public key is paired with a private key (such as a second key) used by the mobile terminal. Simultaneously, the target device calculates another hash value, denoted as H2, for the received, yet-to-be-decrypted encrypted firmware fragment using the same hash algorithm (such as SHA-256) as the sending end (such as the mobile terminal). Finally, verification is completed by comparing whether H1 and H2 are completely identical. If H1 and H2 are identical, the digital signature verification is considered successful, indicating that the firmware fragment's data source is trustworthy and its content is complete. If they are inconsistent, the verification is considered unsuccessful, and the subsequent update process is terminated.

[0185] In some embodiments, the hash algorithm and asymmetric encryption algorithm used to verify the digital signature can be selected according to security requirements. For example, the hash algorithm can be SHA-256, SHA-3, or SM3, and the asymmetric encryption algorithm can be RSA or ECC (elliptic curve cryptography), etc.

[0186] In some embodiments, after digital signature verification is successful, the target device uses a first key to perform a symmetric decryption operation on the encrypted firmware fragment. For example, the first key may be a session key negotiated and generated by the target device and the mobile terminal during communication to ensure the confidentiality of each communication. The target device may use the Advanced Encryption Standard (AES) algorithm to decrypt the encrypted firmware fragment using the first key, thereby restoring the original plaintext data of the firmware fragment.

[0187] For more information on the first key and the second key, please refer to [link / reference]. Figure 4 Related descriptions.

[0188] In other embodiments, the decryption process may employ other symmetric encryption algorithms. For example, the Chinese national standard SM4 algorithm can be used for decryption. The target device also uses the agreed-upon first key to perform SM4 decryption operations, restoring the encrypted firmware fragment data to plaintext form.

[0189] Those skilled in the art will understand that, in addition to AES and SM4 algorithms, any other suitable symmetric decryption algorithm, such as DES or 3DES, can be used, as long as the decryption end (such as the target device) and the encryption end (such as the mobile terminal) use matching algorithms and keys. The source of the first key is not limited to session negotiation; it can also be a fixed key pre-installed in the device.

[0190] The methods provided in some embodiments of this specification encapsulate encrypted firmware fragments within target image data, achieving secure and covert updates to firmware data. Digital signatures and public key verification ensure the authenticity and integrity of the firmware data source, effectively preventing malicious firmware implantation. Simultaneously, encrypting the firmware fragments using a first key guarantees the confidentiality of the fragment content. This scheme hides firmware data updates within regular image transmission, reducing the risk of detection and interception by attackers and significantly improving the overall security of firmware upgrades.

[0191] Step 530: Perform the upgrade using firmware data.

[0192] In some embodiments, the target device writes the reconstructed and verified complete firmware data to a specific area of ​​its flash memory, which stores program code, overwriting any existing old firmware data in that area. After the firmware data is completely and correctly written to the flash memory, the target device automatically performs a hardware reboot. After rebooting, the target device's processor loads and executes the new firmware data from the flash memory, thus completing the upgrade.

[0193] In other embodiments, to improve the reliability of firmware upgrades, the upgrade process can employ an A / B partition (dual bank) update method. The target device's flash memory contains two independent firmware partitions (Partition A and Partition B). Assuming the current firmware is running on Partition A, the target device writes the new firmware data to the inactive Partition B. After writing, the target device changes the bootloader's boot pointer to Partition B, causing the target device to run the firmware on Partition B, and then performs a reboot. If the new firmware on Partition B fails to boot, the target device's executable can still roll back to Partition A, ensuring the availability of the target device.

[0194] The embodiments described in this specification do not limit the specific execution method of firmware upgrades; other upgrade methods well known to those skilled in the art can also be used. For example, after writing new firmware, the system may not restart immediately, but may wait for user confirmation or perform a restart when the device is idle to complete the upgrade.

[0195] In some embodiments, the target device divides firmware data into upgrade groups based on firmware logic modules. For each upgrade group, the firmware data corresponding to the upgrade group is atomically written to the device storage area, and the upgrade progress status stored in the non-volatile memory is updated after successful writing. The upgrade progress status is used to enable the mobile terminal to transmit the remaining upgrade groups to the target device starting from the upgrade group corresponding to the breakpoint after a power failure and restart.

[0196] A firmware logic module refers to a software unit within firmware data that is logically or functionally divided and possesses independent operating logic and dedicated functions. Firmware data can include multiple firmware logic modules, such as a bootloader, communication protocol stack, main application, or driver. For example, a target device can, based on functional independence and boot dependency order, divide code units that implement specific functions and can be independently compiled or updated (such as bootloader, protocol processing, user applications, etc.) into different firmware logic modules. Simultaneously, the division boundaries are determined according to the loading dependencies between modules during system startup (e.g., the bootloader takes precedence over the main application), ensuring that each module can cooperate collaboratively during runtime and support subsequent independent upgrades. Multiple firmware logic modules work together to achieve the complete operational functionality of the firmware data.

[0197] An upgrade group refers to a collection of one or more target image data (or firmware fragments) that divide firmware data according to firmware logic modules during the firmware upgrade process. For example, an upgrade group contains a collection of all firmware fragments corresponding to the firmware logic module of the Bluetooth communication protocol stack.

[0198] In some embodiments, the operation of dividing firmware data into upgrade groups can be completed by the mobile terminal during the firmware data packaging stage. For example, the mobile terminal can identify different firmware logic modules according to a preset firmware architecture definition, and package one or more target image data into an upgrade group based on these firmware logic modules. For example, the mobile terminal can package all target image data related to the bootloader into one upgrade group, package target image data related to the communication protocol stack into another upgrade group, and create a third upgrade group for target image data related to the main application.

[0199] In other embodiments, the partitioning operation can also be dynamically performed by the target device when receiving data. For example, the firmware data stream (such as target image data) sent by the mobile terminal contains identification information of the firmware logic modules. When receiving data, the target device parses this identification information and caches and aggregates target image data belonging to the same firmware logic module. After all target image data corresponding to the same firmware logic module has been received, the target device constructs it into a complete upgrade group for subsequent write operations.

[0200] Identification information refers to the marking data embedded in the target image data to distinguish different firmware logic modules. For example, a "module ID" field is added to each target image data. When the value of this field is "0x01", it means that the data carried by the firmware segment belongs to the Bootloader module. When the value is "0x02", it means that the firmware segment belongs to the main application module. This allows the target device to accurately classify the received target image data into the corresponding upgrade group based on the identification information.

[0201] Furthermore, in some embodiments, the partitioning operation can also be defined through a firmware manifest file, which explicitly describes which target image data are included in each upgrade group. Those skilled in the art can choose an appropriate partitioning method based on the actual application scenario, and this specification does not impose specific limitations on this.

[0202] Atomic write refers to the operation of writing data to memory as an indivisible whole, where either all data is written successfully or no data is written at all in the event of an error, thus ensuring that no data is partially written.

[0203] In some embodiments, after receiving and verifying all target image data corresponding to an upgrade group, the target device initiates an atomic write process: locking the firmware storage area corresponding to the upgrade group in the device's storage area to prevent other operations from interfering with the write process; then writing all firmware data contained in the upgrade group as a whole into the firmware storage area at once; if any error occurs during the write process (such as write verification failure, sudden power failure, etc.), the target device immediately stops the write operation and restores the firmware storage area to its state before writing through a rollback mechanism to ensure that no data is partially written or the firmware storage area is damaged; the atomic write operation is considered to be successfully completed only after all firmware data of the upgrade group has been completely and correctly written into the firmware storage area.

[0204] In some embodiments, atomic write operations can be achieved through a double-buffering mechanism. For example, the target device's storage area is divided into partition A and partition B, with the current firmware running on the target device residing in partition A. When a firmware logic module needs to be upgraded, the target device first writes all the data of the corresponding upgrade group to partition B. After all the data has been written and verification (such as CRC check or group digital signature verification) has passed, a boot flag stored in non-volatile memory is modified to point to partition B. This flag modification operation is a single and fast operation and can be considered an atomic operation. Thus, even if the device loses power while writing firmware data to partition B, the old firmware data in partition A remains intact and will not affect the normal operation of the target device.

[0205] In other embodiments, atomic write operations can also be achieved using techniques such as logging or copy-on-write. For example, before writing new firmware data, the target device first backs up the old firmware content of the storage area to be modified to a temporary area, and then performs the write operation. After successful writing, the backed-up old firmware content is deleted. If a power outage occurs during the write process, and the target device restarts and detects the existence of an undeleted backup, it uses the backup content to restore the original firmware data, thus ensuring the atomicity of the write operation. As another example, before actually writing new firmware data, the target device first records the write operation itself in a dedicated log area within the storage area. Then, the actual write operation is performed in this log area. If an interruption occurs during the write process (such as a power outage of the target device), the target device will check the log after restarting. If the log shows that the write is incomplete, the write operation is rolled back. Only when the firmware data is completely written to the log area is the operation marked as "complete" in the log, and the firmware data in that log area replaces the old firmware data to complete the upgrade operation.

[0206] Device storage is the area within a target device used to store data. For example, device storage could be the target device's flash memory.

[0207] In some embodiments, after the target device writes the firmware data of the upgrade group to the device storage area (such as Flash), it rereads the data that was just written from the storage area and compares it byte by byte with the received firmware data. If the two are completely consistent, the write is considered successful.

[0208] In some embodiments, the Flash memory's own programming status register or completion flag is utilized. When the target device invokes the Flash write instruction, it checks the hardware status register (such as the "programming complete" flag) to confirm whether the data has been successfully written.

[0209] Upgrade progress status refers to information used to record the firmware upgrade progress. This upgrade progress status provides a recovery point for the mobile terminal after the upgrade is interrupted and restarted due to unexpected circumstances such as power outages. The mobile terminal can query the upgrade progress status of the target device, and thus continue transmitting the remaining firmware data from the last successfully written upgrade group (i.e., from the breakpoint) without having to start from the beginning, realizing the breakpoint resume function.

[0210] A breakpoint refers to the point where the firmware upgrade process is interrupted. For example, a breakpoint could be the last successfully written upgrade group when a power outage causes a transmission interruption.

[0211] In some embodiments, the upgrade progress status can be a numerical index. For example, firmware data is divided into 5 upgrade groups (indexes 0 to 4). The mobile terminal transmits the upgrade groups in index order. The initial status value of the upgrade progress status is -1, and whenever an upgrade group (e.g., the upgrade group with index N) is successfully written to the target device's memory, the target device updates the value of a specific address in its non-volatile memory to N.

[0212] In some embodiments, when the target device or mobile terminal restarts due to an abnormal situation such as a power outage, it first reads the upgrade progress status from non-volatile memory. Assume the read status is "Successfully written to group N-1". After re-establishing the connection with the mobile terminal, the target device informs the mobile terminal of this status. Based on this, the mobile terminal determines that all upgrade groups up to group N-1 have been successfully upgraded, therefore, there is no need for repeated transmission, and it directly starts sending the remaining upgrade groups from the Nth upgrade group.

[0213] In some embodiments, the upgrade progress status can be a bitmap. The bitmap includes multiple bits corresponding to multiple upgrade groups; for example, all bits are 0 before writing. When an upgrade group is successfully written, its corresponding bit is set to 1. This method can not only record the upgrade progress but also support out-of-order writing. Based on the upgrade progress status, the mobile terminal can continue to transmit upgrade groups with bits set to 0 to the target device after the mobile terminal or the target device restarts.

[0214] Upgrade progress status can also be recorded in other ways, such as recording the identifier of the next upgrade group to be written, or attaching a completion marker next to each upgrade group's data. Any information that can reliably indicate the upgrade progress after a power outage can be used as upgrade progress status.

[0215] The firmware upgrade method provided in some embodiments of this specification ensures that every logical module in the device's storage area is complete and valid at any given time by dividing the firmware into upgrade groups according to logical modules and performing atomic writes to each group. This fundamentally avoids the risk of firmware corruption and device boot failure due to upgrade interruptions (such as power outages), significantly improving upgrade reliability. Simultaneously, by recording the upgrade progress in non-volatile memory, a resume function is implemented. This eliminates the need to start from scratch after an upgrade interruption, greatly shortening the time required to resume the upgrade, saving communication bandwidth and device power consumption, which is particularly important for scenarios with unstable wireless connections or unstable power supplies.

[0216] In some embodiments, the last target image data of the upgrade group contains a group digital signature; before performing an atomic write, the target device: parses the group digital signature from the last target image data; and verifies the group digital signature using a pre-stored public key based on all firmware fragments corresponding to the upgrade group; wherein, the atomic write is performed after the group digital signature verification is successful.

[0217] Group digital signatures refer to digital signatures generated for an entire upgrade group.

[0218] In some embodiments, the group digital signature is generated by the sending end (e.g., a mobile terminal). For example, the mobile terminal first calculates a single feature value for each firmware fragment within the upgrade group using a preset hash algorithm (e.g., SHA-256). Then, following a preset index order of the firmware fragments, all single feature values ​​are concatenated into a complete byte stream. Finally, this byte stream is hashed again to generate joint feature information, and this joint feature information is encrypted using a private key (e.g., using PSA or ECDSA algorithms) to obtain the group digital signature. This group digital signature is then embedded into a preset field of the last target image data in the upgrade group, such as the application data segment.

[0219] A single signature is a fixed-length binary string used to uniquely identify the content of the firmware fragment and participate in the generation and verification of the group digital signature in subsequent processes. As long as any byte of the corresponding encrypted firmware fragment changes, its single signature will be completely different.

[0220] Joint feature information refers to the feature information shared by all firmware fragments within the same upgrade group. It can be used to verify the integrity and correct order of all firmware fragments within the upgrade group as a whole.

[0221] In some embodiments, the group digital signature may also be stored in other preset locations of the last target image data, such as a specific offset at the beginning or end of the file, without being specifically limited by this specification.

[0222] In some embodiments, a group digital signature needs to be parsed from the last target image data before performing an atomic write. After receiving all target image data for an upgrade group, the target device locates the last target image data and extracts the group digital signature from it for subsequent verification. In some embodiments, the target device can parse the group digital signature in various ways.

[0223] The process of resolving group digital signatures is similar to the process of resolving digital signatures described above, and you can refer to the relevant description of resolving digital signatures mentioned above.

[0224] In some embodiments, parsing can also be performed in other ways, such as identifying and extracting group digital signatures through specific data markers or delimiters.

[0225] In some embodiments, the last target image data can be determined in a pre-defined manner. For example, the target device can determine this based on pre-configured upgrade group division information (such as the number of firmware fragments contained in each upgrade group). When the number of firmware fragments belonging to the same upgrade group received by the target device reaches a preset value (such as the total number of firmware fragments in the upgrade group), it is determined that all target image data in that upgrade group has been received.

[0226] The last target image data refers to the target image data that is last in the index order within the upgrade group. In some embodiments, the target device may determine the last target image data according to the preset index order of the firmware fragments.

[0227] In some embodiments, the process of verifying the group digital signature includes regenerating the joint feature information, decrypting the group digital signature, and comparing and verifying. Specifically, after confirming that it has received all firmware fragments of an upgrade group, the target device first performs individual digital signature verification and decryption on each firmware fragment to obtain all original firmware fragments. Simultaneously, the original firmware fragments are arranged according to the preset index order of the upgrade group, ensuring that the order of the firmware fragments is consistent with the order in which the group digital signature was generated on the mobile terminal. Next, the target device regenerates the joint feature information of the upgrade group using the same first key and encryption algorithm as the mobile terminal. Simultaneously, the target device uses a pre-stored public key to decrypt the group digital signature parsed from the last target image data to obtain the original joint feature information. Finally, the locally regenerated joint feature information is compared with the decrypted original joint feature information. If the two are completely identical, the verification passes; otherwise, the verification fails.

[0228] In some embodiments, the SHA-3 hash algorithm and the Elliptic Curve Digital Signature Algorithm (ECDSA) can also be used. The process is similar to the embodiments described above, except that the hash operation uses the SHA-3 algorithm, and the decryption (i.e., verification) of the digital signature uses the public key paired with the ECDSA algorithm. In some embodiments, a combination of other hash algorithms (such as the Chinese national cryptographic algorithm SM3) and asymmetric encryption and decryption algorithms (such as the Chinese national cryptographic algorithm SM2) can also be used to complete the verification process, while maintaining the same core logic.

[0229] In some embodiments, once the group digital signature verification passes, the target device initiates an atomic write process, writing all firmware fragments of the upgrade group to non-volatile memory at once. If the comparison results are inconsistent, i.e., verification fails, the target device will abort the write process and may discard all data of the upgrade group, thereby avoiding writing incomplete or tampered firmware to the device and ensuring device security. In some embodiments, the handling method after verification failure may also include reporting an error log to the server or requesting a retransmission of the upgrade group.

[0230] In some embodiments of this specification, a group digital signature is generated for the entire upgrade group, and this group signature is verified before atomic writing, ensuring the overall integrity and authenticity of all firmware fragments within the upgrade group. This effectively resists attacks where attackers replace or tamper with partial firmware fragments. By binding security verification with atomic writing operations, writing is only performed after the entire data group has been verified, fundamentally eliminating the risk of device update failure or "bricking" due to partial data errors or tampering, significantly improving the robustness and security of the firmware upgrade process.

[0231] This specification provides a firmware upgrade method in some embodiments that achieves "silent" firmware updates by transmitting target image data encapsulated with firmware during an audio playback session using existing data channels such as the cover image channel of the Bluetooth AVRCP protocol. This method reuses standard communication protocols, eliminating the need for dedicated connections or complex OTA protocols for firmware upgrades, thus simplifying device-side software implementation. Furthermore, encapsulating firmware data within image data reuses existing data transmission channels, improving transmission compatibility. This solution completes firmware upgrades without interfering with normal user operation (such as listening to music), enhancing the security and reliability of the firmware upgrade process, and is particularly suitable for resource-constrained smart wearables or IoT devices.

[0232] It should be noted that the above descriptions of processes 300 and 500 are for illustrative purposes only and do not limit the scope of this specification. Those skilled in the art can make various modifications and changes to processes 300 and 500 under the guidance of this specification. However, these modifications and changes are still within the scope of this specification. For example, the process of generating target image data in step 320 can be modified to first fragment and encrypt the firmware data before encapsulating it into multiple target image data sets for separate transmission.

[0233] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0234] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A firmware upgrade method, characterized in that, The method, executed by a mobile terminal, includes: Obtain firmware data; Based on the firmware data, target image data is generated; In response to the establishment of a communication connection between the mobile terminal and the target device and the triggering of an audio playback session by the mobile terminal, the target image data is transmitted to the target device via the data transmission channel; Control the target device to perform firmware upgrades based on the target image data.

2. The method according to claim 1, characterized in that, The step of generating target image data based on the firmware data includes: dividing the firmware data into multiple firmware fragments according to a preset size; adding a protocol header to each firmware fragment, wherein the protocol header contains the index information and verification information of the fragment; and encapsulating the firmware fragments with the added protocol header into target image data.

3. The method according to claim 2, characterized in that, The step of encapsulating each firmware fragment after adding the protocol header into the target image data includes: encrypting each firmware fragment after adding the protocol header; and writing the encrypted firmware fragment into the application data segment of a standard image format file to generate the target image data.

4. The method according to claim 1, characterized in that, The communication connection is a Bluetooth connection, and the Bluetooth connection is established via Bluetooth Low Energy. The target image data is transmitted to the target device via Bluetooth Classic and through the data transmission channel.

5. The method according to claim 1, characterized in that, The method further includes: In response to a transmission interruption caused by reasons other than power failure, after the connection is restored, the firmware fragment index that the target device has successfully received is obtained, and the remaining target image data is transmitted to the target device starting from the next target image data corresponding to the firmware fragment index. In response to a transmission interruption caused by a power outage, all the target image data are retransmitted after the connection is restored.

6. A firmware upgrade method, characterized in that, Performed by the target device, the method includes: Target image data transmitted during an audio playback session with a mobile terminal is received via a data transmission channel, wherein firmware data is encapsulated within the target image data. The target image data is decoded to obtain the firmware data; The upgrade is performed using the firmware data.

7. A firmware upgrade system, characterized in that, The system, applied to a mobile terminal, includes: The acquisition module is configured to acquire firmware data. The generation module is configured to generate target image data based on the firmware data; The transmission module is configured to transmit the target image data to the target device via a data transmission channel in response to the establishment of a communication connection between the mobile terminal and the target device and the triggering of an audio playback session by the mobile terminal. The control module is configured to control the target device and perform firmware upgrades based on the target image data.

8. A firmware upgrade system, characterized in that, The system, applied to a target device, includes: The receiving module is configured to receive target image data transmitted during an audio playback session with a mobile terminal via a data transmission channel, wherein the target image data encapsulates firmware data. The decoding module is configured to decode the target image data to obtain the firmware data; The upgrade module is configured to perform an upgrade using the firmware data.

9. An electronic device, characterized in that, The device includes at least one processor and at least one memory; The at least one memory is used to store computer instructions; The at least one processor is configured to execute at least a portion of the computer instructions to implement the method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions. When the computer reads the computer instructions from the storage medium, the computer executes the method as described in any one of claims 1-6.

Images