CN113741925A

CN113741925A - Software upgrading method and device

Info

Publication number: CN113741925A
Application number: CN202010942977.0A
Authority: CN
Inventors: 陈磊
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2020-09-09
Filing date: 2020-09-09
Publication date: 2021-12-03
Anticipated expiration: 2040-09-09
Also published as: CN113741925B

Abstract

The embodiment of the application provides a software upgrading method and device, relates to the field of terminals, and aims to enable a first device (for example, a mobile phone) to assist a second device (for example, a sound box or an earphone) in software upgrading. The method is applied to a system comprising first equipment, second equipment and a server, wherein the first equipment comprises a first module set, the first module set comprises a first module and a second module, the second equipment comprises a second module set and first configuration information, and the second module set is a subset of the first module set, and the method comprises the following steps: the second device may determine to schedule the first module of the first device to search for the second version information of the first software from the server according to the first configuration information; the second equipment determines to schedule a second module of the first equipment to download an upgrade package corresponding to the second version information from the server according to the first configuration information; the second equipment receives the upgrade package corresponding to the second version information from the first equipment; and the second equipment installs the upgrade package corresponding to the second version information.

Description

Software upgrading method and device

Technical Field

The present application relates to the field of communications, and in particular, to a method and an apparatus for upgrading software.

Background

Currently, when an IOT device is upgraded, a device manufacturer/manufacturer (e.g., an internet of things (IOT) device manufacturer) generally adopts a policy of using a mobile phone to assist in upgrading the IOT device. The IOT equipment can be divided into a plurality of types, IOT equipment manufacturers can provide a set of integrated binary components for each type of IOT equipment, and the integrated binary components are integrated on the IOT equipment side and the mobile phone side respectively, so that the stability of an interface between the mobile phone and the IOT equipment is ensured.

The above scheme has the following disadvantages: the function realization of the mobile phone side and the IOT equipment side is fixed, and the interactive interfaces between the mobile phone and the IOT equipment are different under the condition that the types of the IOT equipment are different. With the continuous increase of IOT devices, if the mobile phone side needs to uniformly control a plurality of different types of IOT devices, the mobile phone side needs to integrate a plurality of different binary components, resulting in large consumption of storage space of the mobile phone side. Moreover, when a new type of IOT device appears, a corresponding binary component needs to be redesigned and integrated for the new type of IOT device, which makes it difficult for the mobile phone to implement effective extension of the auxiliary upgrade of multiple types of IOT devices.

Disclosure of Invention

The embodiment of the application provides a software upgrading method and device, which are used for assisting in upgrading software of equipment (for example, IOT equipment).

In a first aspect, an embodiment of the present application provides a software upgrading method, which is applied to a system including a first device, a second device, and a server, where the first device includes a first module set, the first module set includes a first module and a second module, the second device includes a second module set and first configuration information, and the second module set is a subset of the first module set, and the method includes: the second equipment determines that first software of the second equipment is to be upgraded, wherein the current version information of the first software is first version information; the second equipment determines to schedule a first module of the first equipment to search second version information of the first software from the server according to the first configuration information, wherein the second version information is different from the first version information; searching second version information of the first software from the server by a first module of the first device; the second equipment determines to schedule a second module of the first equipment to download an upgrade package corresponding to the second version information from the server according to the first configuration information; a second module of the first equipment downloads an upgrade package corresponding to the second version information from the server; the first equipment sends an upgrade package corresponding to the second version information to the second equipment; the second equipment receives the upgrade package corresponding to the second version information from the first equipment; and the second equipment installs the upgrade package corresponding to the second version information.

Based on the method provided by the embodiment of the application, the first device (e.g., a mobile phone) can assist the second device (e.g., a sound box) in searching and downloading the upgrade package corresponding to the second version information. Therefore, if the second device does not have networking capability or the second device cannot be networked, the second device can search and download the upgrade package corresponding to the second version information by means of the networking capability of the first device, and software upgrade of the second device can be achieved.

In a possible implementation manner, the system further includes a third device, where the third device includes a third module set and second configuration information, the third module set is a subset of the first module set, and the third module set is different from the second module set, and the method further includes: the third equipment determines that second software of the third equipment is to be upgraded, wherein the current version information of the second software is third version information; the third equipment determines to schedule the first module of the first equipment to search fourth version information of the second software from the server according to the second configuration information, wherein the fourth version information is different from the first version information; the first module of the first device searches fourth version information of the second software from the server; the third equipment determines to schedule a second module of the first equipment to download an upgrade package corresponding to the fourth version information from the server according to the second configuration information; the second module of the first equipment downloads the upgrade package corresponding to the fourth version information from the server; the first equipment sends an upgrade package corresponding to the fourth version information to the third equipment; the third equipment receives the upgrade package corresponding to the fourth version information from the first equipment; and the third equipment installs the upgrade package corresponding to the fourth version information.

Based on the method provided by the embodiment of the application, the first device (e.g., a mobile phone) can assist the third device (e.g., a sound box) in searching and downloading the upgrade package corresponding to the fourth version information. In this way, if the third device does not have networking capability or the third device cannot be networked, the third device may search and download the upgrade package corresponding to the fourth version information by using the networking capability of the first device, and may implement software upgrade of the third device.

Moreover, the method provided by the embodiment of the present application may enable the first device to assist the different devices (the second device and the third device) to be upgraded through the modules (for example, the first module and the second module) in the first module set.

In one possible implementation, the first set of modules further includes a third module, and the method further includes: the second equipment determines to schedule a third module of the first equipment to check an upgrade package corresponding to the second version information according to the first configuration information; and the third module of the first equipment checks the upgrade package corresponding to the second version information.

In this way, if the second device does not have the upgrade package checking capability or the second device cannot check the upgrade package, the second device may check the upgrade package corresponding to the second version information by using the upgrade package checking capability of the first device.

In one possible implementation, the first set of modules further includes a fourth module, and the method further includes: the second equipment determines to schedule a fourth module of the first equipment to carry out differential reduction and/or compression reduction on the upgrade package corresponding to the second version information according to the first configuration information; and the fourth module of the first device performs differential restoration and/or compression restoration on the upgrade package corresponding to the second version information.

Thus, if the second device does not have the differential restoration and/or compression restoration capability of the upgrade package or the second device cannot perform differential restoration and/or compression restoration, the second device may perform differential restoration and/or compression restoration on the upgrade package corresponding to the second version information by using the differential restoration and/or compression restoration capability of the first device.

In one possible implementation, the searching, by the first module of the first device, the second version information of the first software from the server includes: and inputting the identification information of the second device and the type information of the first software to the first module, and outputting the search result of the second version information by the first module.

That is, the first module may search for the second version information based on the identification information of the second device and the type information of the first software.

In a possible implementation manner, the first module further outputs at least one of the second version information, uniform resource locator address information of an upgrade package corresponding to the second version information, size information of the upgrade package, or update log information.

In a possible implementation manner, the downloading, by the second module of the first device, the upgrade package corresponding to the second version information from the server includes: and inputting at least one of identification information of the second equipment, second version information, uniform resource locator address information of an upgrade package corresponding to the second version information or type information of the first software to the second module, and outputting a downloading result of the upgrade package corresponding to the second version information by the second module.

That is, the second module may download the upgrade package corresponding to the second version information according to at least one of the identification information of the second device, the second version information, the url address information of the upgrade package corresponding to the second version information, or the type information of the first software.

In a possible implementation manner, the second module further outputs at least one of a cache address of the upgrade package corresponding to the second version information or a download progress of the upgrade package corresponding to the second version information.

In one possible implementation, the first set of modules or the second set of modules are integrated into a Software Development Kit (SDK). The first set of modules may be integrated into the SDK of the first device and the second set of modules may be integrated into the SDK of the second device. Among other things, the SDK may be provided uniformly by a software vendor (e.g., huaye).

In a possible implementation manner, before the second device determines that the first software of the second device is to be upgraded, the method further includes: the method comprises the steps that first equipment displays prompt information on a first interface of an application program, wherein the prompt information is used for prompting first software of second equipment to be upgraded; the method comprises the steps that first equipment receives first operation of a user, wherein the first operation is used for upgrading first software of second equipment; the first device sends a notification message to the second device, wherein the notification message is used for indicating that the first software is to be upgraded. The user can perform corresponding operation on the first device so as to upgrade the software of the second device, and the user does not need to operate on the second device, so that the operation convenience of the user can be improved.

In a possible implementation manner, the sending, by the first device, the upgrade package corresponding to the second version information to the second device includes: the first equipment sends an upgrade package corresponding to the second version information to the second equipment based on the near field equipment communication protocol; wherein the near field device communication protocol comprises at least one of a wireless fidelity protocol, a bluetooth protocol, or a Near Field Communication (NFC) protocol.

In one possible implementation, the method further includes: and the first equipment sends the download progress of the upgrade package corresponding to the second version information to the second equipment. If the second device has a display screen, the downloading progress can be displayed for the user.

In one possible implementation, the method further includes: and the second equipment sends the installation progress of the upgrade package corresponding to the second version information to the first equipment. In this way, the first device may display the installation progress to the user through the display screen.

In one possible implementation, the type of the first software includes at least one of firmware, a patch, a software development kit, a plug-in, or a device parameter. That is, the first device can assist the second device in upgrading various upgrading services.

In one possible implementation, the first configuration information is provided by a manufacturer of the second device. Therefore, the upgrading process of the loudspeaker box can be guaranteed to be effectively verified and tested by a loudspeaker box manufacturer, and upgrading reliability is guaranteed.

In a possible implementation manner, the first configuration information is determined by the second device according to the capability information of the second device and the capability information of the first device; the capability information of the second device comprises at least one of communication capability, processing capability and display capability of the second device, and the capability information of the first device comprises at least one of communication capability, processing capability and display capability of the first device. In this way, the upgrade process can be made more flexible.

In a second aspect, an embodiment of the present application provides a software upgrading method, which is applied to a first device, where the first device includes a first module set, and the first module set includes a first module and a second module, and the method includes: the method comprises the steps that first equipment determines that first software of second equipment is to be upgraded, wherein current version information of the first software is first version information; searching second version information of the first software from the server by a first module of the first device; a second module of the first equipment downloads an upgrade package corresponding to the second version information from the server; and the first equipment sends the upgrade package corresponding to the second version information to the second equipment.

In a third aspect, an embodiment of the present application provides a software upgrading method, including: the second equipment determines that first software of the second equipment is to be upgraded, wherein the current version information of the first software is first version information; the second equipment determines to schedule a first module of the first equipment to search second version information of the first software from the server according to the first configuration information, wherein the second version information is different from the first version information; the second equipment determines to schedule a second module of the first equipment to download an upgrade package corresponding to the second version information from the server according to the first configuration information; the second equipment receives the upgrade package corresponding to the second version information from the first equipment; and the second equipment installs the upgrade package corresponding to the second version information.

Based on the method provided by the embodiment of the application, if the second device does not have networking capability or the second device cannot be networked, the second device can search and download the upgrade package corresponding to the second version information by means of the networking capability of the first device, and software upgrade of the second device can be achieved.

In a fourth aspect, an embodiment of the present application provides a first device, where the first device includes: a wireless communication module, memory, and one or more processors; the wireless communication module and the memory are coupled with the processor; wherein the memory is to store computer program code, the computer program code comprising computer instructions; the computer instructions, when executed by the processor, cause the first device to perform a method as set forth in the first aspect or the second aspect and any of its possible implementations.

In a fifth aspect, an embodiment of the present application provides a first device, which has a function of implementing the method described in the first aspect or the second aspect and any possible implementation manner thereof. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.

In a sixth aspect, an embodiment of the present application provides a second device, where the second device includes: a wireless communication module, memory, and one or more processors; the wireless communication module and the memory are coupled with the processor; wherein the memory is to store computer program code, the computer program code comprising computer instructions; the computer instructions, when executed by the processor, cause the second device to perform a method as set forth in the first or third aspect and any possible implementation thereof.

In a seventh aspect, an embodiment of the present application provides a second device, where the apparatus has a function of implementing the method described in the foregoing first aspect or third aspect and any possible implementation manner thereof. The functions can be realized by hardware, and the functions can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the above-described functions.

In an eighth aspect, embodiments of the present application provide a chip system, which includes one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected by a line.

The above chip system may be applied to a first device including a communication module and a memory. The interface circuit is configured to receive signals from the memory and to transmit the received signals to the processor, the signals including computer instructions stored in the memory. When executed by a processor, the computer instructions may perform a method as described in the first aspect and any one of its possible implementations.

Alternatively, the above chip system may be applied to a second device including a communication module and a memory. The interface circuit is configured to receive a signal from the memory of the second device and send the received signal to the processor, the signal including computer instructions stored in the memory. When the processor executes the computer instructions, the second device may perform the method as described in the second aspect and any one of its possible implementations.

In a ninth aspect, embodiments of the present application provide a computer-readable storage medium including computer instructions. The computer instructions, when executed on a first device, cause the first device to perform a method as set forth in the first aspect and any one of its possible implementations. The computer instructions, when executed on a second device, cause the second device to perform the method as described in the second aspect and any one of its possible implementations.

In a tenth aspect, embodiments of the present application provide a computer program product, which when run on a computer, causes the computer to perform the method according to the first, second or third aspect and any possible implementation manner thereof.

In an eleventh aspect, an embodiment of the present application provides a software upgrade system, including a first device, a second device, and a server, where the first device may perform the method according to the first aspect or the second aspect and any possible implementation manner thereof, and the second device may perform the method according to the first aspect or the third aspect and any possible implementation manner thereof.

Optionally, the software upgrading system may further include a third device, and the third device may perform a method similar to the method related to the second device in the first aspect or the third aspect and any possible implementation manner thereof.

Drawings

Fig. 1A is a schematic diagram of a system architecture according to an embodiment of the present application;

fig. 1B is a schematic diagram of a first apparatus provided in an embodiment of the present application;

fig. 2A is a schematic display diagram of a mobile phone according to an embodiment of the present disclosure;

fig. 2B is a schematic display diagram of another mobile phone according to an embodiment of the present application;

fig. 2C is a schematic display diagram of another mobile phone according to an embodiment of the present application;

fig. 2D is a schematic display diagram of another mobile phone provided in the embodiment of the present application;

fig. 2E is a schematic display diagram of another mobile phone provided in the embodiment of the present application;

fig. 2F is a schematic display diagram of another mobile phone according to an embodiment of the present application;

fig. 2G is a schematic display diagram of another mobile phone provided in the embodiment of the present application;

fig. 2H is a schematic display diagram of another mobile phone according to an embodiment of the present disclosure;

fig. 2I is a schematic display diagram of another mobile phone provided in the embodiment of the present application;

fig. 2J is a schematic display diagram of another mobile phone provided in the embodiment of the present application;

fig. 2K is a schematic display diagram of another mobile phone according to an embodiment of the present application;

fig. 2L is a schematic display diagram of another mobile phone according to an embodiment of the present disclosure;

fig. 3A is a schematic diagram of an upgrade module set provided in an embodiment of the present application;

FIG. 3B is a diagram illustrating a set of upgrade modules provided in an embodiment of the present application;

fig. 4A is a schematic diagram of different upgrade modules corresponding to different upgrade services according to an embodiment of the present application;

FIG. 4B is a diagram illustrating a set of upgrade modules provided in an embodiment of the present application;

fig. 5A is a schematic structural diagram of a sound box and a mobile phone provided in an embodiment of the present application;

fig. 5B is an interaction diagram of an upgrade management module and each upgrade module of a sound box and a mobile phone according to an embodiment of the present application;

fig. 6A is a schematic structural diagram of a sound box, a mobile phone, and a server according to an embodiment of the present disclosure;

fig. 6B is a schematic structural diagram of another sound box, a mobile phone and a server according to an embodiment of the present application;

fig. 6C is a schematic structural diagram of another sound box and a mobile phone provided in the embodiment of the present application;

fig. 7A is a schematic diagram of module interaction between a speaker and a mobile phone according to an embodiment of the present application;

fig. 7B is an interaction diagram of another upgrade management module and each upgrade module of a sound box and a mobile phone according to an embodiment of the present application;

fig. 8A is a schematic diagram of module interaction between another sound box and a mobile phone according to an embodiment of the present application;

fig. 8B is an interaction diagram of another upgrade management module and each upgrade module of a sound box and a mobile phone according to an embodiment of the present application;

fig. 9A is a schematic signal interaction diagram of a sound box and a mobile phone provided in the embodiment of the present application;

fig. 9B is a schematic signal interaction diagram of another sound box and a mobile phone provided in the embodiment of the present application;

fig. 9C is a schematic signal interaction diagram of another sound box and a mobile phone provided in the embodiment of the present application;

fig. 10A is a schematic signal interaction diagram of a headset and a mobile phone according to an embodiment of the present application;

fig. 10B is a schematic signal interaction diagram of another earphone and a mobile phone provided in the embodiment of the present application;

fig. 11 is a schematic signal interaction diagram of a first device, a second device, and a third device provided in an embodiment of the present application;

fig. 12 is a schematic structural diagram of a chip system according to an embodiment of the present disclosure;

fig. 13 is a schematic structural diagram of a second apparatus according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the description of the present application, unless otherwise specified, "at least one" means one or more, "a plurality" means two or more. In addition, in order to facilitate clear description of technical solutions of the embodiments of the present application, in the embodiments of the present application, terms such as "first" and "second" are used to distinguish the same items or similar items having substantially the same functions and actions. Those skilled in the art will appreciate that the terms "first," "second," etc. do not denote any order or quantity, nor do the terms "first," "second," etc. denote any order or importance.

For clarity and conciseness of the following description of the various embodiments, a brief introduction to related concepts or technologies is first presented:

firmware: refers to a (software) program that implements the basic functions of a device (e.g., an IOT device), which may be installed in a chip of the device. Firmware can be upgraded via Over The Air (OTA) techniques, and thus firmware upgrades can also be referred to as OTA upgrades, and firmware upgrade services can also be referred to as OTA upgrade services.

Patching: the program code is issued for solving the problem of the firmware.

And (3) SDK: broadly refers to a collection of related documents, paradigms and tools that assist in the development of a certain class of software.

KIT (service): is an SDK that provides basic services to (applications of) the application layer, such as location services, "hit and miss" services, etc.

Plug-in components: is a program written for a particular application program interface. The plug-in is also called plug-in, addin, add-in, addon or add-on. The plug-in can be used for adding functions of a specific application program, for example, a plug-in of a 'night scene mode' can be installed in the camera application, so that the functions of the night scene mode can be added in the camera application.

Equipment parameters: may include protocol class parameters, power consumption parameters, time zone parameters, performance parameters, and customization parameters of the device, among others. In the embodiment of the present application, the device parameter may be simply referred to as a parameter.

At present, IOT device manufacturers generally adopt a policy of upgrading IOT devices with assistance of a mobile phone when upgrading IOT devices. The IOT equipment can be divided into a plurality of types, IOT equipment manufacturers can provide a set of integrated binary components for each type of IOT equipment, and the integrated binary components are integrated on the IOT equipment side and the mobile phone side respectively, so that the stability of an interface between the mobile phone and the IOT equipment is ensured.

The scheme has the following characteristics: the function realization of the mobile phone side and the IOT equipment side are fixed, under the condition that the types of the IOT equipment are different, the realization of the mobile phone side and the interactive interface between the mobile phone and the IOT equipment are different, along with the continuous increase of the IOT equipment, if the mobile phone side needs to uniformly control the IOT equipment with various different types, the mobile phone side needs to integrate a plurality of different binary components, and the storage space consumption of the mobile phone side is large. When a new type of IOT device appears, a corresponding binary component needs to be redesigned and integrated for the new type of IOT device, which makes it difficult for the mobile phone to implement effective extension of auxiliary upgrade for multiple types of IOT devices.

According to the embodiment of the application, a public upgrading frame (upgrading management mechanism) is adopted to upgrade the equipment (for example, the IOT equipment), various types of IOT equipment (for example, a sound box and an earphone) can be upgraded through electronic equipment (for example, a mobile phone), the various types of IOT equipment are upgraded through the same set of upgrading frame, the storage space consumption is low, and effective expansion of auxiliary upgrading of the IOT equipment can be realized.

Fig. 1A is a schematic diagram of a system architecture according to an embodiment of the present disclosure. The system may include a first device, a second device, and a server. Wherein, the first device is installed with an Application (APP). The server may be a management server for the application. The application program may be, for example, an intelligent life APP, an exercise health APP, or the like. Alternatively, the application may be a settings APP local to the first device.

The second device and the first device can communicate with each other through wireless fidelity (WIFI), bluetooth, NFC and other communication modes.

For example, the first device in the embodiment of the present application may be a mobile phone, a tablet computer, a desktop computer (desktop computer), a handheld computer, a notebook computer (laptop computer), an ultra-mobile personal computer (UMPC), a netbook, a Personal Digital Assistant (PDA), an Augmented Reality (AR) \ Virtual Reality (VR) device, or the like, which may be installed with the target application, and the embodiment of the present application does not particularly limit the specific form of the first device.

Wherein, the operating system of the first device may be Android (Android). Optionally, an emoi system may be installed on the Android platform. Optionally, a Huawei Mobile Service (HMS) engine (engine) or a Google Mobile Service (GMS) module may be integrated on the Android platform. Or the first device may be a hong meng system, an IOS system, or another operating system, and the type of the operating system of the first device is not limited in this embodiment.

The second device provided by the embodiment of the application may refer to a device having communication capabilities such as WIFI, bluetooth, or NFC, and may be, for example, a router, a television, a sound device, a camera, an air conditioner, a refrigerator, an intelligent curtain, a desk lamp, a ceiling lamp, an electric cooker, a security device (such as an intelligent electronic lock), a Personal Computer (PC), and the like that can access a home wireless local area network. Or, the second device in this embodiment of the present application may be a wearable device such as a smart watch, a smart bracelet, a wireless locator, a Tracker (Tracker), and an electronic collar, and the second device in this embodiment of the present application may also be a device such as a vehicle-mounted audio device and a vehicle-mounted air conditioner, and this embodiment of the present application does not specially limit the specific form of the second device.

The operating system of the second device may be a hong meng system, a lightweight hong meng system, an Android system lightweight internet of things operating system (lite OS), a linux system, a dual-frame system, or another operating system, which is not limited in the embodiment of the present application.

In this embodiment, taking the electronic device 200 (e.g., a mobile phone) as an example of the first device shown in fig. 1A, a structure of the first device provided in this embodiment is illustrated. As shown in fig. 1B, the electronic device 200 (e.g., a mobile phone) may include: the mobile communication device includes a processor 210, an external memory interface 220, an internal memory 221, a Universal Serial Bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an earphone interface 270D, a sensor module 280, a button 290, a motor 291, an indicator 292, a camera 293, a display 294, and a Subscriber Identity Module (SIM) card interface 295.

The sensor module 280 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

It is to be understood that the illustrated structure of the present embodiment does not constitute a specific limitation to the electronic apparatus 200. In other embodiments, electronic device 200 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 210 may include one or more processing units, such as: the processor 210 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors.

The controller may be a neural center and a command center of the electronic device 200. The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in processor 210 for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. The memory may hold instructions or data that have just been used or recycled by processor 210. If the processor 210 needs to use the instruction or data again, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 210, thereby increasing the efficiency of the system.

In some embodiments, processor 210 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

It should be understood that the connection relationship between the modules illustrated in the present embodiment is only an exemplary illustration, and does not limit the structure of the electronic device 200. In other embodiments, the electronic device 200 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The charge management module 240 is configured to receive a charging input from a charger. The charger may be a wireless charger or a wired charger. The charging management module 240 may also supply power to the electronic device through the power management module 241 while charging the battery 242.

The power management module 241 is used to connect the battery 242, the charging management module 240 and the processor 210. The power management module 241 receives input from the battery 242 and/or the charging management module 240, and provides power to the processor 210, the internal memory 221, the external memory, the display 294, the camera 293, and the wireless communication module 260. In some embodiments, the power management module 241 and the charging management module 240 may also be disposed in the same device.

The wireless communication function of the electronic device 200 may be implemented by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, the modem processor, the baseband processor, and the like. In some embodiments, antenna 1 of electronic device 200 is coupled to mobile communication module 250 and antenna 2 is coupled to wireless communication module 260, such that electronic device 200 may communicate with networks and other devices via wireless communication techniques.

The

antennas

1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 200 may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 250 may provide a solution including 2G/3G/4G/5G wireless communication applied on the electronic device 200. The mobile communication module 250 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 250 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation.

The mobile communication module 250 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be disposed in the processor 210. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be disposed in the same device as at least some of the modules of the processor 210.

The wireless communication module 260 may provide a solution for wireless communication applied to the electronic device 200, including WLAN (e.g., wireless fidelity, Wi-Fi) network, Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and the like. For example, in the embodiment of the present application, the electronic device 200 (e.g., the first device 110) may access a temporary network (e.g., a Wi-Fi network) provided by the home device 130 through the wireless communication module 260.

The wireless communication module 260 may be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 210. The wireless communication module 260 may also receive a signal to be transmitted from the processor 210, frequency-modulate and amplify the signal, and convert the signal into electromagnetic waves via the antenna 2 to radiate the electromagnetic waves.

The electronic device 200 implements display functions via the GPU, the display screen 294, and the application processor. The GPU is a microprocessor for image processing, and is connected to the display screen 294 and an application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 210 may include one or more GPUs that execute program instructions to generate or alter display information.

The display screen 294 is used to display images, video, and the like. The display screen 294 includes a display panel. For example, in this embodiment of the application, the display screen 294 may be used to display an application interface of the first APP, such as a device sharing interface, a device searching interface, a two-dimensional code scanning interface, and the like.

The electronic device 200 may implement a shooting function through the ISP, the camera 293, the video codec, the GPU, the display screen 294, and the application processor. The ISP is used to process the data fed back by the camera 293. The camera 293 is used to capture still images or video. In some embodiments, electronic device 200 may include 1 or N cameras 293, N being a positive integer greater than 1.

The external memory interface 220 may be used to connect an external memory card, such as a Micro SD card, to extend the memory capability of the electronic device 200. The external memory card communicates with the processor 210 through the external memory interface 220 to implement a data storage function. For example, files such as music, video, etc. are saved in an external memory card.

Internal memory 221 may be used to store computer-executable program code, including instructions. The processor 210 executes various functional applications of the electronic device 200 and data processing by executing instructions stored in the internal memory 221. For example, in the present embodiment, the processor 210 may execute instructions stored in the internal memory 221, and the internal memory 221 may include a program storage area and a data storage area.

The storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The storage data area may store data (e.g., audio data, a phone book, etc.) created during use of the electronic device 200, and the like. In addition, the internal memory 221 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like.

Electronic device 200 may implement audio functions via audio module 270, speaker 270A, receiver 270B, microphone 270C, headset interface 270D, and an application processor, among other things. Such as music playing, recording, etc.

The keys 290 include a power-on key, a volume key, etc. The keys 290 may be mechanical keys. Or may be touch keys. The motor 291 may generate a vibration cue. The motor 291 can be used for both incoming call vibration prompting and touch vibration feedback. Indicator 292 may be an indicator light that may be used to indicate a state of charge, a change in charge, or may be used to indicate a message, missed call, notification, etc. The SIM card interface 295 is used to connect a SIM card. The SIM card can be attached to and detached from the electronic apparatus 200 by being inserted into the SIM card interface 295 or being pulled out from the SIM card interface 295. The electronic device 200 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 295 may support a Nano SIM card, a Micro SIM card, a SIM card, etc.

The following description will be made of an operation process of upgrading a first device and a second device (e.g., IOT device) by taking an example in which a target application is an intelligent life APP and the first device is a mobile phone.

As shown in fig. 2A, the main interface (i.e., desktop) 201 of the mobile phone includes an icon 202 of the smart life application, and the mobile phone may receive a click operation of a user on the icon 202 of the smart life application, and in response to the click operation, the mobile phone may open the smart life application. In response to a user's operation to open a "setup" option in the interface of the smart life application, the cell phone may display the interface 203 as shown in fig. 2B. In interface 203, a number of configurable options may be included, for example, IOT device upgrade option 204 may be included. Optionally, the interface 203 may further include options such as an intelligent button sound effect, an intelligent button vibration, a message notification, and personalized content recommendation, which are not limited in the present application. In response to the user selecting the IOT device upgrade option 204 on the interface 203, as shown in fig. 2C, the mobile phone may display an interface 205, and the interface 205 may include identifiers of a plurality of IOT devices, such as an electric cooker, a refrigerator, a desk lamp, a sound box, and the like. The user may manually trigger certain IOT devices in interface 205 to upgrade. Illustratively, in response to a user selecting the upgrade button 206 of the sound box at the interface 205, as shown in fig. 2D, the upgrade button 206 of the sound box may prompt the user that it is loading (searching for a new version). Further, as shown in fig. 2E, the mobile phone may display an interface 209, and in the interface 209, a prompt text 210 may be displayed, where the prompt text 210 is used to prompt the user to check a new version of the firmware of the sound box, where the new version is 11.1.01 a. In the interface 209, a prompt box 211 may be further included, and options such as immediate upgrade, night upgrade, WLAN automatic upgrade, etc. may be included in the prompt box 211 for the user to select. In response to the user selecting the immediate upgrade option 2111 in the prompt box 211, the handset may display the interface 212 as shown in (a) of fig. 2F. In interface 212, a prompt bar 213 may be included, prompt bar 213 being used to prompt the user for firmware download progress (e.g., 58% downloaded). After the firmware download is completed, as shown in (b) of fig. 2F, the mobile phone may display prompt text 214, where the prompt text 214 is used to prompt the user whether the downloaded version 11.1.01a is installed. In response to the user clicking on the "yes" button 215, the handset may display a progress bar 216 as shown in (a) of fig. 2G, the progress bar 216 being used to prompt the user for an installation progress (e.g., 90% installed). After the installation is completed, as shown in (b) of fig. 2G, the mobile phone may display a prompt text 217, where the prompt text 217 is used to prompt the user that the firmware is upgraded to the version 11.1.01 a.

Alternatively, as shown in fig. 2E, if the user selects the option of night upgrade or WLAN automatic upgrade in the prompt box 211, the handset may download the target version of the upgrade package to the local at night or in case of connection to the WLAN. When a user wants to upgrade the IOT equipment, the upgrade package does not need to be downloaded, the upgrade package can be directly installed, the waiting time of the user is shortened, the user experience is improved, and the upgrade rate is improved.

In one possible design, the handset may directly prompt the user for one or more IOT devices currently to be upgraded. For example, as shown in fig. 2H (a), when the user opens the smart life APP and enters the home page 220 of the smart life APP, the mobile phone may display a prompt text "2 devices have their firmware updated and are going to the upgrade bar" in the prompt box (or search box) 221. In response to the user clicking the prompt box 221, as shown in fig. 2H (b), the handset may display a my page 222, a device firmware upgrade option 223 may be included in the my page 222, and the device firmware may be prompted to be upgraded in the firmware upgrade option 223 through a prompt point (e.g., a small black dot or a small red dot). In response to the user's operation of clicking on firmware upgrade option 223, as shown in fig. 2I (a), the handset may display an interface 224, in which interface 224, 2 devices to be upgraded are included, respectively, a television of a first room (e.g., bedroom) and a router of a fourth room (e.g., living room). Each device to be upgraded corresponds to an upgrade button. Illustratively, in response to a user clicking the upgrade button 225 of the television in the first room, as shown in (b) of fig. 2I, the prompt text on the button 225 may become "in upgrade" indicating that the television in the first room is being upgraded. Where "in upgrade" may indicate that the firmware is being downloaded and installed. After the television in the first room is successfully upgraded, as shown in (c) of fig. 2I, the television in the first room may not be displayed in the interface 224, and only the router in the fourth room is displayed, and the user may upgrade the router in the fourth room.

In another possible design, as shown in fig. 2I (a), the handset may display an interface 224, where in the

interface

224, 2 devices to be upgraded are included, respectively, a television of a first room (e.g., a bedroom) and a router of a fourth room (e.g., a living room). Each device to be upgraded corresponds to an upgrade button. Illustratively, in response to a user clicking the upgrade button 225 of the television of the first room, as shown in fig. 2J (a), the prompt text on the button 225 may become "downloading", indicating that the firmware of the television of the first room is being downloaded. After the download is complete, as shown in fig. 2J (b), the prompt on button 225 may become "on installation," indicating that the firmware for the first room's television is being installed. After the installation is completed, as shown in (c) in fig. 2I, the television in the first room may not be displayed in the interface 224, but only the router in the fourth room is displayed, and the user may upgrade the router in the fourth room, where the specific process refers to an upgrade process of the television in the first room, and details are not described here.

In yet another possible design, as shown in fig. 2K (a), the handset may display an interface 224, in which interface 224, 2 devices to be upgraded are included, respectively a television of a first room (e.g., bedroom) and a router of a fourth room (e.g., living room). Each device to be upgraded corresponds to an upgrade button. Also, a one-touch upgrade button 230 may be included for upgrading all of the devices to be upgraded in interface 224. Illustratively, in response to the user's operation of clicking the one-touch upgrade button 230, as shown in fig. 2K (b), the prompt text on the one-touch upgrade button 230 may become "upgrade in progress", and the prompt text on the upgrade button 225 corresponding to the television of the first room and the upgrade button 231 corresponding to the router of the fourth room may be "upgrade in progress", indicating that the software of the television of the first room and the software of the router of the fourth room are being upgraded (downloaded and installed). After the upgrade is completed, as shown in (c) in fig. 2K, the television in the first room and the router in the fourth room may no longer be displayed in the interface 224, which indicates that the television in the first room and the router in the fourth room have been successfully upgraded, and there is no device to be upgraded currently.

For another example, as shown in fig. 2L, when the user opens the smart life APP, a pop-up box 215 may pop up in the interface of the smart life APP, so as to prompt the user that the IOT device such as a television, a sound box, a router, etc. detects a new version and whether to perform an upgrade. The user may choose to upgrade one or more of the IOT devices, or the user may choose to upgrade all IOT devices that detect a new version. For example, in response to a user selecting all upgrade options 216 in prompt box 215, the handset may upgrade all IOT devices that detect a new version.

The following describes a flow of the upgrade method provided in the embodiment of the present application, where the method provided in the embodiment of the present application may include the following flows: (1) establishing an upgrading module set; (2) and scheduling and executing the upgrading process.

The following describes the process (1) (i.e., establishing the upgrade module set).

As shown in fig. 3A, a set of upgrade modules that can be supported by respective devices may be established at a second device (e.g., a sound box) and a first device (e.g., a mobile phone). Wherein the upgrade module represents program code for upgrading. The upgrade module may also be referred to as an upgrade capability, an upgrade sub-capability, or an upgrade unit, and the like, which is not limited in this application. A plurality of upgrading modules can form a set, and the set can be regarded as a resource pool.

Because the functions of software and hardware of the mobile phone are comprehensive, a set of complete upgrading module set can be established at the mobile phone side. As shown in fig. 3B (a), the upgrade module set of the mobile phone may include a user experience design (UX) module, an upgrade package search module (which may be referred to as a search module for short), an upgrade package download module (which may be referred to as a download module for short), and an upgrade package execution module (which may be referred to as an upgrade package upgrade execution module for short). Optionally, the mobile phone side upgrade module set may further include an upgrade package security check module (may be referred to as a security check module for short), an upgrade package difference/compression reduction module (may be referred to as a difference/compression reduction module for short), and the like. The upgrade package may refer to a firmware upgrade package (or referred to as an OTA package), a patch upgrade package, an SDK upgrade package (e.g., a KIT upgrade package (KIT for short)), a plug-in upgrade package, a parameter upgrade package, or the like.

Because the second device comprises a plurality of types and the different types of second devices have different software and hardware functions, different sets of upgrading modules can be established on the different types of second devices on the side of the second device. Generally, the second device may be classified according to its communication module (bluetooth module, WIFI module, or NFC module), processor computing power, memory size, and the like. For example, the second device may be classified into a WIFI device, a bluetooth device, an NFC device, and the like according to different communication modules of the second device. The WIFI device may be a speaker, and the bluetooth device may be a headset.

For example, as shown in (B) of fig. 3B, if the second device is a sound box, the sound box may be a WIFI device, and since the WIFI device has a function of connecting to the internet, the upgrade module set of the sound box may include an upgrade package search module and an upgrade package download module. Optionally, if the sound box has a display screen or a touch screen or other devices for enabling user interaction, the sound box may further establish a UI module. Optionally, if the processor of the sound box has a strong function, the sound box may further establish a security check module. Optionally, if the ROM of the sound box is large, the sound box may further establish a difference/compression restoration module and the like.

As shown in (c) of fig. 3B, the second device may be a headset, the headset may be a bluetooth device, and the upgrade package search module and the upgrade package download module may not be established since the bluetooth device does not have a function of connecting to the internet. Optionally, if the headset has a display screen or a touch screen or other devices for enabling user interaction, the headset may further establish a UI module. Optionally, if the processor of the headset has a strong function, the headset may further establish a security check module. Optionally, if the ROM of the headset is large, the headset may further establish a difference/compression recovery module and the like.

It should be noted that all types of second devices need to be provided with the upgrade execution module. The upgrade execution capability may refer to a capability of writing an upgrade package to the ROM, which is a basic module that the second device should have. Optionally, the upgrade package security check module and the upgrade package difference/compression reduction module may be integrated in the upgrade package execution module. Namely, the upgrade execution capability not only refers to the capability of writing the upgrade package into the ROM, but also includes a security check module and a difference/compression restoration module.

In one possible design, each upgrade module may be further differentiated according to different types of upgrade services. The types of the upgrade services may include a firmware upgrade service (OTA upgrade service), a patch upgrade service, an SDK upgrade service (KIT upgrade service), a plug-in upgrade service, a parameter upgrade service, and the like.

For example, as shown in fig. 4A, the firmware upgrade service may correspond to a firmware search module, a firmware download module, a firmware upgrade execution module, and the like. The parameter upgrading service can correspond to a parameter searching module, a parameter downloading module, a parameter upgrading execution module and the like. The patch upgrade service may correspond to a patch search module, a patch download module, a patch upgrade execution module, and the like.

For the second device, if the second device needs to support different types of upgrade services, the second device needs to include upgrade modules corresponding to the different types of upgrade services. For example, as shown in fig. 4B, for the sound box, if it is required to support the firmware upgrade service and the parameter upgrade service, the upgrade package search module in the upgrade module set of the sound box may include a firmware search module and a parameter search module, the upgrade package download module may include a firmware download module and a parameter download module, the upgrade package security check module may include a firmware security check module and a parameter security check module, the upgrade package difference/compression reduction module may include a firmware difference/compression reduction module and a parameter difference/compression reduction module, and the upgrade package upgrade execution module may include a firmware upgrade execution module and a parameter upgrade execution module. The firmware upgrading service can correspond to a firmware upgrading searching module, a firmware upgrading downloading module, a firmware safety checking module, a firmware differential/compression restoring module, a firmware upgrading executing module and the like. The parameter upgrading service can correspond to a parameter upgrading searching module, a parameter upgrading downloading module, a parameter safety checking module, a parameter difference/compression restoring module, a parameter upgrading executing module and the like.

In one possible design, upgrade modules of partially different upgrade services may be shared. For example, different upgrade services with the same upgrade package structure, the same upgrade package signature and the same security verification mechanism can share the upgrade package security verification module and the upgrade package differential/compression restoration module. For example, the OTA package upgrade service (firmware upgrade service) and the patch upgrade service may share the upgrade package security check module and the upgrade package differencing/compressing restoration module.

It should be noted that, no matter on the first device side or the second device side, each upgrade module has a fixed input interface and a fixed output interface, the input interface may receive a specific input parameter, and the output interface may output a specific return message, so as to ensure that upgrade modules of different upgrade module sets can be seamlessly docked.

Illustratively, the defined format of the upgrade package search module may include functions, input parameters, and return information, wherein:

description of the function: a search (detection) of the target version (new version) upgrade package is initiated.

Inputting parameters: identification information of the second device, a new version upgrade package type (e.g., firmware, patch, parameters, plug-in, or SDK (e.g., KIT), etc.).

Returning information: and searching results of the new version upgrade package (no new version upgrade package/new version upgrade package). If there is a new version upgrade package, the return information may also include version number information, URL address information, upgrade package size information, update log (changelog) information, and the like of the new version upgrade package.

The defined format of the upgrade package download module may include functions, input parameters, and return information, wherein:

description of the function: and initiating the download of the new version upgrade package, or canceling the download of the new version upgrade package.

Inputting parameters: identification information of the second device, a URL address of the new version upgrade package, and a type of the new version upgrade package.

Returning information: the download progress of the new version upgrade package and the download result (download success/download failure) of the new version upgrade package can be included. The return information may also include the local cache address after the new version upgrade package is downloaded, the version number information of the new version upgrade package, and the like. Or the return information can comprise the result of the download cancellation of the new version upgrade package (cancellation success, cancellation failure).

The defined format of the security check module may include functions, input parameters and return information, wherein:

description of the function: and initiating the safety check of the upgrade package.

Inputting parameters: identification information of the second device, a storage address of the new version upgrade package, a type of the new version upgrade package, and the like.

Returning information: and checking the result (checking success/checking failure) of the new version upgrading packet.

The defined format of the differencing/compact reduction module may include functions, input parameters and return information, where:

description of the function: and initiating differential/compression restoration of the upgrade package.

Inputting parameters: identification information of the second device, a storage address of the new version upgrade package and a type of the new version upgrade package.

Returning information: and (4) differentiating/compressing the restoration result of the upgrade package (differentiating/compressing restoration success or differentiating/compressing restoration failure).

The defined format of the upgrade execution module may include functions, input parameters, and return information, wherein:

description of the function: initiating upgrade execution of the upgrade package (i.e., installing the upgrade package), or canceling upgrade execution of the upgrade package.

Returning information: the upgrade execution progress (i.e., the installation progress), the upgrade execution result (installation success/upgrade failure), or the cancel installation result (installation cancellation success/upgrade failure) of the new version upgrade package may be included.

The defined format of the UI module may include functions, input parameters, and return information, wherein:

description of the function: the user is provided with the option of whether to initiate the processes of searching, downloading and installing the new version upgrade package (namely, upgrading execution), or cancel the processes of downloading, canceling installation and the like, and corresponding progress (for example, downloading progress, installing progress and the like) and results (for example, downloading results, canceling downloading results, installing results, canceling installation results and the like) are displayed to the user.

Inputting parameters: identification information of the second device, the type of the new version upgrade package, version number information of the new version upgrade package (including a ROM version and a patch version), and the upgrade status of the second device (including initialization, detection, downloading, and installation).

Returning information: the user UX sets information, such as determining to initiate search, download, and installation of a new version upgrade package, cancel download, cancel installation, and the like.

In order to summarize the upgrade modules in the upgrade module sets of different devices into a complete upgrade process, a set of management mechanisms (i.e., upgrade framework/upgrade management mechanism) for uniformly coordinating and scheduling the upgrade modules may be established between a first device (e.g., a mobile phone) and a second device (e.g., a sound box).

As shown in fig. 5A, taking the first device as a mobile phone and the second device as a sound box as an example, an upgrade management module (or called as an upgrade process scheduling execution module) may be established on the sound box, and the upgrade management module on the sound box may schedule each upgrade module in the upgrade module set of the sound box. An upgrade management module can be established on the mobile phone, and the upgrade management module on the mobile phone can schedule each upgrade module in the upgrade module set on the mobile phone. The upgrade management module on the sound box and the upgrade management module of the mobile phone can carry out signaling interaction.

For example, as shown in fig. 5B, on the mobile phone side, the UI module may send user UX setting information (e.g., information related to an upgrade setting operation performed by a user on a touch screen of the mobile phone, for example, the upgrade setting operation may be to upgrade firmware of the desk lamp) to the upgrade management module, and the upgrade management module determines that upgrade package upgrade is required (e.g., firmware of the desk lamp is upgraded) according to the user UX setting information. Then, the upgrade management module may schedule the corresponding upgrade modules, such as the upgrade package search module, the upgrade package download module, and the upgrade package upgrade execution module. The upgrade management module may input corresponding input parameters to an input interface of the upgrade package search module, an output interface of the upgrade package search module may output corresponding search information (e.g., a URL address of the upgrade package), and when the upgrade management module schedules the upgrade package download module, the upgrade management module may use the search information (e.g., the URL address of the upgrade package) output by the output interface of the upgrade package search module as the input parameters of the input interface of the upgrade package download module, that is, the output interface of the upgrade package search module may be in butt joint with the input interface of the upgrade package download module. The output interface of the upgrade package download module can output corresponding download information (such as a storage address of the upgrade package), and the upgrade management module can use the download information (such as the storage address of the upgrade package) output by the output interface of the upgrade package download module as an input parameter of the input interface of the upgrade package upgrade execution module when the upgrade package upgrade execution module is scheduled, that is, the output interface of the upgrade package upgrade execution module can be in butt joint with the input interface of the upgrade package upgrade execution module.

Similarly, on the loudspeaker box side, the UI module may send user UX setting information (e.g., information related to an upgrade setting operation performed by a user on a touch screen of the loudspeaker box, for example, the upgrade setting operation may be to upgrade firmware of the desk lamp) to the upgrade management module, and the upgrade management module may determine that upgrade package upgrade is required according to the user UX setting information (e.g., to upgrade firmware of the desk lamp). Then, the upgrade management module may schedule the corresponding upgrade modules, such as the upgrade package search module, the upgrade package download module, and the upgrade package upgrade execution module. The upgrade management module may input corresponding input parameters to an input interface of the upgrade package search module, an output interface of the upgrade package search module may output corresponding search information (e.g., a URL address of the upgrade package), and when the upgrade management module schedules the upgrade package download module, the upgrade management module may use the search information (e.g., the URL address of the upgrade package) output by the output interface of the upgrade package search module as the input parameters of the input interface of the upgrade package download module, that is, the output interface of the upgrade package search module may be in butt joint with the input interface of the upgrade package download module. The output interface of the upgrade package download module can output corresponding download information (such as a storage address of the upgrade package), and the upgrade management module can use the download information (such as the storage address of the upgrade package) output by the output interface of the upgrade package download module as an input parameter of the input interface of the upgrade package upgrade execution module when the upgrade package upgrade execution module is scheduled, that is, the output interface of the upgrade package upgrade execution module can be in butt joint with the input interface of the upgrade package upgrade execution module.

In summary, the input interface and the output interface of each upgrade module (such as the upgrade package search module, the upgrade package download module, and the upgrade package upgrade execution module) are fixed no matter on the mobile phone side or the audio box side, so that the seamless butt joint can be realized no matter the upgrade package search module, the upgrade package download module, and the upgrade package upgrade execution module are integrated on the audio box or the mobile phone side.

It can be appreciated that, since the upgrade modules in the upgrade module set of the speaker and the mobile phone may be duplicated (for example, both the speaker (e.g., WIFI-type device) and the mobile phone may be built with the upgrade package search module and the upgrade package download module), a set of module selection mechanisms is required to specify which modules are selected from the upgrade module set of which device to complete the upgrade process.

In one possible design, as shown in fig. 5A, configuration information may be integrated on the loudspeaker, and the configuration information may be specified by the manufacturer of the loudspeaker. The upgrade management module of the loudspeaker box can determine which modules are selected from the upgrade module set of which equipment to complete the upgrade process according to the configuration information.

For example, if the second device is a speaker, the configuration information may be as shown in table 1:

TABLE 1

Upgrade module	Side of sound box	Mobile phone side
			UI module	●	●
Upgrade package search module	●
			Upgrade package download module	●
Security check module for upgrade package		●
			Differential/compression restoring module for upgrade package		●
Upgrade execution module of upgrade package	●

For example, if the second device is a headset, the configuration information (list) may be as shown in table 2:

TABLE 2

Upgrade module	Earphone side	Mobile phone side
			UI module	●
Upgrade package search module		●
			Upgrade package download module	●
Security check module for upgrade package		●
			Differential/compression restoring module for upgrade package	●
Upgrade execution module of upgrade package	●

It should be noted that, in the configuration information, the UI modules may be in parallel, that is, the UX interaction may be performed on both the first device side (e.g., a mobile phone) and the second device side (e.g., a sound box or a headset). UX interaction on different devices has the same effect, namely, a plurality of user interaction interfaces aiming at upgrading can be provided, each interface can be independently operated by a user so as to carry out upgrading control, and the operation result is shared in different interaction interfaces. Moreover, it can be understood that, when upgrading the second device, the upgrade execution module can only select the upgrade execution module on the second device side. The other modules (e.g., upgrade package search module, upgrade package download module, etc.) except the UI module and the upgrade execution module may select only the upgrade module of the one-side/one-end device.

In another possible design, the upgrade management module may automatically arrange the upgrade modules for completing the upgrade process according to the upgrade module information of the second device side and the first device side. The policies for automatic orchestration may be: the upgrade module of the second device side is preferentially scheduled, and when the second device lacks a necessary upgrade module (e.g., an upgrade package download module), the corresponding upgrade module is scheduled from the first device side.

Exemplarily, as shown in fig. 6A, a system architecture diagram provided for the embodiment of the present application includes a speaker, a mobile phone, and a server. The mobile phone comprises an application program and an SDK set. The set of SDKs may be, for example, an HMS module (otherwise known as an HMS engine) or a GMS module. The application program can be an intelligent life APP, and the application program comprises an upgrade management interface. The SDK set comprises a first SDK, a second SDK and a near field device communication protocol module. The first SDK may be, for example, a KIT frame (frame), and the second SDK may be, for example, a smart home KIT (smart home KIT). The first SDK includes an upgrade function module, which includes an upgrade management module on the mobile phone side in fig. 5A and an upgrade module except the UI module in the upgrade module set.

The upgrade management interface of the application program may receive an operation of a user, and based on the operation of the user, the application program may call an Application Programming Interface (API) interface provided by the first SDK to interact with the upgrade function module. On the mobile phone, the first SDK may exist independently in an APP mode, or the first SDK may be integrated in the application program, or the SDK set may be regarded as an independent APP, the application program and the independent APP may be downloaded and installed cooperatively, and the running of the application program depends on the independent APP.

The sound box comprises an upgrade related user interaction application (i.e. an application for performing upgrade, such as a setting application of the sound box), an SDK set, an upgrade adaptation layer and a vendor-owned code. The set of SDKs may be, for example, an HMS module or a GMS module. The SDK set comprises a first SDK, a second SDK and a near field device communication protocol module. Wherein the first SDK may be, for example, a first SDK, and the second SDK may be, for example, a smartome KIT. The first SDK includes an upgrade function module, which includes an upgrade management module on the speaker side in fig. 5A and an upgrade module except the UI module in the upgrade module set.

Wherein, the SDK set of the speaker side may be delivered by the software vendor (e.g., hua ye) in a unified way. The SDK set can be upgraded independently of the loudspeaker box, namely, the SDK set is decoupled from the code of the loudspeaker box manufacturer. The rest software codes of the sound box are adapted and developed by a sound box manufacturer according to the characteristics of the current sound box.

The manufacturer of the sound box can bear the self upgrading capability of the sound box in the self code. The self-upgrading capability of the loudspeaker box can establish association with the SDK set through the upgrading adaptation layer. As shown in fig. 6B, the speaker may communicate with a server (e.g., a factory OTA server) via the factory owned code, e.g., an OTA upgrade package may be obtained from the server. The self-upgrading capability of the sound box can refer to the related description below, and is temporarily omitted here.

The soft bus in the speaker or the mobile phone is used for providing communication capability between devices. For example, the soft bus may provide inter-device communication capabilities for near field devices, which may include devices connected via a near field protocol such as bluetooth, or devices connected via a home router.

A second SDK in the speaker or handset may provide far field device communication capabilities. The far-field device is a device which completes information interaction between devices through a cloud server (cloud server). It should be noted that the near field device and the far field device are not fixed and may be dynamically switched. For example, when a user controls an air conditioner at home through a mobile phone in a company, the mobile phone and the air conditioner belong to far-field equipment, and a far-field equipment communication protocol is adopted. If the user returns home, the mobile phone and the air conditioner are both connected into the home router network, and at the moment, the mobile phone and the air conditioner belong to near field equipment, and a near field equipment communication protocol is adopted. The first SDK can call a far-field device communication capability interface provided by the second SDK to complete information interaction between far-field devices.

The server may include an OTA server and an application marketplace server, among others. The OTA server can store an OTA upgrade package (e.g., an OTA upgrade package provided by a software vendor (e.g., huaye)) and a patch upgrade package. The application marketplace server may have an SDK, such as (KIT upgrade package), stored therein.

The operating system of the mobile phone can be an android system, a damming system, an IOS system or other operating systems. The operating system of the sound box may be a hong meng system, a lightweight hong meng system, a lite OS, a linux system, a dual-frame system, or other operating systems.

The second SDK of the mobile phone may include a far-field device communication module, and the first SDK of the mobile phone may further include a far-field upgrade control interface and a near-field upgrade control interface. The first SDK may invoke a far-field device communication capability interface of a far-field device communication module through a far-field upgrade control interface so that the first SDK may communicate with a far-field device. The first SDK may invoke a near field device communication capability interface of the soft bus through the near field upgrade control interface so that the first SDK may communicate with the near field device.

Similarly, the second SDK of the sound box may include a far-field device communication module, and the first SDK of the sound box may further include a far-field upgrade control interface and a near-field upgrade control interface. The first SDK may invoke a far-field device communication capability interface of a far-field device communication module through a far-field upgrade control interface so that the first SDK may communicate with a far-field device. The first SDK may invoke a near field device communication capability interface of the soft bus through the near field upgrade control interface so that the first SDK may communicate with the near field device.

For example, as shown in fig. 6C, on the sound box side, the first SDK of the set of SDKs may include an upgrade function module, and the upgrade function module may include an upgrade management module and an upgrade module other than the UI module in the set of upgrade modules. On the mobile phone side, the first SDK may include an upgrade function module, and the upgrade function module may include an upgrade management module and an upgrade module other than the UI module in the upgrade module set.

The UI module of the sound box can be integrated in the related user interactive application for upgrading, and the related user interactive application for upgrading can perform information interaction with the upgrading management module through the upgrading API interface. The UI module of the mobile phone can be integrated in the application program, a user can perform corresponding upgrading setting through an upgrading management interface of the application program, namely, the mobile phone can receive corresponding operation of the upgrading setting of the user through the upgrading management interface, and the upgrading management interface can perform information interaction with the upgrading management module through an upgrading API interface. The upgrade management module of the mobile phone and the upgrade management module of the sound box can interact through the upgrade control interface.

The upgrade configuration information specified by the sound box manufacturer is determined by the sound box manufacturer according to the current sound box condition and the auxiliary upgrade capability (module) condition provided by the mobile phone in the process of integrating the SDK set. The configuration information can be solidified in the sound box after the sound box manufacturer effectively verifies and tests. The subsequent updating module scheduling execution process is executed according to the solidification scheduling sequence and the process. Therefore, the upgrading process of the loudspeaker box can be guaranteed to be effectively verified and tested by a loudspeaker box manufacturer, and upgrading reliability is guaranteed.

In one possible design, the upgrade module of the sound box may not be integrated in the first SDK of the set of SDKs, and the sound box may have its own upgrade capability. The self-upgrading capability of the sound box can be borne in the self-code of a sound box manufacturer, and the association is established through the upgrading adaptation layer and the SDK set. The self-upgrading capability of the sound box means that a sound box manufacturer is responsible for integrating and developing contents. The loudspeaker box can have self-upgrading capability in the following two cases.

1. Some modules need to be developed by the manufacturers of the sound boxes. For example, the upgrade execution module may optionally be developed by the speaker manufacturer itself. The upgrade execution module can support an AB upgrade mode, an independent module upgrade mode and the like.

2. And the capability of part of sound box manufacturers is stronger, and the upgrading function can be designed by self. For example, some speaker manufacturers have OTA servers, and can make and release OTA upgrade packages by themselves. Therefore, the searching module and the downloading module of the upgrade package can be realized by the loudspeaker manufacturer. Namely, the sound box manufacturer can construct the upgrade package searching module and the download module by itself.

It should be noted that the scheduling of the sound box with its own upgrade capability still depends on the upgrade management module of the sound box, so that it can be ensured that the target application (e.g., application program) can effectively manage the sound box upgrade.

Moreover, no matter the upgrading module of the sound box is built in the first SDK of the SDK set or built by a sound box manufacturer, the input interface and the output interface of the upgrading module of the sound box are fixed, so that the upgrading module of the sound box and the upgrading module of the mobile phone can be in seamless butt joint.

The following describes the process (2) (i.e., the upgrade process scheduling execution).

For example, a user may initiate an upgrade (e.g., firmware upgrade) to a second device (e.g., a sound box) on an application on a first device (e.g., a cell phone). The mobile phone can send user UX setting information to the sound box, the upgrade management module on the sound box can read the configuration information integrated on the sound box, and each upgrade module is scheduled according to the arrangement result in the configuration information. Or, the upgrade management module on the sound box may determine (i.e., automatically arrange) the upgrade module for completing the upgrade process according to the upgrade module information on the sound box side and the mobile phone side, and schedule the corresponding upgrade module.

As shown in fig. 7A, a user may perform upgrade settings through an upgrade management interface of an application (for example, as shown in fig. 2C, the user may upgrade a sound box through an upgrade button 206 at an interface 205), and the upgrade management interface may transmit user UX setting information (i.e., information related to the upgrade settings performed by the user at the upgrade management interface) to the upgrade management module through an upgrade API interface. The upgrade management module of the mobile phone can send user UX setting information to the upgrade management module of the sound box through the upgrade control interface, and the upgrade management module of the sound box can receive the user UX setting information through the upgrade control interface. According to the user UX setting information, the upgrade management module of the sound box determines that upgrade of an upgrade package (e.g., OTA package) is required. The upgrade management module of the sound box can read the configuration information, and the configuration information can specify that the OTA package searching module, the OTA package downloading module and the OTA package upgrade execution module on the sound box are adopted. Thus, the upgrade management module of the sound box can determine that the upgrade execution flow is as follows: (1) calling an OTA packet searching module on the sound box; (2) calling an OTA package downloading module on the sound box; (3) and calling an OTA package upgrading execution module on the sound box.

As shown in fig. 7B, on the handset side, a UI module (which may be integrated in an application as in fig. 7A) may transmit user UX setting information to the upgrade management module, and the upgrade management module may transmit the user UX setting information to the upgrade management module on the speaker side. And the upgrading management module at the side of the loudspeaker box determines that the OTA package is required to be upgraded according to the UX setting information of the user. The upgrade management module at the loudspeaker box side can determine to call the local (namely loudspeaker box) upgrade package searching module, the upgrade package downloading module and the upgrade package upgrade execution module according to the configuration information. For a specific calling process, reference may be made to the related description of fig. 5B, which is not described herein again.

Optionally, the upgrade management module on the audio box side may further send corresponding search information, download information, and upgrade execution information to the upgrade management module on the mobile phone side, and the corresponding search information (e.g., version number of new version as shown in fig. 2E), download information (e.g., download progress as shown in (a) of fig. 2F or download progress as shown in (a) of fig. 2J, download completion result as shown in (b) of fig. 2F), upgrade execution information (e.g., installation progress as shown in (a) of fig. 2G or installation progress as shown in (b) of fig. 2J, installation completion result as shown in (b) of fig. 2G, etc.) may be presented to the user through the application program by the upgrade management module on the mobile phone side.

For another example, as shown in fig. 8A, a user may perform upgrade setting through an upgrade management interface of an application program, and the upgrade management interface may transmit user UX setting information to the upgrade management module through an upgrade API interface. The upgrade management module of the mobile phone can send upgrade setting information through the upgrade control interface, and the upgrade management module of the sound box can receive the upgrade setting information through the upgrade control interface. And according to the upgrade setting information, the upgrade management module of the sound box determines that the OTA package is required to be upgraded. The upgrade management module of the sound box can read the configuration information, and the configuration information can specify that a search module and a download module on the mobile phone are adopted and an upgrade execution module on the sound box is adopted. Thus, the upgrade management module of the sound box can determine that the upgrade execution flow is as follows: (1) calling an OTA packet searching module on the mobile phone; (2) calling an OTA package downloading module on the mobile phone; (3) and calling an OTA package upgrading execution module on the sound box.

As shown in fig. 8B, on the handset side, a UI module (which may be integrated in an application as in fig. 8A) may transmit user UX setting information to the upgrade management module, and the upgrade management module may transmit the user UX setting information to the upgrade management module on the speaker side. And the upgrading management module at the side of the loudspeaker box determines that upgrading of an upgrading packet (for example, an OTA packet) is required according to the UX setting information of the user. The upgrade management module at the audio box side can determine an upgrade package search module and an upgrade package download module at the call phone side and an upgrade package upgrade execution module at the local (i.e. the audio box side) according to the configuration information. The upgrade management module at the audio box side can send the configuration information to the upgrade management module at the mobile phone side, so that the upgrade management module at the mobile phone side sequentially calls the upgrade package search module and the upgrade package download module at the mobile phone side. The upgrade management module on the mobile phone side can send the return information of the upgrade patch search module and the upgrade patch download module on the mobile phone side to the upgrade management module on the sound box side, the upgrade management module on the sound box side can analyze the return information, and the sound box calls the upgrade patch upgrade execution module. For a specific calling process, reference may be made to the related description of fig. 5B, which is not described herein again.

Optionally, the upgrade management module on the audio box side may further send the upgrade execution information and the parsed search information and download information to the upgrade management module on the mobile phone side, and the upgrade management module on the mobile phone side forwards the upgrade execution information, the search information and the download information to the UI module on the mobile phone side, so that the corresponding search information (e.g., the version number of the new version shown in fig. 2E), download information (e.g., the download progress shown in (a) in fig. 2F or the download progress shown in (a) in fig. 2J, the download result shown in (b) in fig. 2F), upgrade execution information (e.g., the installation progress shown in (a) in fig. 2G or the installation progress shown in (b) in fig. 2J, the installation result shown in (b) in fig. 2G, etc.) is presented to the user through the application program.

In the processes shown in fig. 7A and 7B, the handset and the speaker may communicate using far-field devices or near-field devices. In the process shown in fig. 8A and 8B, the handset and the speaker may communicate using a near field device. This is because far-field device communication is typically unable to transfer files (i.e., the handset is unable to send handset-downloaded upgrade packages to the speaker).

The upgrade management module of the first device (e.g., a mobile phone) may determine whether the second device (e.g., a speaker) to be upgraded is a far-field device or a near-field device, and then determine whether to complete inter-device communication using the near-field device communication interface or the far-field device communication interface. The judgment modes of the far-field equipment and the near-field equipment are as follows: the soft bus provides information of all near-field devices currently connected with the first device, so that the first device can determine all the near-field devices, and if the second device to be upgraded is a non-near-field device, the second device to be upgraded is considered to be a far-field device. Of course, the second device also needs to determine whether the current communication mode is near-field device communication or far-field device communication, and further determine which set of communication interface needs to be used currently. The second device may also determine, through the soft bus interface, information of all near-field devices currently connected to the second device, and if the current first device is a non-near-field device, the second device is considered to be a far-field device.

For example, the following describes an upgrade package search process, an upgrade package download process, and an upgrade package execution process, respectively, by taking the first device as a mobile phone, the second device as a sound box, and the configuration information specifies that a search module, a download module, and an upgrade execution module on the sound box are used as examples.

Taking the upgrade service type as the OTA service as an example, the upgrade package (OTA package) search process is shown in fig. 9A, and includes:

901. and the UI module of the mobile phone informs the upgrade management module of the mobile phone that the user initiates OTA upgrade package search.

For example, the UI module of the mobile phone may be integrated in an application program, and a user may perform corresponding upgrade setting through the application program, and the mobile phone may receive corresponding operation of the upgrade setting of the user through an upgrade management interface of the application program. Where the version of the OTA upgrade package is different (e.g., higher) than the version of the OTA package on the current loudspeaker.

902. The upgrade management module of the mobile phone informs the upgrade management module of the sound box that the user initiates OTA upgrade package search.

The upgrade management module of the mobile phone and the upgrade management module of the sound box can adopt near field equipment communication or far field equipment communication.

903. And the upgrade management module of the sound box starts a version searching process.

904. And the upgrade management module of the sound box reads module scheduling configuration information configured by equipment manufacturers.

The module scheduling configuration information configured by the equipment manufacturer may be configuration information solidified in the sound box by the sound box manufacturer.

905. The upgrade management module of the loudspeaker box confirms to use the search module of the equipment.

I.e. the configuration information in the loudspeaker specifies the use of the search module of the loudspeaker itself.

906. And the upgrade management module of the sound box calls the search module of the equipment.

907. And the sound box searching module initiates OTA new version searching.

The speaker's search module may search for a new version of the OTA package from the OTA server or the speaker manufacturer's own OTA server.

908. And the searching module of the sound box sends the OTA package new version information to the upgrading management module of the sound box.

909. And the upgrading management module of the sound box stores the OTA package new version information locally.

910. And the upgrading management module of the sound box sends the OTA package new version information to the upgrading management module of the mobile phone.

911. And the upgrading management module of the mobile phone sends the OTA package new version information to the UI module of the mobile phone.

912. And the UI module of the mobile phone displays the new version information of the OTA package.

Illustratively, as shown in FIG. 2E, the handset may display prompt text 210 prompting the user to check for a new version 11.1.01A.

The process of searching for upgrade packages of other types of upgrade services is similar to that in fig. 9A, and is not described in detail herein.

The process of downloading the upgrade package of the OTA service is shown in fig. 9B, and includes:

920. and the UI module of the mobile phone informs the upgrade management module of the mobile phone that the user initiates OTA upgrade package downloading.

For example, as shown in fig. 2E, the mobile phone may receive an operation of clicking on the immediate upgrade entry 2111 by the user, and in response to the operation, the upgrade management interface (i.e., interface 209) may notify the upgrade management module of the mobile phone, through the corresponding upgrade API interface, that the user initiates the OTA upgrade package download of the sound box. Alternatively, as shown in fig. 2I (a), the handset may receive an operation of clicking an upgrade button 225 corresponding to the television of the first room by the user, and in response to the operation, the upgrade management interface (i.e., interface 224) may notify the upgrade management module of the handset that the user initiates OTA upgrade package download of the television of the first room through a corresponding upgrade API interface.

921. And the upgrade management module of the mobile phone informs the upgrade management module of the sound box that the user initiates OTA upgrade package downloading.

922. And the upgrading management module of the sound box starts the downloading process of the OTA upgrading packet.

923. And the upgrade management module of the sound box reads the configuration information configured by the equipment manufacturer.

924. The upgrade management module of the loudspeaker box confirms to use the download module of the equipment (namely the loudspeaker box).

925. And the upgrade management module of the sound box calls a download module of the equipment.

926. And the downloading module of the sound box downloads the OTA upgrade package.

927. And the downloading module of the sound box sends the local cache address of the OTA upgrade package to the upgrade management module of the sound box.

928. And the OTA upgrade package is stored locally by the upgrade management module of the loudspeaker box.

And the upgrade management module of the loudspeaker box stores the OTA upgrade package locally according to the local cache address of the OTA upgrade package.

929. The downloading module of the sound box feeds back the downloading progress (also called downloading progress) of the upgrade package to the upgrade management module of the sound box.

930. And the upgrade management module of the sound box feeds back the downloading progress to the upgrade management module of the mobile phone.

931. And the upgrading management module of the mobile phone feeds back downloading progress to the UI module of the mobile phone.

931a, displaying the downloading progress by a UI module of the mobile phone.

Illustratively, as shown in (a) of fig. 2F, the current download progress may be 58%. For another example, as shown in (a) of fig. 2J, the handset may display "downloading" through the button 225 without displaying a specific downloading progress.

932. And the downloading module of the sound box informs the upgrading management module of the sound box that the OTA upgrading packet is downloaded.

933. And the upgrade management module of the sound box informs the upgrade management module of the mobile phone that the OTA upgrade package is downloaded.

934. And the upgrading management module of the mobile phone informs the UI module of the mobile phone that the OTA upgrading packet is downloaded.

935. And the UI module of the mobile phone downloads the OTA upgrade package and displays the result.

For example, as shown in (b) of fig. 2F, after the OTA upgrade package is downloaded, the mobile phone may prompt the user of the downloaded version 11.1.01a through prompt text 214, and may prompt the user whether installation is required.

The process of executing the upgrade package of the OTA service is shown in fig. 9C, and includes:

940. and the UI module of the mobile phone informs the upgrade management module of the mobile phone that the user initiates OTA upgrade package installation.

Illustratively, as shown in fig. 2F (b), the cell phone may prompt the user of downloaded version 11.1.01a through prompt text 214, and may prompt the user whether installation is required. In response to the user clicking on button 215, the upgrade management interface (i.e., interface 212) may notify the upgrade management module of the handset via the corresponding upgrade API interface that the user initiated OTA upgrade package installation of the loudspeaker.

Or after the upgrading management module of the mobile phone determines that the OTA upgrading packet is downloaded, the OTA upgrading packet installation can be automatically initiated.

941. And the upgrade management module of the mobile phone informs the upgrade management module of the sound box that the user initiates OTA upgrade package installation.

942. And the upgrade management module of the sound box starts the OTA upgrade patch installation process.

943. And the upgrade management module of the sound box reads the configuration information configured by the equipment manufacturer.

944. And the upgrade management module of the loudspeaker box confirms to use the upgrade execution module of the equipment.

945. And the upgrade management module of the sound box calls an upgrade execution module of the equipment.

946. And an OTA upgrade package is installed on the upgrade execution module of the sound box.

947. The upgrade execution module of the sound box feeds back the installation progress (also called downloading progress) to the upgrade management module of the sound box.

948. And the upgrade management module of the sound box feeds back the installation progress to the upgrade management module of the mobile phone.

949. And the upgrading management module of the mobile phone feeds back the installation progress to the UI module of the mobile phone.

950. And displaying the installation progress by a UI module of the mobile phone.

Illustratively, as shown in (a) of fig. 2G, the current installation progress may be 90%. Alternatively, as shown in (b) of fig. 2J, the cellular phone may display "installation in progress" through the button 225 without displaying a specific installation progress.

951. And the upgrade execution module of the sound box feeds back the installation completion to the upgrade management module of the sound box.

952. And the upgrading management module of the sound box is used for completing information recording after installation.

953. And the upgrade management module of the sound box feeds back the installation completion to the upgrade management module of the mobile phone.

954. And the upgrading management module of the mobile phone feeds back the installation completion to the UI module of the mobile phone.

955. And displaying the installation completion result by the UI module of the mobile phone.

Illustratively, as shown in fig. 2G (b), the handset may prompt the user that the firmware of the speaker (OTA package) has been upgraded to version 11.1.01a by prompt text 217. Alternatively, as shown in fig. 2I (c), the first room's television may no longer be displayed in the interface 224 to indicate that the first room's OTA upgrade package installation is complete.

Taking the first device as a mobile phone, the second device as an earphone, and the configuration information specifies to adopt a search module and a download module on the mobile phone and an upgrade execution module on the earphone as examples, the upgrade package search process, the upgrade package download process, and the upgrade package execution process will be described respectively.

Taking the upgrade service type as the OTA service as an example, the upgrade package (OTA package) search process is shown in fig. 10A, and includes:

1001. and the UI module of the mobile phone informs the upgrade management module of the mobile phone of the user to initiate OTA upgrade package search.

1002. And the upgrade management module of the mobile phone informs the user of initiating OTA upgrade package search to the upgrade management module of the earphone.

The upgrade management module of the mobile phone and the upgrade management module of the earphone can adopt near field device communication or far field device communication.

1003. And the upgrading management module of the earphone starts the OTA upgrading packet searching process.

1004. And the upgrade management module of the earphone reads the configuration information configured by the equipment manufacturer.

1005. The upgrade management module of the headset confirms the use of the search module of the mobile phone.

1006. The upgrade management module of the earphone calls the search module of the mobile phone through the upgrade management module of the mobile phone.

1007. And the upgrading management module of the mobile phone calls the searching module of the mobile phone.

1008. And a searching module of the mobile phone initiates OTA upgrade package searching.

The search module of the headset may search for new versions of OTA packets from the OTA server or the headset vendor's own OTA server.

1009. And the search module of the mobile phone feeds back OTA upgrade package version information to the upgrade management module of the mobile phone.

1010. And the upgrading management module of the mobile phone feeds back the version information of the OTA upgrading packet to the upgrading management module of the earphone.

1011. And the upgrading management module of the earphone stores the version information of the OTA upgrading packet locally.

Namely, the upgrading management module of the earphone stores the OTA package version information on the earphone.

1012. And the upgrade management module of the earphone sends the upgrade package description file information to the upgrade management module of the mobile phone.

It should be noted that, after the search module of the mobile phone completes the search of the OTA upgrade package, the version information of the OTA upgrade package is not processed, and is directly transmitted to the upgrade management module of the headset by the upgrade management module of the mobile phone, and the upgrade management module of the headset can analyze the description file information of the upgrade package from the version information of the OTA upgrade package and then transmit the description file information of the upgrade package to the upgrade management module of the mobile phone.

1013. And the upgrading management module of the mobile phone sends the upgrading package description file information to the UI module of the mobile phone.

1014. And the UI module of the mobile phone displays the version information of the OTA upgrade package.

And the UI module of the mobile phone displays the version information of the OTA upgrade package based on the description file information of the upgrade package. Illustratively, as shown in FIG. 2E, the handset may display prompt text 210 prompting the user to check for a new version 11.1.01A.

The process of downloading the upgrade package of the OTA service is shown in fig. 10B, and includes:

1021. and the UI module of the mobile phone informs the upgrading management module of the mobile phone of the user to initiate OTA upgrading package downloading.

1022. And the upgrading management module of the mobile phone informs the upgrading management module of the earphone of the user to initiate OTA upgrading packet downloading.

1023. And the upgrading management module of the earphone starts the OTA upgrading packet searching process.

1024. And the upgrade management module of the earphone reads the configuration information configured by the equipment manufacturer.

1025. The upgrade management module of the earphone confirms to use the download module of the mobile phone.

1026. The upgrade management module of the earphone calls the download module of the mobile phone through the upgrade management module of the mobile phone.

1027. And the upgrading management module of the mobile phone calls the downloading module of the mobile phone.

1028. And the downloading module of the mobile phone downloads the OTA upgrade package.

1029. And the download module of the mobile phone sends the cache address of the OTA upgrade package to the upgrade management module of the mobile phone.

1030. And the upgrading management module of the mobile phone stores the OTA upgrading packet locally.

1031. And the download module of the mobile phone feeds back the download progress to the upgrade management module of the mobile phone.

1032. And the upgrading management module of the mobile phone feeds back the downloading progress to the upgrading management module of the earphone.

1032a, the upgrade management module of the earphone feeds back the downloading progress to the upgrade management module of the mobile phone.

1033. And the upgrading management module of the mobile phone feeds back the downloading progress to the UI module of the mobile phone.

1034. And displaying the downloading progress by a UI module of the mobile phone.

1035. And the download module of the mobile phone feeds back the completion of the download to the upgrade management module of the mobile phone.

1036. And the upgrading management module of the mobile phone sends the OTA upgrading packet to the upgrading management module of the earphone.

1037. The upgrade management module of the headset stores the OTA upgrade package locally.

1037a, the upgrade management module of the earphone feeds back the completion of downloading of the OTA upgrade package to the upgrade management module of the mobile phone.

It should be noted that, after the download module of the mobile phone finishes downloading the OTA upgrade package, the OTA upgrade package is not processed, the upgrade management module of the mobile phone directly transmits the OTA upgrade package to the upgrade management module of the headset, the upgrade management module of the headset finally determines that the OTA upgrade package is downloaded, and then the upgrade management module of the headset feeds back the completion of the OTA upgrade package download to the upgrade management module of the mobile phone.

1038. And the upgrading management module of the mobile phone feeds back the downloading completion of the OTA upgrading packet to the UI module of the mobile phone.

1039. And the UI module of the mobile phone downloads the OTA upgrade package and displays the result.

For example, as shown in (b) of fig. 2F, after the OTA upgrade package is downloaded, the mobile phone may prompt the user of the downloaded version 11.1.01a through prompt text 214.

The process of executing the upgrade package of the bluetooth device may refer to the flow shown in fig. 9C, which is not described herein again.

Based on the method provided by the embodiment of the application, the first device (for example, a mobile phone) can upgrade different types of second devices (for example, a sound box or an earphone) by using the same set of upgrade frame, the consumption of the storage space of the mobile phone is small, and the mobile phone can provide different capability assistance for the different types of second devices through the upgrade frame. For example, for a headset with only bluetooth, NFC, etc. communication capabilities, the handset may assist the headset in searching and downloading upgrade packages. For another example, for a device without a touch screen or a device with complicated user interaction operations (for example, the process of operating a television through a remote controller is complicated), a mobile phone may provide the television with user interaction capability. For another example, for a second device that cannot support the differential restoration capability and the security check capability, the mobile phone may provide the security check capability for the second device, for example, the mobile phone may assist the second device in performing HTTPS security protocol and PKI authentication on the upgrade package. In this way, effective extension of the first device to the secondary upgrade of the second device can be achieved.

As shown in fig. 11, an embodiment of the present application provides a software upgrading method applied to a system including a first device, a second device, and a server, where the first device includes a first module set, the first module set includes a first module and a second module, the second device includes a second module set and first configuration information, and the second module set is a subset of the first module set, and the method includes:

1101. the second equipment determines that first software of the second equipment is to be upgraded, and the current version information of the first software is first version information.

Before step 1101, the following steps may also be included: the method comprises the steps that first equipment displays prompt information on a first interface of an application program, wherein the prompt information is used for prompting first software of second equipment to be upgraded; the method comprises the steps that first equipment receives first operation of a user, wherein the first operation is used for upgrading first software of second equipment; the first device sends a notification message to the second device, wherein the notification message is used for indicating that the first software is to be upgraded.

Wherein the type of the first software comprises at least one of firmware, a patch, a software development kit, a plug-in, or a device parameter. The first configuration information is provided by a manufacturer of the second device. Or the first configuration information is determined by the second device according to the capability information of the second device and the capability information of the first device; the capability information of the second device comprises at least one of communication capability, processing capability and display capability of the second device, and the capability information of the first device comprises at least one of communication capability, processing capability and display capability of the first device.

1102. The second device determines to schedule the first module of the first device to search for second version information of the first software from the server according to the first configuration information, wherein the second version information is different from the first version information.

The first module may be the upgrade package search module described above.

1103. The first module of the first device searches for second version information of the first software from the server.

For example, identification information of the second device and type information of the first software may be input to the first module, and the first module outputs a search result of the second version information.

Optionally, the first module further outputs at least one of the second version information, the uniform resource locator address information of the upgrade package corresponding to the second version information, the size information of the upgrade package, or the update log information.

1104. And the second equipment determines to schedule a second module of the first equipment to download the upgrade package corresponding to the second version information from the server according to the first configuration information.

The second module may be the upgrade package downloading module described above.

1105. And the second module of the first equipment downloads the upgrade package corresponding to the second version information from the server.

For example, at least one of identification information of the second device, second version information, url address information of an upgrade package corresponding to the second version information, or type information of the first software may be input to the second module, and the second module outputs a download result of the upgrade package corresponding to the second version information.

Optionally, the second module further outputs at least one of a cache address of the upgrade package corresponding to the second version information or a download progress of the upgrade package corresponding to the second version information.

Optionally, the first device may send, to the second device, a download progress of the upgrade package corresponding to the second version information.

Further, the first module set further includes a third module, and the third module may be the upgrade package security check module described above. The second device may determine to schedule the third module to verify the upgrade package corresponding to the second version information according to the first configuration information; and the third module of the first equipment checks the upgrade package corresponding to the second version information.

Further, the first module set further includes a fourth module, and the fourth module may be the upgrade package difference/compression restoration module described above. The second device may determine to schedule the fourth module to perform differential restoration and/or compression restoration on the upgrade package corresponding to the second version information according to the first configuration information; and the fourth module of the first device performs differential restoration and/or compression restoration on the upgrade package corresponding to the second version information.

1106. And the first equipment sends the upgrade package corresponding to the second version information to the second equipment.

The first equipment sends an upgrade package corresponding to the second version information to the second equipment based on the near field equipment communication protocol; wherein the near field device communication protocol comprises at least one of a wireless fidelity protocol, a bluetooth protocol, or a near field communication protocol.

1107. And the second equipment receives the upgrade package corresponding to the second version information from the first equipment.

The second device may receive an upgrade package corresponding to the second version information from the first device based on the near field device communication protocol.

1108. And the second equipment installs the upgrade package corresponding to the second version information.

Optionally, the second device may send the installation progress of the upgrade package corresponding to the second version information to the first device.

In one possible design, the system further includes a third device, the third device includes a third set of modules and second configuration information, the third set of modules is a subset of the first set of modules, and the third set of modules is different from the second set of modules, and the method further includes:

1109. and the third equipment determines that second software of the third equipment is to be upgraded, wherein the current version information of the second software is third version information.

1110. And the third equipment determines to schedule the first module of the first equipment to search the fourth version information of the second software from the server according to the second configuration information, wherein the fourth version information is different from the first version information.

1111. The first module of the first device searches for fourth version information of the second software from the server.

1112. The third equipment determines to schedule a second module of the first equipment to download an upgrade package corresponding to the fourth version information from the server according to the second configuration information;

1113. and the second module of the first equipment downloads the upgrade package corresponding to the fourth version information from the server.

1114. And the first equipment sends the upgrade package corresponding to the fourth version information to the third equipment.

1115. And the third equipment receives the upgrade package corresponding to the fourth version information from the first equipment.

1116. And the third equipment installs the upgrade package corresponding to the fourth version information.

The processes of step 1109 to step 1116 may refer to the related descriptions of step 1101 to step 1118, which are not described herein again.

It should be noted that, in the embodiment illustrated in fig. 11, the first device may be a mobile phone in the foregoing embodiment, the second device may be a sound box, and the third device may be an earphone, and portions which are not described in detail in the embodiment illustrated in fig. 11 may refer to the foregoing embodiment, and are not described herein again.

Based on the method provided by the embodiment of the application, the first device (for example, a mobile phone) can upgrade different types of second devices (for example, a sound box or an earphone) by using the same set of upgrade frame, the consumption of the storage space of the mobile phone is small, and the mobile phone can provide different capability assistance for the different types of second devices through the upgrade frame. For example, for a headset with only bluetooth, NFC, etc. communication capabilities, the handset may assist the headset in searching and downloading upgrade packages. For another example, for a device without a touch screen or a device with complicated user interaction operations (for example, the process of operating a television through a remote controller is complicated), a mobile phone may provide the television with user interaction capability. For another example, for a second device that cannot support the differential restoration capability and the security check capability, the mobile phone may provide the security check capability for the second device, and for example, the mobile phone may assist the second device in performing hypertext transfer protocol over security socket (HTTPS) security protocol and Public Key Infrastructure (PKI) authentication on the upgrade package. In this way, effective extension of the first device to the secondary upgrade of the second device can be achieved.

Another embodiment of the present application provides a chip system, as shown in fig. 12, which includes at least one processor 1201 and at least one interface circuit 1202. The processor 1201 and the interface circuit 1202 may be interconnected by wires. For example, the interface circuitry 1202 may be used to receive signals from other apparatuses (e.g., a memory of a first device, a memory of a second device, or a memory of a third device). Also for example, the interface circuit 1202 may be used to send signals to other devices, such as the processor 1201.

For example, the interface circuit 1202 may read instructions stored in a memory in the device and send the instructions to the processor 1201. The instructions, when executed by the processor 1201, may cause the first device or the second device (e.g., the electronic device 200 shown in fig. 1B) to perform the steps in the embodiments described above.

Of course, the chip system may further include other discrete devices, which is not specifically limited in this embodiment of the present application.

Other embodiments of the present application provide a first device (e.g., the electronic device 200 shown in fig. 1B) that may include: a communication module, a memory, and one or more processors. The communication module, the memory and the processor are coupled. The memory is for storing computer program code comprising computer instructions.

Another embodiment of the present application provides a second device, as shown in fig. 13, a second device 1300 includes a communication module 1303, a memory 1302, and one or more processors 1301. The communication module 1303 and the memory 1302 are coupled to the processor 1201. The memory 1302 is used for storing, among other things, computer program code comprising computer instructions. The computer instructions, when executed by the processor 1301, cause the second apparatus 1300 to perform the respective functions or steps performed by the second apparatus in the above-described method embodiments.

Embodiments of the present application also provide a computer-readable storage medium, which includes computer instructions, and when the computer instructions are executed on a first device (e.g., the electronic device 200 shown in fig. 1B), the electronic device 200 executes various functions or steps performed by the first device (e.g., a mobile phone) in the above-described method embodiments. When the computer instructions are executed on a second device (e.g., the second device 1300 shown in fig. 13), the second device 1300 is caused to perform the functions or steps performed by the second device (e.g., the speaker or the headset) in the above-described method embodiments.

Embodiments of the present application also provide a computer program product, which when run on a computer, causes the computer to perform the functions or steps performed by the first device (e.g., a mobile phone) or the second device (e.g., a sound box or a headset) in the above method embodiments.

Through the description of the above embodiments, it is clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the above described functions.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical functional division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another device, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may be one physical unit or a plurality of physical units, that is, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially or partially contributed to by the prior art, or all or part of the technical solutions may be embodied in the form of a software product, where the software product is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only an embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A software upgrading method applied to a system including a first device, a second device and a server, wherein the first device includes a first module set, the first module set includes a first module and a second module, the second device includes a second module set and first configuration information, and the second module set is a subset of the first module set, the method includes:

the second equipment determines that first software of the second equipment is to be upgraded, wherein the current version information of the first software is first version information;

the second device determines to schedule the first module of the first device to search the server for second version information of the first software according to the first configuration information, wherein the second version information is different from the first version information;

the first module of the first device searching the server for the second version information of the first software;

the second equipment determines to schedule the second module of the first equipment to download the upgrade package corresponding to the second version information from the server according to the first configuration information;

the second module of the first device downloads the upgrade package corresponding to the second version information from the server;

the first equipment sends an upgrade package corresponding to the second version information to the second equipment;

the second equipment receives the upgrade package corresponding to the second version information from the first equipment;

and the second equipment installs the upgrade package corresponding to the second version information.

2. The method of claim 1, wherein the system further comprises a third device comprising a third set of modules and second configuration information, wherein the third set of modules is a subset of the first set of modules, and wherein the third set of modules is different from the second set of modules, the method further comprising:

the third equipment determines that second software of the third equipment is to be upgraded, wherein the current version information of the second software is third version information;

the third device determines to schedule the first module of the first device to search for fourth version information of the second software from the server according to the second configuration information, wherein the fourth version information is different from the first version information;

the first module of the first device searching the server for the fourth version information of the second software;

the third equipment determines to schedule the second module of the first equipment to download the upgrade package corresponding to the fourth version information from the server according to the second configuration information;

the second module of the first device downloads the upgrade package corresponding to the fourth version information from the server;

the first equipment sends an upgrade package corresponding to the fourth version information to the third equipment;

the third equipment receives the upgrade package corresponding to the fourth version information from the first equipment;

and the third equipment installs the upgrade package corresponding to the fourth version information.

3. The method of claim 1 or 2, wherein the first set of modules further comprises a third module, the method further comprising:

the second equipment determines to schedule the third module of the first equipment to check the upgrade package corresponding to the second version information according to the first configuration information;

and the third module of the first equipment verifies the upgrade package corresponding to the second version information.

4. The method of any of claims 1-3, wherein the first set of modules further comprises a fourth module, the method further comprising:

the second device determines to schedule the fourth module of the first device to perform differential restoration and/or compression restoration on the upgrade package corresponding to the second version information according to the first configuration information;

and the fourth module of the first device performs differential restoration and/or compression restoration on the upgrade package corresponding to the second version information.

5. The method of any of claims 1-4, wherein the first module of the first device searching for second version information of the first software from the server comprises:

and inputting the identification information of the second device and the type information of the first software to the first module, and outputting the search result of the second version information by the first module.

6. The method of claim 5,

the first module further outputs at least one of the second version information, uniform resource locator address information of an upgrade package corresponding to the second version information, upgrade package size information, or update log information.

7. The method according to any one of claims 1 to 6, wherein the downloading, by the second module of the first device, the upgrade package corresponding to the second version information from the server includes:

inputting at least one of identification information of the second device, the second version information, uniform resource locator address information of an upgrade package corresponding to the second version information, or type information of the first software to the second module, and outputting a download result of the upgrade package corresponding to the second version information by the second module.

8. The method of claim 7,

the second module further outputs at least one of a cache address of the upgrade package corresponding to the second version information or a download progress of the upgrade package corresponding to the second version information.

9. The method according to any one of claims 1 to 8,

the first set of modules or the second set of modules are integrated in an SDK.

10. The method of any of claims 1-9, wherein before the second device determines that the first software of the second device is to be upgraded, the method further comprises:

the first equipment displays prompt information on a first interface of an application program, wherein the prompt information is used for prompting that first software of the second equipment is to be upgraded;

the first device receives a first operation of a user, wherein the first operation is used for upgrading the first software of the second device;

and the first equipment sends a notification message to the second equipment, wherein the notification message is used for indicating that the first software is to be upgraded.

11. The method according to any one of claims 1 to 10, wherein the sending, by the first device, the upgrade package corresponding to the second version information to the second device includes:

the first equipment sends an upgrade packet corresponding to the second version information to the second equipment based on a near field equipment communication protocol; wherein the near field device communication protocol comprises at least one of a wireless fidelity protocol, a Bluetooth protocol, or a near field communication protocol.

12. The method according to any one of claims 1-11, further comprising:

and the first equipment sends the download progress of the upgrade package corresponding to the second version information to the second equipment.

13. The method according to any one of claims 1-12, further comprising:

and the second equipment sends the installation progress of the upgrade package corresponding to the second version information to the first equipment.

14. The method according to any one of claims 1 to 13,

the type of the first software includes at least one of firmware, a patch, a software development kit, a plug-in, or a device parameter.

15. The method of claims 1-14,

the first configuration information is provided by a manufacturer of the second device.

16. The method of claims 1-15,

the first configuration information is determined by the second device according to the capability information of the second device and the capability information of the first device; the capability information of the second device includes at least one of communication capability, processing capability and display capability of the second device, and the capability information of the first device includes at least one of communication capability, processing capability and display capability of the first device.

17. A software upgrading method applied to a first device, wherein the first device comprises a first module set, the first module set comprises a first module and a second module, and the method comprises the following steps:

the first device determines that first software of the second device is to be upgraded, wherein the current version information of the first software is first version information;

the first module of the first device searches for second version information of the first software from a server;

and the first equipment sends the upgrade package corresponding to the second version information to the second equipment.

18. A method of upgrading software, comprising:

the method comprises the steps that a second device determines that first software of the second device is to be upgraded, wherein current version information of the first software is first version information;

the second equipment determines to schedule a first module of the first equipment to search second version information of the first software from a server according to first configuration information, wherein the second version information is different from the first version information;

the second equipment determines to schedule a second module of the first equipment to download the upgrade package corresponding to the second version information from the server according to the first configuration information;

19. A software upgrade system, characterized in that it comprises a first device, a second device and a server, the first device performing the method according to any of claims 1-17, the second device performing the method according to any of claims 1-16 or 18.

20. A computer-readable storage medium comprising computer instructions;

when the computer instructions are run on a first device, cause the first device to perform the method of any one of claims 1-17;

alternatively, the computer instructions, when executed on a second device, cause the second device to perform the method of any of claims 1-16 or 18.